> So long as websites pretend they are documents, they will remain bloated poorly performing synchronous applications.
I disagree.
Most websites (99%) are just barely interactive documents with buttons.
The bloat we suffer today is because we ship them and design them as full interactive App when it's absolutely not needed.
Why this happened ? Because the current tooling make it easy. Not because it is the right design.
The "distributed application" is just a bullshit fashion of a time. very little applications require the current level of complexity compares to the features they give.
They are like they are because "create-react-app" and "npm install world" is easy.
I agree with you. However, making a great single-page app takes a lot of experience and work, a bit less so with current frameworks, but still. A lot of in-house SPAs are truly terrible, with bad performance and broken navigation, you wish the developers wouldn’t have bothered. Multi-page apps might be a bit harder to screw up as badly.
So maybe the user experience hierarchy goes something like: great SPA > MPA > average SPA?
This would mean there’s still a place for MPAs, at least with certain budget constraints.
> “However, making a great single-page app takes a lot of experience and work, a bit less so with current frameworks, but still.”
So what? Get experience. The days of a plucky developer throwing together some simple page he built over a weekend while reading a programming book and having that be good enough for millions of people around the world are over.
Users will require richer and deeper experiences and that will breed a demand for some developers who actually know what they are doing, and possess a vast experience to draw insights from.
It depends what the app is, surely? The problem is too many things that should just be displaying a single document instead produce a bloated SPA with worse usability. Medium is probably the archetype of this.
Once I lived in an apartment with a safe that had been locked open. It was a giant, heavy thing too large to move. The owners simply renovated the apartment around it.
Eventually I got bored and started playing with it. Since it was locked open, it was possible to start taking apart the door from the inside. Once the tumblers were exposed, I figured out the combination.
It was tremendous fun!
If anyone here is in a similar situation, I recommend cracking the safe. Building the robot seems like a nice bit of mechanical engineering:
- write a sax event based parser that scaled but was low level
- use a DOM parser with a fairly convoluted API. The combination of attributes and children makes for wordy accessors.
Both YAML and JSON provide formats that more readily deserialize into native map / list / string / number types which at the time was quite convenient.
Waterfall isn't an engineering methodology, it's an investment methodology. Engineering will mirror the interests of the capital. And sometimes capital wants to build the same thing again for a "safe" return, rather than building something new for a transformative return.
IMHO it's not actually a safe investment strategy, but I understand where it comes from.
