3 ms·

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 de

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.

cosmic_cheese 1y ago
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.
RajT88 1y ago
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.
torginus 1y ago
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 1y ago
  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.
  - ben_w 1y ago
    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 1y ago
    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.
  - 1y ago
extraisland 1y ago
> 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.
ben_w 1y ago
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.

cosmic_cheese 1y ago

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.

RajT88 1y ago

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.

torginus 1y ago

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 1y ago
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.
- ben_w 1y ago
  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 1y ago
  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.
- 1y ago

extraisland 1y ago

> 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.

ben_w 1y ago

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.