Every JS frontend dev I met was speedrunning trying to prove himself by "inventing something new" which in fact was already a state of art.
The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering.
TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
This is true at every layer of software development.
> TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
I don’t think I could disagree more. JS is a tool, swapping it out doesn’t remove the unique problems of front end development.
Let’s say we switched to python for the FE. The team wants to use numpy for some of its features. Bam, 30 mb being sent over the wire for one library. What do you do? You decide that’s unacceptable and start extracting the functions from the library you are using. You realize that these functions are useful enough on their own and publish them separately on pypi. You describe the library as fast and only 1kb.
Then someone else comes along and decides this is a tedious task to break up all these libraries and publish small functions as packages. They figure out a smart way to tree shake the library so only the code used gets sent over the wire. Do you see where I’m headed here? In 5 years the python ecosystem for FE development will look shockingly like JS of today.
Your solution does not resonate with me because it does not address the core problems of FE development. The tool isn’t the issue, it’s what the tool is trying to solve for that is the problem.
It’s more fun to write code and make stuff up than to find and evaluate libraries (especially when said libraries are written by self-taught devs), so people tend to reinvent rather than research.
Javascript was never the problem. Today there are bazillions of solutions using another language for the people who don't want to hear about Javascript. The problem is all the DOM and WebAPI available to the developer. You can potentially interact with all that in C++ if you wish, but you'll always be limited by the exact API as Javascript in the browser, by design.
Fundamentally there is a mismatch between how the DOM works and how most people develop complex interactive UI, switching to another language doesn't solve that problem.
JS is just not good enough for what we want it to do.
Someone sooner or later has to make a decision to move further.