History does not repeat itself…
…Rather, history is predictive of the future. That is one of the reasons I cringed when I read Jen Simmons’s tweet “Javascript is the New Flash™.”
I’m a huge fan of Jen’s podcast “The Web Ahead” which has (and continues to) change the way I develop, so I am no stranger to the discussion on Javascript framework malpractice.
A few months ago I would have agreed 100% with Jen’s controversial statement. But now, I can’t.
I agree that HTML and CSS are amazing standards, and completely support the ongoing standards movement (really love that ES7). These technologies represent years of experience, best practice, accessibility, and semantics of the web industry. With these truths in mind, for a long time I tried to develop my web pages as close to the intent of these specifications as possible.
But these pages were not easy to build. The front-end Javascript turned into a spaghetti monster mess, and the HTML/CSS mirrored the poor scripting infrastructure. As a developer it was very painful to work with code I knew was suboptimal, but I had no choice. I had principles to stick to.
What started to change my mind on this topic was not frustration (although that point was coming close), but the Shop Talk Show panel on “Inline Styles.” Specifically the fact that there was no strong voice negating inline styles. I thought that for sure I would leave the panel with my anti-inline styles opinion reinforced, but that just didn’t happen.
The realization that ultimately changed my mind was as follows: HTML, CSS, and Javascript are in no way ideal and they were never designed to be ideal.
When’s the last time you wrote CSS? Actual real CSS. No Sass, no Less, just Cascading Style Sheets. For me that answer is never. CSS is not ideal, but that’s ok.
Have you ever taken a look around the Mozilla Developer Network’s documentation on the DOM API? In no universe is that the ideal way to create great web experiences. DOM nodes are not an array, an attribute map has it’s own class—overall it’s just way, way overcomplicated. If you tried to author a good web experience (dare I say silky smooth) with those APIs directly you would go crazy. But that’s ok, it’s even preferred.
I could keep going for a long time naming the ugly, messy things the W3 has specified, but I would be wasting my time as ranting about them does not change the fact that they work. The web should aim to be a platform, not a framework for development.
HTML, CSS, and Javascript should be incredibly powerful, but at the same time they should never limit a web software engineer’s decisions, creativity, and capability to solve problems. An engineer should be able to come to web technologies and interpret them in radically different ways to solve a multitude of different problems.
The web is not a stack and the web should not be a stack. Web specifications are not the house which our applications code simply furnishes, but rather the raw materials we use to build our applications from the ground up.
Javascript frameworks try to bridge the gap between the web platform and an environment where developers can be comfortable and efficient. What Jen describes as a “boxed-up, pre-fab environment” is a good thing. It means developers don’t have to reinvent the wheel time and time again. It means developers can focus on revolutionizing their site’s layout and on making the best user experience possible instead of building their own custom “boxed-up” environment.
JavaScript is not the new Flash, that is unfair to say. We can’t blame the medium (JavaScript) for the faults in its art (Angular, React…).
Let’s reframe the debate
Instead of trying to get closer to the web standards metal, we should instead take a critical look at our javascript frameworks and fix what they are missing, find where they fail. For one, frontend JavaScript frameworks should definetly server rendering, and these frameworks would also benefit from enforcing accessibility. These are not unsolvable problems; and they definitely do not warrant a complete removal of all which makes happy, efficient (even 10x) developers.
Therefore I ask designers to have empathy for developers. JavaScript frameworks allow the developer to write the best and most effective code possible. The frameworks allow the developers to bring the designers careful and beautiful plans into reality.
Likewise I ask developers to have empathy for users. Just because a framework solves 80% of your problems, that does not make the other 20% irrelevant. Accessibility and Progressive Enhancement are critical. They are business issues but more importantly they are human issues.
Looking towards the future
I think ReactJS (or some iteration of) is one of the best things to happen to the web community. It unifies progressive enhancement, accessibility, user experience, backend, front-end, data, content, atomic design, developer sanity, and future web standards so perfectly that it’s a shame to see so little art on it’s uses in these regards. I need more time to experiment before I can say for certain, but I feel as if HTML authored in Javascript will fix many of our problems with the web in the status quo (something a few months ago I would have considered blasphemy). Stay tuned.
