When I was getting started in web development, the Web Standards Project was something I latched onto quickly.
One of their main goals at the time was to avoid “outdated methods that yoke structure to presentation.” They were advocating against the use of proprietary technologies on the web, and encouraged developers to properly use only standards-based development techniques.
The web development landscape was rough in those days. Browser vendors had very different interpretations of how to render a document, and getting a website to look acceptable in multiple browsers, or multiple versions of the same browser, was quite a task. Many developers rejected the project’s mission. They didn’t have any concerns about using structures meant for other purposes to layout a document, and felt that this new method of development was not worth the extra effort required.
In school, these older methods were the basis of my web development education, but when I started to work as a freelancer, I felt that using the standards was a better way to go. The idea of enforcing a clear division of labor when building a website made sense to me, so I decided from then on that all my websites would be built using semantic structure and standards-based styling.
Much of my output at the time was hand-coded, but over time this style of development would be replaced by dynamic languages. As the web grew, it became clear that trying to maintain large styling systems over the life of a project was becoming difficult, so just as structure had moved to dynamic languages, so did our styling.
This move was also met with some resistance. Even though these new languages and processors allowed us to work more efficiently across browsers, some were concerned that the output was not well optimized. They felt that hand-coding was a better way to deliver styling to the browser, and feared that these new system were only adding unnecessary weight to our final output.
Despite the concerns, I felt that these new tools enabled me to create far more powerful and interactive experiences for my clients, while also improving my developer experience, so I embraced them.
In the web standards word, logic was always the third tool in the toolbox. The logic layer was wholly optional for a long time, because it could also live on the server side, meaning the structure sent to the browser would already have had logic applied. Over time, as browser vendors improved the language and smart people started to see the potential, doing logic on the client side became more and more of an option.
The breakthrough for me here came not from a further separation of concerns, but rather an integration of them.
With component-based development, rather than trying to manipulate structure based on logic, the logic itself creates the structure. When the logic layer moved away from the server and back onto the client, there needed to be a way to easily manipulate it, and these new logic layers had the answer. This integration of logic and structure meant that all structure was now a simply an output of the logic.
This move was, of course, criticized by many. The idea of marrying structure with logic seemed antithetical to the separation of concerns many had been trained on. Upon its introduction, this new way of thinking was attacked for being unmaintainable and harder to reason about.
Despite the concerns, this new methodology made sense to me. Not only were there many technical and experiential benefits, it also allowed me visualize my code in a way I was never able to do before, so I embraced it.
With two tools in our toolbox becoming one, what about the third? New frameworks for integrating our style with our logic and structure are emerging, and again we have a another debate about its merits.
Just as we have dynamic structure that needs to be built and destroyed within the viewport, so too has there arisen a need for dynamic styling to be calculated and interpolated based on user inputs. When we integrated our structure with our logic, everything became a component, but often times that meant styling was left out, as a thing to be coded in some separate context. Now with all of our tools together, our workflow has become truly modular, with individual components being in control of their own structure, style, and logic.
As I reflect on my journey through this industry, rather than argue the merits of this new integration, I feel that a larger point has emerged. When we moved from intermingling style and structure, many were mad because the new systems were harder to use, but in the end the ecosystem as a whole benefited from separation.
When we moved our style and structure from hand-coding to dynamic languages, many decried the lack of control and the unknown output quality, but this move has also enhanced developer productivity and product maintainability.
When structure moved into the logic layer, many were mad that concerns were no longer separated, but that move has also empowered many developers by allowing them to visualize their UIs in a declarative way.
The most recent move is trying to fit style into the logic layer, and many are upset once again. Snarky tweets and angry blog posts talk about the lack of understanding of core web technologies, and yearn for the days of separate concerns.
My principle argument against this feeling is that a separation of concerns was never the end goal, it was merely a stepping stone. There was a time when the industry needed to standardize our processes, and thankfully that has happened. Now that we have them, the community and the browser vendors can embrace and extend, molding and morphing our tools to fit our needs.
What I feel gets lost in all the pedantry is that the tools themselves haven’t changed, only the process of authoring them has. Arguing for the sake of rightness over wrongness feels quite small when the emphasis of our work should be on our products, not our means of achieving them. I invoke the solutions that work for me, and being labeled or judged or argued with over those decisions is short-sighted. The history of our industry is one of introduction, reaction, and evolution. New tools and approaches are what got us to where we are, and not being afraid to try new things is what’s keeping us moving forward.
Maybe this new thing won’t be the best choice, maybe the next thing will be better, but either way I’m not going to regret trying it out. I’m not going to pretend that my castle will stand forever, because I know that eventually, all castles crumble.