[zeroCalories]

I agree that the problem is product development, but the framing is wrong. Engineers generally have a solid intuition for what will perform well, but when UX designers and PMs with only a vague idea of how these technologies work dreams up an idea, gives a deadline, then the engineers are evaluated on fulfilling those metrics, then the outcome will be obvious.

[torginus]

I disagree - it's often engineering's fault. It's been pretty consistent that a decently specced server, running PHP that was written sometime last century, generating static pages, redis cache in front, and serving static content via nginx, beats the everloving pants off whatever fotm microservice SPA monstrosity modern devs tend to come up with.

The most hilarious if you go to pirate sites (for stuff like comics, manga or movies), and it's 100x faster and works better than the official paid for alternative, even though I'm sure the former runs off some dudes former gamer PC in his bedroom.

[extraisland]

A lot of companies seem to architect their web apps to deal with millions of users. When in reality they may have a couple of hundred hitting the site at once.

This explodes the cost of development and it makes current web development miserable IME.

I am forced to deal with everything being totally overengineered when a Flask app with a PostgresSQL backend could probably do the job on a reasonably priced VPS.

[torginus]

I used to work at a boring mid-sized finance-y company a while ago. Our stack was full Microsoft - IIS,ASP.NET,MS SQL, plus some appliance doing load balancing/API throttling stuff (not sure, not a sysadmin guy). The whole thing fit in a closet, handled 10k+ requests day and night.

All our code was basically - check user auth - do some stuff with the db/perhaps call out to some external service - serve request.

I never saw a single request above 50ms, with most being way less. Nobody ever talked about performance.

Then I moved to a fancy startup. EKS, nodejs servers, microservices of every denomination, GraphQL, every fashionable piece of tech cca 2018. I realized node was shockingly slow, and single threaded to boot, all that overhead added up to requests with a median latency of about 200ms, with the 99% latency measured in seconds.

Performance engineering was front and center, with dashboards, entire sprints dedicated to optimization, potential optimizations constantly considered, adding fake data and suspense to our React frontend, to hide latency etc. It was insane.

[extraisland]

This has been my precisely my experience. There are lots of odd gotchas when working with these fancy stacks and the platform themselves often don't provide much benefit.

[ben_w]

If it's done right, "millions" of users is something you can serve on racks of machines specced from the late 00s with all the commensurate sysadmin tools.

It's just that "done right" means the web pages are actually crafted to be what they need, and there's none of the modern extras like 1850 ad tracking agencies all being copied in, nor an ad server injecting just about anything…

[sgarland]

They cosplay as architecting them that way. IMO, one of the largest negative consequences to EverythingAsAService is that it allows people with little to no experience administering and tuning systems to run complex pieces of software. Sure, you can go spin up a managed Kafka cluster with a few clicks, but that means you can skip reading the docs, which means that you likely have no idea how to use it (or even when you should use it). Case in point for that: the number of people who think Kafka is a message queue.

This is also a huge contributor to the curse of Full Stack Engineering. “Full Stack” should mean that you have significant experience with and knowledge of every system and language you’re interacting with (I’ll give systems administration a pass for the sake of argument). For most web apps, that means frontend and backend, as well as some flavor of RDBMS, some flavor of caching, and likely a message queue. It likely also means you need to understand distributed systems. The number of developers I’ve met who tick all of those boxes is zero. Honestly, as soon as you include an RDBMS, it’s game over for most. Yes, you can get away with horrible things via ORMs, but as soon as you start hitting scaling limits, you’ll discover what people have known for decades: databases are tricky, and chucking everything into JSON columns with UUID PKs isn’t a good idea.

[extraisland]

> Engineers generally have a solid intuition for what will perform well

I worked for about 15 years as a frontend developer. I've seen very little evidence of this being the case.

I've seen a huge amount of developers (backend, frontend doesn't matter much) will do things that are really dumb e.g. repeated look of values that don't change often, not trying to minimise roundtrips.

[RajT88]

Totally agree. I did a lot of work with an eCom site (a big one; you probably see their brand name daily) for about 5 years and latency mattered a lot to them. Any extra latency was deadly, and they freaked out about latency going up by 100ms.

So then you load their site - unbelievable garbage, tons of pop-up ads for promos, video frames all over the place, high res graphics, megabytes of javascript.

The backend just as messy, with dozens and dozens of layers that made the latency budget by the time you reached the database backend super slim. Think: orders dropping when database request latency hit 10ms at the 99th percentile.

Insanity.

[cosmic_cheese]

And don’t forget that once the engineers are done, a nice thick layer of analytics junk is slathered on, plus whatever layer that allows marketing/sales to make arbitrary changes at will without code. By the time you’re done with all that even the best engineered web app has become a behemoth.

There’s are a few cases where the engineering side isn’t helping things though, like how the Spotify desktop app loads a full redundant set of JS dependencies for each pane since they’re each independent iframes, which they do so the teams responsible for the panes never have to interact.

[ben_w]

It's not just that. I've seen plenty of technical talks where people are showing off (and a few jobs where we were required to use) stuff that's several layers of abstraction more complex than it needs to be.

Right now, I'm converting some C++ game code that is very obviously originally meant for a 68k mac (with resource forks etc.) into vanilla JS. It's marginally easier to work with than SwiftUI + VIPER, and I'm saying that as someone who has been working on iOS apps since the first retina iPod came out and has only 14 months experience of C++ and perhaps about that, perhaps a bit less than that, total experience of JS since getting one of those "lean foo in 24 hours" books from WHSmith using pocket money in the late 90s.