Yes, it was a simpler time :) There was a job position known as "webmaster" who was basically a god. User expectations were low because users didn't know what to expect. Everything was so new. Putting formerly locked-away resources like job databases and digital libraries online blew people's minds. And we imagined that we were building a utopia where everyone could publish, and information was free..

> Trying to make modern users happy with '90s era tech would be impossible and deeply painful.

Given my experience users can be delighted in 2019 by well-designed and lightweight UI built with just CSS and vanilla JS, instead of an overweight buggy SPA (usually built by engineers more interested by the code itself than solving the business problem in the leanest way). Source: I made that my business and I couldn’t be happier.

You're correct, but so is OP.

You're exceeding their expectations by providing less than they expected. That's easy to do when the user expects to be accosted by a slow loading page that comes onto his screen janky because of deferred stylesheets and 4 different Google fonts and 1.6mb worth of ads.

SPAs are often buggy, but you can’t honestly blame React/Angular for that. I’ve built and actively maintain a number of SPAs in React. With some care JS size and speed is very manageable even in mobile devices.

The thing that consistently kills site performance is ads and trackers. Of the sites I work on, GTM, Optimizely, FullStory, and other similar crap routinely are responsible for >75% of the JS weight and >90% of the HTTP requests. It doesn’t matter how much I prune our npm dependencies and tweak React to make sure it’s rendering fast—marketing is going to make the page suck and I can’t do anything about it besides generate page speed reports that the client will ignore.

I still make websites this way because no-one told me to stop. They can be made responsive to things like smartphone browsers which incredibly minimal changes. No complaints so far.

What kind of sites do you make? I’d imagine that avoiding things like react is fine for a lot of sites that just need a bit of form input here and there and some nice styling, but that anything relatively big with interactive pieces would fairly quickly devolve into a difficult to maintain mess without components. I’ve sort of been trained to think that, though, as I was just starting development right before libraries like React started to get big. I remember reading cs books and learning about how important encapsulation and modularity was and then feeling like I wasn’t really able to apply those concepts adequately in my really early web projects. React came along and seemed like the best answer. Do you do something different to organize code related to more complex frontend user interaction than forms/animations, or do you find that you just don’t really need complex frontend user interaction for the websites you make?

Most of the things I've made are not public-facing. I just try to keep things simple. My sites generally require page loads more than the average single page application, but they have the advantage of loading faster and working in nearly any browser, even super old ones.

Link or not real.

Please stop

:P

No, please continue.

What is old is new again.

Brutalism for President 2020.

It's not necessarily brutalism, I own a maximalist site that doesn't have any Javascript on it, only CSS, HTML and images.

With respect, I strongly disagree with your assertion that it’s the users demanding anything. Users are rarely asking for our bloated single-page apps; we just foist them on the public because we think JavaScript development is fun and cool. That’s not how we rationalize it to ourselves, of course, but it’s the truth. The majority of web sites (all newspapers, all magazines, many less trafficked social media sites, I could go on) would be served just fine with HTML, CSS, and minimal to no JavaScript.

If there were no JS, how would anyone make billions of dollars of ad revenue?

That was... really interesting to read with a early 2000's mindset (seeing the date of the article)

Pinboard is also a good example of this.

> the simplicity of it all

> No React

True, but when I remember how we used 1x1px Java applet to allow reloading data without refreshing the page I would not call that simpler... And don't even get me started on Flash.

> no REST API

True, but when I remember fumbling about with SOAP I would hardly call that simpler...

> no microservices

True, but what we had instead -- monolithic PHP "applications" with insane hacks to integrate with other monolithic services, Microsoft' and Adobe's attempts to abstract the backend/frontend separation away and so on -- I would not call that simpler...

> no Docker, no Kubernetes

True, but when I remember the deployment mechanisms (upload via FTP), problems with scaling once our server became not enough (usual approach: set-up everything on a separate machine and then have a downtime until it was back up) and so on, I would certainly not call that simpler...

There are always trade-offs, and you continuously have to learn new technologies and unlearn others...

Interesting. There were two primary triggers for me creating https://alchemist.camp. One was that the Elixir screencasting I'd used site had very out-dated tutorials that often didn't compile or run on the post 1.0 versions of the language. The second was that I loathed the huge card-based design and the SPA the author moved to.

I just wanted information density and scannability, not hamburger buttons and pages and pages of responsive cards.

Similarly, I'm no fan of Reddit's redesign or the huge lag when loading IH and yet more and more content sites are going the same direction.