Should We Change Web development?
I have been a front-end developer for quite a long time, and the reason I chose to deal with interfaces instead of other flavours of coding like back-end or data is that I like when the results of my work are very visual.
Having pursued a design degree taught me how people think visually when they want to convey a message, even when those people are not professionals of design.
In the early days of the web as a popular matter, circa 1997, many people and most companies wanted to have a presence on the new and amazing “World Wide Web” by having their own websites — their “home page”.
These people and the early-time professionals dealing with designing for the web discovered they had to deal with a technology not built for what they often used to do with printed graphic design, a hypertext technology called HTML, basically designed to be mainly text — static — like in books but with links.
Since very early on, the web supported images as well as some basic formatting for the text and the page’s background. So people had to be extra creative when working against poor connections and very limiting standards when designing a visual experience on the web. Connections improved a lot, as it is attested by all people watching video online in 4K, but the limiting standards, as they surely improved, may not have improved just as much.
In the beginning, there were tables
Back to the very beginning of “pop-culture internet”, some people came up with a neat workaround for layout: using the HTML built-in tables (obviously, built to display value tables) to establish a hacky “grid” that could be used for layout, with large caveats all around. This approach is, disgracefully, still used in e-mails today, as important e-mail clients intentionally do not support modern layout technologies, supposedly for security reasons or to intentionally keep e-mails as plain as possible.
CSS and JavaScript (and the DOM, which is basically the programmatic representation of HTML in JS) were already there around that time, but CSS was on its first version still very buggy and limited.
JS (very limited as well) was just not seen as the right tool for the job, and it was very, very slow. Within a couple of years and after lots of table contortionism (which I proudly took part in) CSS was made usable and layouts improved… a bit.
Stacking up the divs
After Internet Explorer 5 a new era of layouts started, which changed everything but also introduced new issues to the developer. CSS was there with a new “tableless” layout model based on floats and clears, that didn’t solve all layout issues but at least could be used instead of the dreaded tables. Blank canvas tags like div and span were born on the premise that CSS was now the only tool for layout and HTML would be exclusively taking care of content, so they were “transparent” tags, without fixed meaning. At that time many pages started having their HTML code made up entirely by divs and spans, which still happens to this very day. Separation of content from layout seemed like a great idea back then, and the CSS Zen Garden (a website that had a fixed HTML as its base but changed completely with different CSS “themes”) blew many people’s minds at the time.
Even with the mighty Cascading Style Sheets sold as a “revolutionary” tool, doing layouts with the early CSS standards was still a hacky, clumsy task, as differences between browsers required writing exceptions and rewriting things entirely for different cases. The CSS layout model didn’t seem to take into account a number of real demands of developers and designers properly.
To me, though, the biggest issue seems to be that this HTML vs. CSS separation was designed for a web that never happened: one in which most websites offered different themes, not only colours or background to be customisable but something more akin to what CSS Zen Garden did, changing fonts, proportions, the foundations of the layout itself. How many websites that you know today offer themes in such a way?
HTML independence
A bit later, HTML was cemented as a media for content only, with new standards that ended on HTML5. In real-world development, though, developers would not care about this separation as nobody actually wanted “themes”, but they started to care mostly because of search engines, that meaning Google.
Search Engine Optimisation, also known as SEO, was deemed the number one way to succeed on the Internet back then, and together with accessibility (that very few people actually mind) pushed developers towards the aforementioned separation and also towards the hard and loose task of making HTML code more “semantic”, trying to forcibly use tags like <article> in places where it didn’t seem to belong.
Later though, it should be said in fairness, when Google started to try mimicking actual people in its behaviour, prioritising actual content over standardisation of the underlying code, it was just too late and most web developers were doing things just because they “should” do rather than understanding the point of why they would (read the note in the end about accessibility).
One funny detail is that the web browsers have to offer retro-compatibility and this means that, ideally, nothing can be just removed: instead, most deprecated functionalities may be kept in an “oblivious” harmless state and some of these must be preserved not to break websites entirely. Very popular older tags from before CSS like b or i (for bold and italic respectively) were “repurposed” to fit new semantics (in this case, “bring to attention” and “idiomatic text”, which sound like lame excuses to me) and some like center, although completely deprecated, frowned upon, and marked as poisonous and cursed, still work on all browsers at the time I’m writing.
Flex, grids, and CSS redemption
Back to CSS, the situation of hacky, limited power to layouts came to improve (again, just a bit) when the “flexible model” was introduced on the third iteration of CSS standards. With this model we could now control flexible layouts in a much more complete way, killing the need for some of the hacks used. It is/was still not everything that someone needs for making layouts, though, not to mention the API for it is downright confusing, so even experienced people just learned what it can do and did it with some trial-and-error or through cheat sheets, which tells me that something is wrong there.
Even later, in fact, only very recently, true CSS grids were implemented across modern browsers (old ones still require a number of hacks). The implementation is often criticised, as everything in the age of Twitter, but it is mostly fine given all constraints and the general complexity of the whole HTML + CSS + JS chain. This feature is still not used as much though, as developers are stuck in the “old ways” and will, naturally, be stuck there for a while, especially when there are people still using IE11.
With grids, CSS has finally all features that everybody wanted and we are all utterly happy that the Frontend stack is done. Or is it? Well, I can see two problems here:
- First of all, the more features we have on CSS (and the rest of the stack) and the more “good practices” and recommendations we have on how to make web pages, the less democratic and more esoteric the Web becomes. HTML was born as an easy way to make pages, that everyone with access to the Internet at the time (not a lot of people, but still) could deal with, as it was mostly text after all. Now, even the most experienced professional developers work aware of the fact that making websites is quite hard and there is absolutely no way of achieving something 100% good;
- Second, the most popular browsers of today can perform rather well as the optimisations for this chaotic integration between HTML, CSS, and JavaScript are amazing. With this said, should this integration be this chaotic? Extending this a bit: should we have this integration at all? Should we really carry all the history above with us? Making a silly analogy: if you carry a bag that has someone constantly shoving things there and making it heavier, should you try focusing on working out so you can always carry more and never assess the actual content of the bag?
There’s something rotten
I wrote an article some months ago that went deep on how the separation between CSS and HTML (presentation vs. content) was put in jeopardy by frameworks like Bootstrap and Tailwind. By that time, as now, I pointed out that it makes no sense to stick to the separation of concerns as it is something designed for a Web that we never got to see.
While using a lib like Tailwind can work to have less unnecessary abstractions, it obviously does not address the issue of this separation being the built-in behaviour of the Web today. The whole system comprised of HTML + CSS is a victim of its age. Now we’re still supporting a way of achieving layouts and rendering pages that are based upon and extended over a structure from the early/mid-1990s for no good reason other than the lack of options.
Actually, there are ways, ones that are still experimental or incomplete, but they surely exist. With WebAssembly, which is basically a way to access the lowest level of resourcing in our browsers, we are not stuck to any architecture, to HTML, CSS, DOM, even to JavaScript anymore. In theory, at least: we have already 3D high-performing engines out there written in WebAssembly running games and 3D applications. Making a 2D engine to render mostly static pages on WebAssembly looks like it would be a much smaller job, from this point of view.
However, this is not the actual case, unfortunately. At least not for a 2D engine necessary to render what we consider to be a “web page”. The main problem is not quite the engine itself but how Web site developers (either professionals or not) are bound to generate layouts there. Thinking about all the immediate problems that are currently solved by HTML+CSS+JavaScript we have a long list of features and, even if a lot of those are just quirks of the stack or deprecated things, we would still be left with a lot. How to make this “lot” accessible to casual developers, flexible to professionals and sustainable as a platform is the challenge in question, likely solvable through the power of WebAssembly but still very much a hard task.
In my next article, I will delve into the concept of a potential replacement for the whole HTML + CSS + JS (DOM) stack, not with practical implementations (I don’t want to sell anyone a new library) but with concepts that can be used for creating the next Web for all of us.
Final note on accessibility: Personally, making websites more accessible now seems to me a noble but clumsy task and I know most people either hate it or do it wrong, or both. I am not saying that because I don’t want me or my Frontend peers to have extra work for accessibility, but because trying to make people adapt to things that are just not well designed is only realistic when the reward is big enough, which has a sad consequence in this case. This means that the majority of websites will always be not ideally adapted for a very intricate set of aria-something parameters and other dubious rules. I think the Web should be open to whoever wants to publish something and not become a place that is a private club only for specialists of any kind. More on that in the next article.
More content at plainenglish.io
