Frontend things that do work, but could be changed anyway

Photo by Waldemar Brandt on Unsplash

In the city I live, Berlin, Germany, some subway trains look like coming straight from the 1950s and some seem even older. In consonance with the German austere mind, as they do their jobs they are not changed. It’s not like they are hated or something: in fact, they’re quite stylish. I wonder, though, what a slightly smoother ride and a nicer train interior would have on commuters’ daily lives? We may not know so soon in this case.

In my craft, which is Front-end programming, I also see a situation that many aspects of my daily professional life are suboptimal despite the undeniable fact that they work. Opposite to the trains described above, though, these aspects are not “stylish” nor do they carry anything necessarily good.

Most developers are too busy with things from inside and outside their work to think about those things, so they are just there, lying as diffuse ghosts on a house’s foundation, making people uneasy every once in a short while but mostly unnoticed. Also, with faster processors, faster Internet and larger data plans on mobile, it may seem to some developers that they cannot be reached by the limits of overengineering paths made to hide some of the flaws on our development stack. The users of whatever is made by those developers may get the bill, though (even literally, in the case of data plans).

Our common Frontend stack today is generally designed to make it easy to build and maintain big projects, or to quickstart short ones and make them approachable in a familiar way. That’s not a bad goal in itself, as the developer’s times are very important and maintainability is really key (anyone who is a proud disciple of Uncle Bob can agree). The problem is that we usually forget about the user in this equation, delivering them endless bytes of dummy boilerplate data in applications that are too bloated, too slow, too inefficient.

The point of this small piece is to say: it didn’t need to be this way. Our stack is full of funny choices and things that aged badly, not to mention that it is right now ruled by minds detached from the real world of development, unaware of what is going on with the developers on the market. Let’s take a look into some of the problematic aspects we have today:

JavaScript

Prototypal inheritance

From the development perspective, JS prototypes are a weird kind, hybrid of OOP mindset being “sort of it” without being it. Worse: to please Java developers at the time, they are even weirder than they should have been. Many people would be happy if JS featured classes just like in Java in 1996 but JS was designed to be a “minor” language, in charge of small scripts only, so they came up with this particular aspect instead. OOP fans and anti-OOP people are equally dismayed by this, so at least that the disappointment is very democratic. In the words of Douglas Crockford (from 2008):

[…] JavaScript itself is conflicted about its prototypal nature. In a prototypal system, objects inherit from objects. JavaScript, however, lacks an operator that performs that operation. Instead it has a new operator, such that new f() produces a new object that inherits from f.prototype

This indirection was intended to make the language seem more familiar to classically trained programmers, but failed to do that[…]. JavaScript’s constructor pattern did not appeal to the classical crowd. It also obscured JavaScript’s true prototypal nature. As a result, there are very few programmers who know how to use the language effectively.

See the point I emphasised above? We are talking about the most popular language in the world right now, so this is concerning. It is the worst of two worlds: prototypes on JS are unintuitive so people don’t use them and they just stay there as useless heavy bags that have to be carried, bringing the inefficiency to a very basic level.

Maybe with WebAssembly we will have the possibility to have a more efficient Web in this aspect.

Event loop

The point here is not about the event loop itself, but more about one aspect of it: how badly the single-threaded nature of JS is exposed in the language itself.

In the age of frameworks and many things happening at the same time (or, rather, many things being pushed to the queue of events in the loop) doing something inside a call to setTimeout as a hacky way to make something work in its right timing became a de facto standard. Another command, this one more recent, requestAnimationFrame, started to be used for that as well (the name can be misleading for that).

If we have two or more hacky ways to deal with the event loop, are there non-hacky ways? Well, no. Node has a command called process.nextTick but it is only for Node.js, browsers do not support it.

The main point, though, is what most developers make of it: they are led to understand that JS is either multi-threaded or that the JS queue of events is fatal and untouchable, which are both wrong interpretations, but possible to be inferred by the JS APIs and the lack of good advanced tools JS has to deal with the loop in a fine-grained way. With the heavy use of frameworks we have now, there are many things happening under the hood all the time, so this becomes a problem and the hacks become more used.

CSS

Cascading

I said enough of this one already, so I’ll just summarise it here: cascading works (as all the points in this article) but it is a mess. CSS is fine, the presentation vs. content separation can be also fine (although there is room to question it) but the cascading makes everything just feel off. One can even manage to make a native, vanilla CSS implementation work on a big project (maybe with BEM or something similar) but most of the time it is just not funny and not feasible. Good luck with this especially in a team.

The problem with this is that it is so distant from the way programmers’ minds work that most of them just have CSS as a burden, when in fact the rules make sense, the media queries are ok, the cascading though is the real culprit. Cascading was designed for another sort of Web (the mid-1990s, small websites, global themes, Zen Garden) that never came to be and they are also originally designed to be used mostly by designers themselves, which is the key diversion of reality, in my opinion.

Developers were not the target for CSS and, in fact, they tend to use CSS wrong: if a language intentionally bypasses any kind of logic, abstractions or automations to come with its own approach intentionally alien to programmers, then if they use it wrong that will be natural.

Replace cascading with variables and functions (or mixins) and I bet that, for many, most of the problems would be gone. How do you do that, though, without resorting to solutions that seem mostly incomplete or hacky or depend on frameworks? You can’t.

Still, there are so many CSS-in-JS libraries (even in an older list it is quite a number) that I think I may be right. Some modern frameworks have their own way to lightly automate CSS and this is one possible reason for their current popularity.

HTML

Semantics

Another topic which I talked about before. HTML was everything on the Web until it was decided that it should take care only of content and not of presentation anymore. Some tags were deprecated (but are still working, even after 20 years) and Google became the most important factor on why people got onboard this new semantic approach, as it prioritised “adjusted” content for its results. SEO consultants became experts on this approach.

However, sensing that the majority of developers were struggling to get it right and this prioritisation was indeed hurting the quality of its results, Google stepped back after a while to prioritise actual content, to the detriment of the HTML structure. Google’s investment in AI helped to teach its crawler tool to “sense” what was actual content there, just like an actual person would do.

The problem with semantic is that there are too many tags, making both the decision of which tag to use more loose than ideal and the differences between these tags too subtle. I have seen some discussions between well-seasoned experts on possible approaches for ordinary solutions and this shows me that either this reveals some sort of redundancy (which is good) or confusion. Even if it is the first case, the cognitive load theory shows that the more choice you have the less comfortable people are with decisions, and with more than 100 tags to use, most people will stick to half a dozen and call it a day, whether we want this or not.

There is also a very important aggravation factor: not knowing English enough or not knowing it at all makes this problem much bigger. It is like if we are telling people that, to develop, they should know English. This is exactly the opposite direction of where we should go for a more inclusive Web.

Regardless, though, what every developer wants is to put divs and spans on every content corner because the functionality is what they care about. Content is usually taken care of by other people, and these people usually never touch the HTML or any other part of the code. This is another problem on the assessment of how the future would be by the minds who decided the directions of the Web during the late 1990s and early 2000s.

Accessibility (aria)

Analogue and related to the problem above, we have accessibility. It has a similar history to the SEO issue mentioned above but a worse outcome. Unlike what happens with Google, there’s no big AI investment here to make users of accessibility tools like screen readers users aware of what is going on, in case the developer doesn’t stick to the accessibility rules.

The problem is, those are many. Not only do they comprise following the semantic rules described on the point above but there are also the accessibility aria attributes (a standard referred to its acronym WAI-ARIA). The intention behind the standard is, of course, completely noble. In reality, though, developers don’t follow it, no matter how noble it may be or how much the attributes make sense. There are almost 50 attributes and certainly, even if there are people that take special care and know many of them, again, most developers either omit those entirely or use just a couple of them.

Bear in mind, I’m not ranting about developers, saying they (we, in fact), are either dumb or ignorant. Humans are like this, our capabilities have limits and, on top of that, we are just too busy. The ideal thing would be for the technology to adapt to us, not the opposite (which never works).

Meanwhile, even with less investment and sophistication than Google tech, screen readers are improving in their intelligence to provide people without sight a better Web experience, even without enough “meta” information like the ones brought by HTML semantic tags and aria attributes.

In conclusion

I certainly do not want to sound too ambitious or unaware of my limited power as a sole developer, neither I want to blame anyone in special for this, but after many years Web Development has reached a stage where things are quite confusing, unnecessarily at most.

Despite all that, I believe that developing for the Web will be better in the medium-term future, even if this means that developers have to come up with deep changes to how we do things right now. Those changes will address the points above one at a time or perhaps will just render those obsolete at once (maybe through WebAssembly, who knows?)