You have to define "worse". What is actually "worse" is paying developer time to sit there in a never-ending upgrade and deprecation cycle when your core product is elsewhere.
Gen 1 wasn't Gen1. Gen1 for dynamic websites was a lamp stack with yolo javascript in the php header. Then people really started using jQuery because targeting a bunch of browsers at the time was a huge incompatible mess, along with other tools like modernize.js . Then your gen 1 started in earnest, if I remember correctly.
I remember the divisions slightly differently . There seemed to be a core movement from Ember.js and backbone onto Angular. Then from angular to react. Now I am seeing some movement off of react onto alternatives like Vue and Svelte, but almost everyone still is using react. Most shops have issues with the React part of their stack. It's still hard to get buy in for the alternatives in production. No one is using web assembly or even knows what a web component is.
I disagree about the comment about not going wrong with either. This assumes you or your team have the time to maintain the stack with the large amount of dependencies, as there are security patches often and deprecations often. It's a waste when it seems like a large portion of the actual market is just creating dashboard products. You can handle this with a much lighter frontend if you can get buy in (you can't).
I am not sure this is true . As I wrote elsewhere, almost everyone wants a web app or thinks that they have a web app, but usually it is just a dynamic website. You do not need to build up a framework to have a dynamic website.
Everyone thinks they have a web application but a lot of the React I get asked to build could have easily just been a dynamic webpage (it is usually a dashboard). I think there is an over-emphasis on what constitutes a "web app".
Alright, I've been in the industry a very long time but moved to backend when it got complex. I am wondering why you need a decent hash map or set implementation. This is supposed to be done on the backend. The frontend is for presentation. Your backend should not give you elements with duplicates (why you don't need set). "Decent hash map" sounds like you just don't like the hash map implementation because you are trying to do something complex with the Map implementation, in which case it belongs on the backend.
I remember when I used to run gnome 2 (i.e. mate) on a machine with 256mb of ram. It was a full experience and it worked with youtube videos and so on. What are we even doing .
Sure, back when videos were at most 480p/720p that's feasible.
I'm not saying software is any more efficiently written these days but I do think it's important to recognize that just the act of pushing more pixels on its own requires more RAM.
Honestly, no. Prior to 2009 there were almost no 720p videos on the platform. In 2009 Windows 7 came out with a minimum requirement of 1GB RAM (Vista in 2007 also already recommended 1GB). What I'm trying to say is, 1GB wasn't much even before 720p got common. The amount of people watching 720p on systems with less than 1GB has likely always been minuscule.
I was just thinking "there is no way this person works on embedded devices". Then I read the last paragraph where you bring up "over 1GB of RAM". Explains that.
