This week, somebody proposed to replace HTML, CSS and JavaScript with just one language, arguing “they heavily overlap each other”. They wrote the separation between structure, styles and interactivity is based on a “false premise“. I don’t think it is. In this post, we’ll look at why it is good for people that HTML, CSS and JS are separate languages.
I’m not here to make fun of the proposal, anyone is welcome to suggest ideas for the web platform. I do want to give an overview of why the current state of things works satisfactorily. Because, as journalist Zeynep Tefepkçi said (source):
If you have something wonderful, if you do not defend it, you will lose it.
On a sidenote: the separation between structure, style and interactivity goes all the way back to the web’s first proposal. At the start, there was only structure. The platform was for scientists to exchange documents. After the initial idea, a bunch of smart minds worked years on making the platform to what it is and what it is used for today. This still goes on. Find out more about web history in my talk On the origin of cascades (video), or Jeremy Keith and Remy Sharpe’s awesome How we built the World Wide Web in 5 days.
Some user needs
Users need structure separated out
The interesting thing about the web is that you never know who you’re building stuff for exactly. Even if you keep statistics. There are so many different users consuming web content. They all have different devices, OSes, screen sizes, default languages, assistive technologies, user preferences… Because of this huge variety, having the structure of web pages (or apps) expressed in a language that is just for structure is essential.
We need shared structure so that:
- screen reader users can navigate web pages by heading (see headings are tables of contents).
- people with an attention disorder can turn on reader mode
- people with motor impairments can use autofill (see Identify Input Purpose)
- people who want to read a foreign language page in their mother tongue can stick a URL into Google Translate
All of these users rely on us writing HTML (headings, semantic structure, autocomplete attributes, lang attributes, respectively). Would we want to break the web for those users? Or, if we use the JSON abstraction suggested in the aforementioned proposal, and generate DOM from that, would it be worth breaking the way developers are currently used to making accessible experiences? This stuff is hard to teach as it is.
Even if we would time travel back to the nineties and could invent the web from scratch, we’d still need to express semantics. Abstracting semantics to JSON may solve some problems and make some people’s life easier, but having seen some attempts to that, it usually removes the simplicity and flexibility that HTML offers.
Users need style separated out
Like it is important to have structure separated out, users also need us to have style as a separate thing.
We need style separated out, so that:
- people with low vision can use high contrast mode; a WebAIM survey showed 51.4% do (see also Melanie Richard’excellent The Tailored Web: Effectively Honoring Visual Preferences)
- people who only have a mobile device can access the same website, but on a smaller screen (responsive design worked, because CSS allowed HTML to be device-agnostic)
- people with dyslexia may want to override some styles use a dyslexia friendly typeface (see Dyslexic Fonts by Seren Davies)
- people who (can) only use their keyboard can turn on browser plugins that force focus outlines
- users of Twitter may want to use a custom style sheet to turn off the Trending panel (it me 🙄)
Users need interactivity separated out
Some users might even want (or have) interactivity separated out, for instance if the IT department of their organisation turned the feature off company-wide. Some users have JavaScript turned off manually. These days, neither are common at all, but there are still good reasons to think about what your website is without JavaScript, because JavaScript loss can happen accidentally.
We need interactivity separated out, because:
- some people use a browser with advanced tracking protection, like Safari or Firefox (see my post On the importance of testing with content blockers)
- some people may be on low bandwidth
- some people may use an old device or operating system for valid reasons
- some people may be going to your site while you’ve just deployed a script that breaks in some browsers, but you’ve not found out during testing, because it is obscure
As Jake Archibald said in 2012:
“We don’t have any non-JavaScript users” No, all your users are non-JS while they’re downloading your JS
That’s right, all your users are non-JS while they’re downloading your JS.
Existing abstractions
None of this is to say it can’t be useful to abstract some parts of the web stack, for some teams. People abstract HTML, CSS and JavaScript all the time. People happily separate concerns differently: not on a page level, but on a UI component level.
On the markup end of things, there are solutions like Sanity’s Portable Text that defines content in JSON, so that it can be reused across many different “channels”. This is a format for storing and transferring data, not for displaying it on a site. Because before you display it anywhere, you’d write a template to do that, in HTML. In a government project I worked on years ago, the team abstracted form fields to JSON before converting them to HTML. I currently work on a project where we use XSLT to specify some stuff before generating HTML.
For CSS there are extensions like Sass and Less, utility-first approaches like Tailwind and many methods to define CSS inside JavaScript component. From JSSS (from 1997) to CSS in JS today, there is lots to choose.
As for JavaScript: there are numerous abstractions that make some of the syntax of JavaScript easier (jQuery, in its time), that help developers write components with less boilerplate (like Svelte and Vue) and that help teams make less programmatically avoidable mistakes (TypeScript).
I don’t use any of these abstractions for this site, or most others I work on. Yet, many approaches are popular with teams building all sorts of websites. Choose any or no abstractions, whatever helps you serve the best HTML, CSS and JS to end users.
We’re very lucky that all of these abstract things that are themselves simple (ish) building stones: HTML, CSS and (to a different extent) JavaScript. With abstractions, individual teams and organisations can separate their concerns differently as they please, without changing the building blocks that web users rely on.
Could you benefit people in your abstractions? Maybe. The proposal mentions specific parameters for visual impairments and content that can trigger seizures. But it is better for users (including their privacy) to have such things in the main HTML and CSS, regardless of whether that was written by hand or outputted by some abstraction.
Conclusion
The separation between HTML, CSS and JavaScript as it currently is benefits web users. It does this in many ways that sometimes only become apparent after years (CSS was invented 25 years ago, when phones with browsers did not yet exist, but different media were already taken into account). It’s exciting to abstract parts of the web and remodel things for your own use case, but I can’t emphasise enough that the web is for people. Well written and well separated HTML and CSS is important to their experience of it.
Thanks to Darius, Jen, Krijn, Thijs, Tim and Coralie for pointing out typos and mishaps.
Comments & mentions (316)
Another thing that Mike Little, co-creator of WordPress let me in on that I did not know is that sometimes users in need of assistive technologies cannot easily upgrade without significant costs, which may make them unable to use the “new standards”, which is another great argument for the cascade and for structure with progressively enhanced presentation and interactivity.
I would challenge this a little bit – the points that you presented in this article are entirely valid; However, these benefits are from a web-consumer point of view and not a developer point of view. There’s nothing to say that these benefits cannot be realised with a unification of the 3 languages as presented in the proposal. The capabilities and use cases presented are simply a product that can be replicated using other technologies. I would raise the analogy of writing Hello World in C or in Rust – one cannot say that because C can write hello world and benefits the user that Rust is not capable or is inherently a worse approach – both are tools to create the end product of Hello World.
This is not to say that the content of this article is not relevant – I just don’t think they are relevant to the argument against the grand unification proposal.
I would challenge this a little bit – the points that you presented in this article are entirely valid; However, these benefits are from a web-consumer point of view and not a developer point of view. There’s nothing to say that these benefits cannot be realised with a unification of the 3 languages as presented in the proposal. The capabilities and use cases presented are simply a product that can be replicated using other technologies. I would raise the analogy of writing Hello World in C or in Rust – one cannot say that because C can write hello world and benefits the user that Rust is not capable or is inherently a worse approach – both are tools to create the end product of Hello World.
This is not to say that the content of this article is not relevant – I just don’t think they are relevant to the argument against the grand unification proposal.
[garrettc]
[garrettc]
Exactly what Minh said. This post makes valid arguments for applying semantics and abstracting and separating user concerns, but that has nothing to do with the tech stack of developing for the web.
I’m not saying I agree with the proposal of a grand unification, but it seems this post completely missed the point and addresses different issues.
And then people use React + CSS in JS just to have everything in one place. Not saying separation is bad, but the merger will happen sooner than later, it is already happening with mobile and desktop platforms, web isn’t too far away, web assembly will open the door to this unfortunately.
Even from a development perspective this is a horrible idea. HTML, CSS and JS are all their own distinct sections with distinct limits. For all intents and purposes HTML and CSS are already able to be merged, so where is the gain? We already know heavy inline coding of CSS has a negative affect on performance. Then you also blur the lines or appearance and structure which while similar are not the same.
IMHO the best way to approach this is by acknowledging each of these languages are unique tools. As such that does not say in the least how or when you must use them. It merely indicates when a particular tool might be best suited for a purpose.
Either way, even if you tok the time to unify all three languages you still run into the problem that many third party sub-languages exist and new ones will come over time. How do you merge all of these sub-languages and to what benefit is it really?
The separation by tool is the best way as it gives full control to the one using the tools in the first place. Then there is the cost to rewrite basically all the current websites and tools just to get something some people think but do not know is more efficient. Plus this is completely overlooking the fact that HTML, CCS and JS all operate on other sets of tools for their foundation as well.
Grand unification is already well supported. You implement it on your own at your leisure and at your own personal costs, be it time, effort, energy, resources, etc. You can also live with any unforeseen consequences all on your dime.
The modern Internet is indeed a product of twenty five (or more) years of user-first Web Development. And the future of the Web is therein as well. The human user of the Internet is the primary reason why the Internet exists in the first place.
To accomplish this, HTML, CSS and JavaScript have their own incredible eco-systems that (however intertwined) are the engines that make what the Web is and can become. Thankfully there’s a broad consensus that the Net will continue on this track.