Web apps without HTML and CSS: the support conundrum
When writing many articles about how HTML became a lacking tool over time and how CSS also may fall short, I frequently talk about a possible way out of the HTML/CSS duo through WebAssembly. This is a path that will be at least considered because both HTML and CSS are hard sells from the developers’ perspectives, at least for most of them. I go very deeply about this in all the linked articles above, but the summary is: CSS is quite declarative, so it doesn’t adapt very well to most developers’ mindsets, while HTML is all full of inconsistencies and rough edges kept to achieve everlasting compatibility without versioning. Bad decisions from the past, impossible to fix today unless some disrupting measurements are taken.
I should say though, I don’t really believe that the biggest players on the market regarding Web browsers and engines (Google, Apple, Microsoft, even Mozilla) will change this situation, at least not directly. As much as I think it would still be very good for all of them to have a more streamlined and future-oriented Web, by shifting focus from compatibility on the Web to starting focusing on truly new technologies that can be better for users, developers and, of course, browsers (even if still keeping a compatibility layer).
As powerful and influential as those companies are, though, they are with their hands tied because HTML at some point in history became basically an agreement between parties. After the awful situation developers had when Microsoft and Netscape battled for supremacy in the late 1990s with no standards at all for the Web, all those companies basically agreed on not breaking anything else, even if at the cost of halting innovation and having a very half-baked tool to work with. Now, HTML is a sumptuous mansion built on top of an original wooden cabin. As the cabin is still there and should be untouched, the whole mansion just feels all wrong.
Now, developers try to bypass the shortcomings on both HTML and CSS partially by having templating engines inside their JS frameworks/libs, as well as CSS automation tools like Styled components and UI libraries. I personally am not a fan of many of those tools, by the way, but I certainly understand why they exist.
UPDATE: it would be nice to say, given some angry comments on this article, that as much as I think we could be better of HTML and CSS, that I don’t nurture strong feelings towards any technology including those and I judge myself to be quite proficient at those. However, I cannot ignore that this is a tendency from the community, made explicit by the extremely successful JS frameworks/libs mentioned above.
WebAssembly to the rescue, or…?
What WebAssembly brings to the table, in this case, is a more powerful way out. If one doesn’t like any of the aspects of Frontend development, even the JS language, WebAssembly can be the solution for that, at least in theory.
The problem is, how websites work is not so straightforward. There are a number of aspects that would be involved in replacing all technologies in favour of a new solution made in WebAsm, and ironically speaking, replacing JS with another language would be the least complex step (and for the issues discussed here, not a solution for anything). The important thing would be to replace CSS using a layout engine and HTML by having a way to manage content. Sounds simple? It is not, especially for the latter.
Layouts
To do layouts without doing it on actual CSS is possible with some layout engines available on WebAssembly right now, and it might even be better. Engines like Stretch and Yoga-layout have versions based on WebGL that run directly on WebAssembly without having to be translated to HTML and CSS and have their own advantages, like being compatible with other platforms other than the Web.
However, there is a caveat: you have to ship your layout engine to your user. This means your awesome web app based on non-CSS layouts will always suffer from a natural disadvantage as it has extra things to be downloaded before anything shows up on the screen. This can be considered an important issue especially for time-critical apps such as commerce websites, where every millisecond spent by waiting customers that want to interact can be crucial for the very survival of a business.
Content: SEO
This is the real issue here. Not the content that is visible to users that are using normal browsers, as this one is not a problem as long as the layout engine can output this (which it should). The issue is what can be considered the “meta-content”: tagging for SEO (search engine optimisation) and accessibility, which is covered now by the very uneven HTML semanticity.
Content for SEO is a problem because the robots that crawl the Web are not trained to cope with custom solutions like layout engines made in WebAssembly. They are trained to deal with HTML, CSS and JavaScript. Web crawler robots like Google’s can read what is on the HTML code and, at their most advanced state, infer the content that is rendered dynamically in JS by some dynamic routines or frameworks, but that’s it, nothing more.
Of course, this is not because those robots are somehow inefficient, but rather because there are no siginificant demand right now that justifies an investment in robots to read the content generated by new layout engines made on WebAsm. Maybe there will be changes about this somewhere in the future, but right now SEO on a theoretical non-HTML website is a real issue. The only upside in that is that in several situations SEO is a non-issue, such as on closed-access web apps.
Content: accessibility
In any case though, unless we are making web apps for a very restricted audience, we always have to care about accessibility. Screen readers for visually disabled people behave in an analogue way to crawler robots, reading the content of pages in a non-visual way.
Unfortunately, right now, these tools need the meta-information that is provided by HTML in order to do their jobs, which is a problem because that information now is often missing or wrong. The adaptation to what happens in the “real world” has started, so they are close to having about the same efficacy as the search crawler robots mentioned above for dynamic JS websites. However, for a non-HTML website, this is a significant dealbreaker, as a current screen reader would not be capable of gathering any important information to decode the page and tell its user.
In theory, meta content information can be extracted from the layout and it would be a matter of transcribing the visual cues such as proportions, action controls and sequences of reading to a non-visual system, but the reality right now is that we don’t have a system with such capability ready for the non-HTML Web. One can argue that tagging like it happens in HTML is better as a meta-information holder, but that doesn’t imply any impossibility to this scenario described above.
In the end, even without layout itself being an issue (but it would be very often) SEO and accessibility make a WebAssembly “way out” of HTML/CSS very hard or downright impossible in practical terms. Because of having no support from search engines and accessibility tools, what we have now can be considered a conundrum: those tools won’t adapt as there is no demand and this demand won’t come because there are no such tools.
I believe that more and more experiences with WebAssembly and WebGL layout engines will come and, maybe, eventually, this loop will be broken, but right now it is clear to see those tools are not to be used in professional development yet, despite the fact most developers that have worked their fair time with HTML and CSS would love to have an alternative to them.
