Farewell WebTech

Or see you later rather?

# TLDR:

End of this month, I will quit web programming and programming in general for some time, taking a much deserved time off and decide on my future direction.

It has been a nice ride, let me share a few things.

# The beginnings

I edited my first piece of HTML back when using Netscape Navigator in Windows 95. It quickly grew into a hobby and starting in 2000, I was managing a few game-related fan pages.

Back in those days <table> based layouts with bgcolor and <img> were all the rage. There was no CSS back then, and noone was using JS for anything really. You basically did some PHP3, maybe with a MySQL 3 in the backend. No real classes in the backend code, no transactional database, no client side code.

At one point, I made the move from IE6 to Firebird as it was called back then, simply because it supported these semitransparent images called PNG. It was crazy, really.

Apart from some game-related fanpages, I also contributed to a browser-based MMO and did some occasional paid work when I was not in school. I also contributed to bigger pieces of software, both closed source and open source.

I was always the one embracing bleeding edge technologies. Table-less layouts, pure-CSS dropdowns, -moz-border-radius, etc. I actually wrote my Bachelors theses about WebGL, in a time when it was just an experimental thing in Firefox only, back in 2010.

Before that, I also switched to Linux full-time (apart from gaming), mostly motivated by the horribly bad Windows Vista. Well thanks for that actually :-)

Along the way, I developed a strong focus on frondend code and JavaScript. My Masters Thesis was about implementing a sophisticated code completion engine for JS. I know the language inside and out, hell I even wrote some of it. That refers to some of the ES2015 features I implemented in SpiderMonkey, the JS engine running Firefox. One of the achievements I am most proud of.

# Problems ensue

But the web ecosystem itself moves in a direction I am not happy with and that I also do not want to be part of anymore, really.

One of the problems is the community that is increasingly moving towards a Java-esque mindset where it is ok to just layer abstraction over abstraction, all that after you have to install hundreds of megabytes of tooling, all while wrestling with packagers and half-broken solutions to things like hot module reloading and things like that.

You are left with either choosing library A that can’t handle usecase X you have, or with library B that sucks because of completely different reasons. Things are buggy and incomplete, and nodejs still has not figured out what to do about ES2015 modules, predictions are it will take a year to sort it out. It is a real mess.

People jokingly call all this JS fatigue, but it really is draining all your energy, especially if you have been at it as long as I have.

# The web as a platform

Proponents always say that the web is a single platform that can finally achieve the “write once, run everywhere” thing we always wanted. Sadly, it is far from it. It is actually four main browser engines running on different operating systems on different hardware and form factors. All of those break in surprising ways and have subtle incompatibilities that haunt you any time you want to do anything interesting. Not to mention legacy systems.

For the last 2+ years I have been working on pagestrip, which provides a system for digital publishing which brings user authored content to the web and scales it to the available viewport pixel-perfectly. It does sound pretty easy, and that is the reaction I got from most people who asked what I (used to) do for a living.

But the devil is in the detail, and making those things work on all those different platforms with halfway decent performance and visual fidelity is, at least for certain things we want to do, simply impossible because of platform limitations. Chasing down all the edge cases is really frustrating work. Up to the point where I just snapped and said I could not take it any more.

(As a funny side story, a former collegue of mine quit a few month prior after a very long time struggling with implementing proper snapping in the editor part of our platform. He just snapped :-)

I am also jokingly referred to as the CSO of the company, the chief scrolling officer, because one of my recent projects was to implement proper scrolling with snapping support. You know, because browser-native scroll snapping is a changing spec that only has some incomplete, incompatible and buggy implementations in browsers. And we kind of need to have that stuff working.

But oh boy is it hard! With all those different browers, devices and input methods. Its a real mess, believe me! One might rightfully say that it really was what broke me at last.

# The Future of Software

But lets get back to software development and programming languages in general. There is one big trend I see in recent times, which is to write more and more software in javascript.

Actually, I think the main goal was to have one language that you could use to write software for all platforms. Something Java failed to do (thank god for that), but now JS is kind of achieving, for better or for worse.

I can see this trend looking at the proliferation of both Electron for desktop development and react-native for mobile. And I really see the appeal of both approaches. You can share, say 80-90%, of your code across platforms. And electron itself is much more of a single platform than the mess of incompatible browsers is.

But I am deeply opposed to this trend. Simply because JS / web technologies is not the right technology to use for this. As much as I have worked with JS over the years, also my own opinion about things like type systems has changed a lot over the years. And by now I am ready to say that JS is a horrible language, just as the web platform is a horrible platform.

One of the reasons is the nature of web technology. It is extremely flexible and dynamic. But that is also one of the weaknesses. Because it is only ever going to grow. Let me give you an example.

The number of properties of CSSStyleDeclaration (aka Element.style) will only ever grow, it will never ever increase. There is no thing like deprecations or semver-major releases of web tech. Features will never ever be removed.

The goal of pay for what you use does not work in the context of web technology. It is impossible just by the nature of the technology. Browsers will only ever get more complex. They will use up more memory and system resources, just because of the standards development. And that does not even mention the ever increasing bloated libraries that pile up layers of abstraction in a language that has no zero cost abstractions.

I mean we now have 4 cores and 4G of RAM in our phones, and easily 8 cores and up to 32G of RAM in our desktop computers. Because we actually need that much to run all the bloated software. Sure, “unused memory is wasted memory”, but maybe I want actually multitask and be able to run more than one program at the same time.

Not to mention startup cost. I would argue that before the advent of SSDs, system bootup and app startup was mostly IO limited. But now with more and more desktop apps moving over to things like electron, things become CPU bound again and a simple text editor needs up to one second to start. This is simply unacceptable. I want the PC to wait for me, not the other way around. And speaking of SSDs, storage might also become a bottleneck when every piece of software needs a ~100-200M electron bundle. At least on linux distribution packaged software can deduplicate that. No idea how huge react-native packages are though, but I bet they aren’t light either.

# Opposing trends

Speaking of react-native, I am actually happy that it will hopefully kill this thing called mobile web apps. I think those were a terrible idea, contrary to what other Mozilla fanboys might think, related to Firefox OS.

Anyway, I think mobile web apps were a terrible idea, because they were never able to match both the performance and the look-and-feel of native mobile apps. React-native takes care of that by at least providing a native look-and-feel. And react-native is also increasingly moving performance critical things (such as animations) to native code, because, oh what a surprise, JS sucks when it comes to performance.

Electron is kind of the opposite. It rather provides a unified look (and themeable, that really is a plus) of one app across platforms, although electron apps will not really match the look-and-feel of native apps for each desktop platform. And like I mentioned, people are apparently happy with subpar performance on desktop for whatever reason.

# The hero we deserve

Well I am personally betting quite heavily on Rust, a language that is extremely high performance (on par or even beating C++), but also safe (no crashes) and most importantly easy to use. Well at least once its ergonomics are improved a bit, which is an ongoing task. I am especially excited about non-lexical lifetimes.

I am also happy to see some progress for the general problem of 2D graphics and performance, a problem that former(?) Qt developer Zack Rusin was talking about 7 years ago. I mean it really surprises me every time why modern games can render millions of polygons and extremely high quality graphics at buttery smooth framerates but web pages still stutter. I do think that finally we have the proper technologies to move 2D content to the GPU. Not surprisingly, part of that stack is written in Rust. Pathfinder, a high quality GPU font renderer and webrender, a 2D scene graph renderer optimized for web content.

Also the GNOME/GTK community is making progress towards hardware accelerated drawing in GTK4 via GSK, and doing experiments around bringing GTK and Rust closer together, which I am very excited about.

Since electron clearly shows that desktop apps are moving toward a custom themeable look-and-feel across platforms instead of platform native look-and-feel, maybe the time would be ripe for a completely new toolkit powered by webrender, with a css inspired theming solution, but still with a clear strategy on deprecation and purging/detoxing of obsolete features.

Coupled with a language that actually supports zero cost abstractions and pay for what you use resource usage.

Or maybe it will rather happen in the form of react-native for desktop powered by WebAssembly, so you can still use a decent language.

# In closing

Exciting times, certainly. Only time will tell, but I sure am too tired to be on for the ride. I will just wait this one out, practicing my Rust game in the meantime, hoping that things will turn out for the better in the long run.

Peace out.