XML is the future

Okay, campers, rise and shine...

Summary

My first hype exposure was "use the Extensible Markup Language for everything". Learning from it allowed me to live through the front end stack explosion, the micro-service overdose and many, many more silly trends.

It turns out Grandma was right. Eat vegetables, exercise, sleep well.

And use the right tool for the right job.

Well, she didn't say that last one.

But she could have.

Hype cycles

When I started programming, XML was going to replace everything. HTML with XHTML, validation with DTD, transformation and presentation with XSLT, communication with SOAP.

I missed the train on the OOP hype, that was the generation before me, but I read so many articles warning me about it, that I applied the reasoning to XML: let's wait and see if this is actually as good as they say before investing everything in it.

Turns out, XML was not the future. It was mostly technical debt.

It was useful for things like documents, and I believe the most successful use of it are still MS Office and LibreOffice file formats. They are just zips of XML.

I was lucky to learn this lesson very early in my career: there is no silver bullet, any single tool, no matter how good it is, must be evaluated from the engineering point of view of pros and cons. Everything has a cost, and implies compromises. It's a matter of ROI. Which is hard to evaluate without experience.

Bottom line, time is once again the great equalizer, there is no substitute to observe how a complex system evolves, no matter your model of the world.

But above all, I learned that geeks think they are rational beings, while they are completely influenced by buzz, marketing, and their emotions. Even more so than the average person, because they believe they are less susceptible to it than normies, so they have a blind spot.

And so it begins

XML was just the beginning of many, many waves of hype.

When MongoDB came around (it's web scale!), suddenly you had to use NoSQL for everything. Didn't matter that there was absolutely no relation between 2 NoSQL systems. It's like labeling a country as "doesn't speak English". Didn't matter MongoDB was a terrible product at the time that was destroying your data (they did fix that, it's now a good DB to have in your toolbox). Didn't matter that most people using it didn't need free replication because their data could fit in a SQlite file.

So we watched beginners put their data with no schema, no consistency, and broken validation in a big bag of blobs. The projects began failing in large numbers.

Then the node era arrived. Isomorphic JavaScript was all the rage, you had to use the same language in the frontend and the backend, and make everything async. But JS sucked, so most JS projects were created... to avoid writing ES5. I mean, no import, no namespace, terrible scoping, schizophreniac this, prototype based inheritance, weak types, come on! So we got coffeescript, then babel, webpack, typescript, react + JSX, etc.

We were told to stay on top of the most modern ecosystem, and by that I mean dealing with compatibility being broken every two months. That’s the price of cutting edge tree-shaking transpilation. That, and a left-pad way of life you couldn’t debug because the map files were generated wrong.

At this point, everything needed to be a Single Page Application with client-side routing, immutable data structures and some kind of store. That is, if you could chose between flux, redux, alt, reflux, flummox, fluxible, fluxxor, marty.js, fynx, MacFly, DeLorean.js, fluxify, fluxury, exim, fluxtore, Redx, fluxx… No, I’m not making that up.

But because you still had to pass a lot of data through the wire, and since everything had to be on the client, GraphQL was born. Of course, all that stuff had terrible accessibility, SEO and first-rendering time issues, leading to the rise of Server-Side Rendering, aka CGI with extra steps. This couldn’t stop there, so the community added hydration on top.

This turned out to be an immense addition in complexity, and created tons and tons of disposable code base, leading to, you get it, failed projects and waste of money.

Because, of course, most of those tasks could have been done with Ruby-On-Rail, Symfony or Django and a pinch of jQuery. At least, they would have been finished with those boring techs. Instead, dead projects began to accumulate, and for one Figma shinning, you had a trail of hidden bodies behind corporate walls nobody dared to talk about.

It was taboo to speak about this madness. You were the one not getting it.

It's a revolution!

You would think people drowning while trying to produce a basic CRUD app would have been a red flag.

Instead, it inspired teams everywhere in the world to make things harder on themselves.

First, the "everything should be a micro-service" crowd started to take over. Every single small website had a docker container for the restish API, plus one for the front end, and one for the database. Indirection layers on top of indirection layers. To communicate between all that, why not a little message queue? ZeroMQ, RabbitMQ... And a good exchange format, like grpc with protobuff.

Believe it or not, it became very hard to make your todo-list app work with all those, so a solution was found: adding orchestration. Docker swarm, and now kubernetes.

At this stage, so much time and money were obliterated the cloud felt like a savior: they will do all that for you, for a fee. You just had to learn their entire way of doing things, debug their black box, be locked in their ecosystem, and carefully optimize and configure - using state-of-the-art templated YAML files and hostile UIs - your entire project, so that you could only spend 10 times more on hosting, and not 10000 times by mistake.

Easy.

Second, big data arrived. You had to store every single click of your users. A/B test everything as well, so that you consistently annoy 10% of your customers and make support unbearable. Now the data you had was gigantic! And if it was not, you had to believe it, and you needed some kind of Dynamo data lake. Or maybe a time series db. Or a graph one. You needed something, that's for sure.

Third, all of that stuff was now very slow. It was not because of the terrible technical decisions leading to use Google level industrial architectures for your 100 request/seconds website, no. It was because you used a slow language. So let's rewrite everything in Go. Or Rust.

The compilation step is not going to have any impact on the feedback loop anyway, since the CI pipeline already takes 73 minutes.

That was the last straw, so out of tiredness, devs went back to simple ways...

Just kidding, they went in flocks to serverless lambda and SaaS services you call from the edge, cause not owning your stack is the future!

Building products you don't need

Meanwhile, while the blog posts about burn out were increasing tenfold, somewhere at the top, leaders heard the call of money.

You can't grow without making everything social.

Gamify, gamify, gamify.

Block chain will change the universe.

You need an AMP website.

Your stuff is not competitive without Machine Learning.

If you lived through all those, you know what remains about it: almost nothing.

A few "share" buttons and "login with" workflows. Some points and badges. Graphs.

Things either died, or filled the niche they were good at, as they should.

Some were replaced by the future of today.

Coming back to reason

I like the new hype: YAGNI is popular again.

Projects like Vue, HTMX and unpoly, alpine.js or just vanilla are getting traction.

There is talk of coming back to using Postgres for most things.

37signals is on the spotlight once more, because they left the cloud.

It will, of course, be overdone. Because minimalism being hyped is still... hype.

You do need the cloud, containers, nosql, go, rust and js build systems. Modern software requirements, customers’ expectations and incredible new features are not to be ignored.

Just not for everything.

Nothing is ever needed for everything.