4 ms·

I think the charitable interpretation is there are a whole class of web sites/applications (news sites, e-commerce, etc.) that haven't appreciably changed in th

I think the charitable interpretation is there are a whole class of web sites/applications (news sites, e-commerce, etc.) that haven't appreciably changed in the last 15 years. Yeah, there's been some incremental improvement, but the core experience is the same. However, the versions today are generally resource hogs. It's not rare for me to leave a browser tab open and find it grows to > 2GB RAM. I had one hit 28 GB and it would have kept going if I hadn't killed it. One thing I miss on the M1 is the fan kicking on so I know when a browser tab has run away. I think the OP has a point. We've been building a massively complex ecosystem on a very shaky foundation. The web has indeed advanced, but most of the time it feels like duct taping something onto this monster of a creation. Between backwards compatibility and competing browser vendor concerns, it's hard to push meaningful change through. So many security (especially supply chain) and dependency issues in JS would go away if there were a reasonable standard library. But, there isn't, so we're doomed a large graph of inter-related dependencies that break regularly. The constant churn in frameworks is mostly related to novel ways to work around limitations in the web platform and bridging behavioral differences across browsers. It's more than just churn in frameworks though. It's depressing how many person-years have been spent on build systems and bundlers or CJS vs ES6. Participating in the open source ecosystem means needing to be familiar with all of it, so it's not enough to pick one and run with it. Prior to flexbox, people struggled to center content with CSS; it was bad for layout. There's a ton of old CSS out there, much of it accomplishing the same thing in different ways, often with vendor-specific options. You still run into this if you have to style HTML email. Given the difficulty in mapping CSS back to its usages, it's incredibly challenging to refactor. It requires familiarity with the entire product and a lot of guess work to intent since comments don't exist. Moreover, there have been massive changes in "best practices". React and Tailwind violate the previous principles of unobstructive JS and semantic naming that were the prevailing practices not too long ago. My cynical take is a lot of that is driven by consultants looking to stand out as thought leaders. Regardless, it adds to the complexity of what you need to know if you do have to work with older (often other people's) code. I'm fairly confident that if we had today's use cases in mind when designing the foundational web technologies we'd have a very different platform to work with. It almost certainly would be more efficient, less error-prone, and likely more secure. It'd be nice if we could take a step back and revisit things. A clean break would be painful, but could work. Developers are already building web apps that only work on Chrome, so much as it pains me to say, having to get all the vendors on board isn't entirely necessary.

solarkraft 3y ago
> React and Tailwind violate the previous principles of unobstructive JS and semantic naming that were the prevailing practices not too long ago. My cynical take is a lot of that is driven by consultants looking to stand out as thought leaders. You're missing that people are adopting this on their own because they enjoy the benefits during development. This is also my explanation for why apps with the same complexity as 15 years ago are now slower: What Andy Giveth, Bill taketh away. Developers (or rather their management) are choosing to make "lazy" trade-offs, i.e. prioritizing programmer productivity over execution performance. Which makes economical sense. I wish there was a way to shift the economic incentives because that would change things very quickly. Maybe some browser performance limits.
ttfkam 3y ago
The point you appear to be making is the same point made at every step in computing history. It's an old and predictable refrain going back to assembly programmers complaining about the laziness and bloat of C development. Yes, bad software can suck up all your RAM and CPU time. This was a concern on the family's XT clone with 1MB of RAM. The only reason the bad software back then didn't suck down 32GB of RAM was because they hit the system's limit far earlier than that. That said, there have always been efforts to reduce the overhead of individual apps. Docker for all its bloat was a dramatic memory and CPU boon over full virtualization. New languages like Go and Rust have much better memory profiles than Java and C# before them. Qwik, Svelte, and Solid are all worlds better in terms of efficiency than React and Angular. There are clear improvements and also clear highlights of waste within our industry as there has always been. But if you can only see the waste and bloat, you are sadly missing large parts of the whole picture. The truth lies somewhere as a mix of the two extremes, and the overall capabilities of the current landscape are unambiguously more advanced than they were 5, 10, and 15 years ago.
- nirvdrum 3y ago
  I think your summary is a bit too reductive. I laid out a fairly comprehensive list of issues that are unique to the JavaScript ecosystem and you highlight one point I made about wasting resources. I don't see as many parallels with the past as you. Certainly software has bloated. But, few application platforms are as difficult to optimize for as the web. Working with HTML fragments, the shadow DOM, reducing unnecessary renders, figuring out the most efficient way to find nodes, etc. are things you don't have to deal with with most GUI toolkits. The closest thing I've seen is avoiding a full window repaint by only painting a region that's changed. To tackle that complexity we keep creating new frameworks, but those often bring their own bloat. So, we create new frameworks. Any time a new framework comes out, there's a light-weight variant that follows (e.g., React and Preact). There's potentially money to be made by building an influential library or framework and I think that has had an adverse impact as well. The entire JS ecosystem is built around a commercial package management system. That's virtually unheard of. I guess Maven Central gets kinda close? My contention is that if we took a step back and re-evaluated the platform and added a real standard library, I posit we could cut a lot of this out. You could take everything that's good and make it better.

solarkraft 3y ago

> React and Tailwind violate the previous principles of unobstructive JS and semantic naming that were the prevailing practices not too long ago. My cynical take is a lot of that is driven by consultants looking to stand out as thought leaders. You're missing that people are adopting this on their own because they enjoy the benefits during development. This is also my explanation for why apps with the same complexity as 15 years ago are now slower: What Andy Giveth, Bill taketh away. Developers (or rather their management) are choosing to make "lazy" trade-offs, i.e. prioritizing programmer productivity over execution performance. Which makes economical sense. I wish there was a way to shift the economic incentives because that would change things very quickly. Maybe some browser performance limits.

ttfkam 3y ago

The point you appear to be making is the same point made at every step in computing history. It's an old and predictable refrain going back to assembly programmers complaining about the laziness and bloat of C development. Yes, bad software can suck up all your RAM and CPU time. This was a concern on the family's XT clone with 1MB of RAM. The only reason the bad software back then didn't suck down 32GB of RAM was because they hit the system's limit far earlier than that. That said, there have always been efforts to reduce the overhead of individual apps. Docker for all its bloat was a dramatic memory and CPU boon over full virtualization. New languages like Go and Rust have much better memory profiles than Java and C# before them. Qwik, Svelte, and Solid are all worlds better in terms of efficiency than React and Angular. There are clear improvements and also clear highlights of waste within our industry as there has always been. But if you can only see the waste and bloat, you are sadly missing large parts of the whole picture. The truth lies somewhere as a mix of the two extremes, and the overall capabilities of the current landscape are unambiguously more advanced than they were 5, 10, and 15 years ago.

nirvdrum 3y ago
I think your summary is a bit too reductive. I laid out a fairly comprehensive list of issues that are unique to the JavaScript ecosystem and you highlight one point I made about wasting resources. I don't see as many parallels with the past as you. Certainly software has bloated. But, few application platforms are as difficult to optimize for as the web. Working with HTML fragments, the shadow DOM, reducing unnecessary renders, figuring out the most efficient way to find nodes, etc. are things you don't have to deal with with most GUI toolkits. The closest thing I've seen is avoiding a full window repaint by only painting a region that's changed. To tackle that complexity we keep creating new frameworks, but those often bring their own bloat. So, we create new frameworks. Any time a new framework comes out, there's a light-weight variant that follows (e.g., React and Preact). There's potentially money to be made by building an influential library or framework and I think that has had an adverse impact as well. The entire JS ecosystem is built around a commercial package management system. That's virtually unheard of. I guess Maven Central gets kinda close? My contention is that if we took a step back and re-evaluated the platform and added a real standard library, I posit we could cut a lot of this out. You could take everything that's good and make it better.