ar·chi·tec·ture
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures.
ar·chi·tec·ture
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures.
This is the definition of architecture—traditional architecture, like of buildings—on wikipedia.
[READ SLIDE]
ar·chi·tec·ture
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures.
The process and the product.
With that in mind—what does that mean... [SLIDE]
So what is Front End Architecture?
For front-end development? For building apps and websites?
What is front end architecture?
Front-end Architecture is a collection of tools and processes that aim to improve the quality of our front-end code while creating a more efficient and sustainable workflow.
[READ SLIDE]
Believe it or not, there are some people, like me, who enjoy the organizational part of writing CSS more than we enjoy making something pretty or animated or a better interaction. I like making a CSS file that is organized and commented, that other people can read and use with joy , and I feel that the end result (the designed website) is way better when the code is better.
And I believe it makes sense to have a separate role for this, not just foist this work off on all your front-end devs.
Front-end dev has gotten SO complex these days that we can't assume that all devs care about this. We can't leave a gap of responsibilities, like visual regression testing, linting, or building internal tools and documentation, and hope it will get done a little bit by everyone. It's time we put focus on this, as it deserves, rather than being an afterthought.
Front-end Architecture is a collection of tools and processes that aim to improve the quality of our front-end code while creating a more efficient and sustainable workflow.
Micah Godbolt gave a great talk at CSSDevConf called Raising a Flag for the Front End Architect, and in it this is how he defined FEA.
Micah’s talk covered the following potential responsibilities:
Coding Standards - HTML, CSS and Sass/LESS/etc, JavaScript
Documentation
Style Guides or Pattern Libraries, “a common language”
Regression Testing
Dependency Management, package managers, etc
Build Systems, Grunt/Gulp/etc
Linting, Compiling, Minifying, etc
Performance Optimization for CSS, JS, images, asset caching
Continuous Integration
I’d go on to say that a quality Front-End Architect might also be responsible for:
understanding the cascade, inheritance, semantics, and being able to choose the best style of CSS organization for the project (not necessarily their favorite)
organizing and building UI modules, working closely with UX or more visually-focused designers/CSS developers
consistency of modules, look and feel, UI interactions
creating file and folder structure and naming conventions, for HTML and CSS, most likely JS as well, and helping define back-end naming conventions for consistency
understanding the technological and business implications of a task, technical debt, and “perfect is the enemy of done”
code standards · documentation · visual regression testing · automation · pattern libraries · build systems · maintainability · performance · tooling · DRY code · front end ops · clarity · efficiency · scalability · extensibility · dependency management · unit testing · style guides · continuous integration
code standards · documentation · visual regression testing · automation · pattern libraries · build systems · maintainability · performance · tooling · DRY code · front end ops · clarity · efficiency · scalability · extensibility · dependency management · unit testing · style guides · continuous integration
If we remember that architecture is both the process and the product, for us...
The process is automation, how we write code for clarity, maintainability, and modularity. it's how we help our future selves.
Then, the process creates the product.
code standards · documentation · visual regression testing · automation · pattern libraries · build systems · maintainability · performance · tooling · DRY code · front end ops · clarity · efficiency · scalability · extensibility · dependency management · unit testing · style guides · continuous integration
The product is a style guide, a consumable package of code, a code standards guideline. it's a build system, internal tools, grunt, package and dependency management, tests. It's the CSS and HTML and JS modules themselves, that developers use to create a website.
A Front End Developer's audience is the website user.
A Front End Developer's audience is the website user.
A Front End Developer's audience is the website user. the developers themselves.
This may seem obvious, or no big deal, but to me it's the key to understanding why Front End Architecture needs to be a separate discipline than just front end development.
A Front End Architect builds the design and construction.
A Front End Architect builds the design and construction. a designer of constructions, not the actual builder.
This means that I am building the legos, if you will, of the site, so that my developers—you—can build the site itself.
You are the builders of the web.
My current job description:
“refactoring & documenting Sass/CSS/HTML modules, making a consumable package of Sass for other apps, visual direction and UX of a living style guide tool, versioning the tool, testing it, producing release notes, and of course, actually building it.”
My current job description
refactoring & documenting Sass/CSS/HTML modules, making a consumable package of Sass for other apps, visual direction and UX of a living style guide tool, versioning the tool, testing it, producing release notes, and of course, actually building it
As the tool is being built, this role will work collaboratively on features with consuming teams, to make sure it is working as needed. They will train consuming teams on both the value of the tool as well as how to use it.
As well they will provide conflict resolution for conflicting UI components/use cases, and consult with teams on the best ways to design and build new UI features with best practices/reusability in mind.”
AN INTERNAL AUDIENCE
DEVELOPER ERGONOMICS
LONG TERM MAINTENANCE
Writing code as an architect is a different beast than writing code that is deployed straight to the browser.
A Front End Architect has to care about three things that your average developer doesn't have to.
[FRAGMENT] an internal audience
[FRAGMENT] developer ergonomics
[FRAGMENT] long term maintenance
AN INTERNAL AUDIENCE
when you work on a large-scale product, you have many devs, many designers, many teams working on features at any time
RMN has ~50-60 devs, a big design/product team, and 5-10 features or A/B tests on various parts of the site at any given time. ops has scaled, deployment has scaled, but the css/front end has not.
Front End Architects are not
I am writing code for internal consumers - other developers - not for users - not to be minified and go straight to the browser.
<div class="c2 p1 usr-ntfy usr-box cf">
This means you have many different concerns—you care about the people reading the code, so you want to write human-readable code.
The browser doesn't care what your classnames are—so why not make them super short and efficient and acronym-y?
Because this [POINT AT SLIDE] is difficult to parse, as a human. And the efficiency gains of a longer classname list, for the browser, is typically not significant.
And if this is difficult for you to parse, it's more difficult for you to know where to add code, or change code, or what might affect something else.
er·go·nom·ics
the study of people's efficiency in their working environment.
Ergonomics isn't just how tall your chair is and if your elbows are straight when you are typing on your keyboard.
Ergonomics is another name for "human factors"
Human factors or ergonomics is concerned with the "fit" between the user, equipment and their environments. It takes account of the user's capabilities and limitations in seeking to ensure that tasks, functions, information and the environment suit each user.
What is your primary skillset?
& how often do you struggle with something else?
What is your primary skillset?
[FRAGMENT]
And how often do you struggle with doing something else that ISN'T your primary job?
We want a dev who may not understand CSS very well to not have to worry about where to add code, or if will cause specificity issues.
We want a designer who wants to make a new visual addition to not worry about breaking prod and introducing bugs.
but we also want a dev or designer who loves writing CSS to have a huge toolbox of extensible styles they can play with, see the inner workings, and make new stuff - but not have to reinvent the wheel.
LONG TERM MAINTENANCE
what is “long term”? for a client project, or a prototype, long term might be 3-6 months, a year. you need front end code that can withstand a few changes, but not many people touching it, etc.
Salesforce is ~15 years old — lots of original code.
Retailmenot’s site is over 4 years old—and in many places it’s the same code as when we purchased it in 2010. RMN has ~50-60 devs, a big design/product team, and 5-10 features or A/B tests on various parts of the site at any given time. ops has scaled, deployment has scaled, but the css/front end has not.
lots of time to have to live with your technical decisions! long term takes on a different meaning when you think that the tech choices you are making could be things you live with for 5, 10 years.
Technical Savings
but what about technical savings?
Technical Savings: Well-designed code, planned to satisfy future needs. Technical Savings are a form of wealth that makes a module more maintainable, extensible or reusable.
Technical Savings are the result of some extra work. We must invest in the design of our modules so that they are indeed more maintainable, extensible and reusable. But we must believe that this investment will pay itself in the future. If done right, the efforts invested in accumulating Technical Savings should be smaller than the efforts required in the alternative of incurring technical debt and then paying this debt through successive refactors.
HUMAN READABLE CODE.
So here are just a few things that differ when you're architecting CSS/Sass for a large scale project, for internal consumers, rather than writing CSS that goes straight to the browser.
First of all, and I can't stress this enough: human readable code.
The browser doesn't care, and when you send code to the browser you want it to be squished and minified and ugly—but as a front end architect, you're not writing code for the browser. You're writing code for humans.
· keep the authoring style sheets accessible
· don’t needlessly complicate simple needs
· one-to-one parity of file names
· prefer unambigious names over shorthand
HUMAN READABLE CODE, naming with intent, classes, named files/partials/JS the same (one-to-one parity)
Ben Frain:
Don’t write impenetrable looking code. CSS is a declarative language so try and keep the authoring style sheets as accessible as the resultant CSS. Mixins and logical loops are sometimes preferable and advantageous (they can greatly reduce verbosity and repetition in the authoring style sheets) but don’t needlessly complicate simple needs.
Try to create one-to-one parity of your HTML, CSS, JS, folder names, so you always know exactly what to look for
And of course, prefer unambigious names over acronyms, or shorthand, or making people guess about what they're looking for.
“Don’t write clever code. Write embarassingly obvious code.”
—Scott Stevenson, @scottstevenson
I love this quote by Scott Stevenson, he tweeted this just yesterday.
“Don’t write clever code. Write embarassingly obvious code.”
PRACTICE SAFE CSS.
This one is huge, too. If we want to remove the burden of "will this break something on the website?" from our developers, we have to write bulletproof, super safe CSS, so they can not worry.
“By preventing name collisions with other components, chunks of CSS can be more easily moved one environment to another (prototype, stg, prod),... or be removed in the safe knowledge that their removal will not affect others.”
—Ben Frain
Name-spacing the CSS of each visual component can be used to create some form of isolation. By preventing name collisions with other components, chunks of CSS can be more easily moved one environment to another (from prototype to production for example).
“As name-spaced components are almost guaranteed to not leak into other components it makes it incredibly easy to build out and iterate on new components as new design requests are received. It affords a hitherto un-afforded blanket of impunity.
This approach however is not without cost. This approach has greater potential for code duplication (you may be styling one item in a component that could be abstracted and easily used in another component) but I find it results in far more maintainable code – whole components can be removed in the safe knowledge that their removal will not affect others.
“In some ways it is the opposite of DRY; we are gaining a degree of component isolation at the cost of verbosity.”
“I don’t know what that’s for, so just leave it in.”
“In a rapidly changing large project, where many different people touch CSS, I find that more CSS bloat accumulates due to author deletion fear than duplicated styles.
It’s likely that CSS authors are more likely to simply add to existing CSS than risk removing huge swathes of it because it’s difficult to be entirely sure what will be affected.“
But yes, also
MODULAR, REUSABLE,
My goal when writing CSS for enduring and rapidly changing web application is long-term maintainability.
It's important to understand output and the tradeoffs in file size, selector output/css bloat, and ease of authoring and reuse.
Composition is the idea that an html component might “contain” other styles, rather than “inheriting” those styles. You can see this principle used extensively in OOCSS, BEM and Sass @extends. Instead of layers of styles, each overriding the last, these approaches embrace the Single Responsibility Principle.
easily reusable code > the cleanest code to the browser
It's important here to understand the cascade, use it to your advantage, but also reduce the places where you can create cascading or specificity issues.
we don’t care what the css that the browser sees looks like—it's all compressed, non-dynamic code now — yes, we care about perf, no we don’t want eighteen selector long declarations, but ultimately as an author...
...being able to delete an entire Sass partial (say 9KB) in six months time with impunity (in that I know what will and won’t be affected by the removal) is far more valuable to me than a 1KB saving enjoyed because I re-used or extended some vague abstracted styles.“
DOCUMENTATION
Ah, documentation. Everyone's favorite, right?
DOCUMENTATION
What if I told you you didn't have to write any documentation yourself, but that it was all there, in the files for you, so that
[SLIDE]
You can find what you need.
A Front End Architect should produce detailed documentation inline in the CSS or HTML to increase ability to reuse components rather than write new ones
I want to write the world's most detailed CSS/Sass comments, instructions in helpers, mixins, etc, so that you don't have to. So when you go hunting for how to make that style, button, whatever, it's painless for you.
Backend developers or designers don't want to spend
Backend developers or designers don't want to spend It frees them up to do the work they are best at.
Think of the 80/20 rule. You should get to spend 80% of your time doing the thing YOU are really good at, whether it's prototyping a new flow so you can get users in front of it, or writing JS unit tests or something; and then 20% of your time in setup, polish, code review, etc.
But how often do you spend more like 20% of your time on the feature, and 80% of your time making sure there aren't CSS bugs in prod? Or whether or not you increased performance? Or unable to find where the CSS you need is?
The job of the Front End Architect is to make it so that you can focus on the work you are best at.
“If we think about CSS first, we’ll be able to think about CSS less.”
—Michelle Bu, @hazelcough #cssconfoak
I want to leave you with this quote from Michelle Bu, who spoke at CSSConfOak yesterday on a similar topic.
She's totally right: if we can focus on CSS now, if we can have someone focusing on all the organizational, architectural stuff—then we can think about it less in the future.
Thank you!
@elyseholladay