React was designed to solve all these problems. Now these problems are used to solve react.
Programming, like life, is a flat circle.
Programming, like life, is a flat circle.
Because the source was too complex.
Now we want to expose the source and get rid of the abstraction... Why?
Because the abstraction is too complex.
Recurse and repeat.
TypeScript ecosystem is the Enterprise Java of this decade, except it's built on shakier foundations, i.e. you can run some ancient JVM, but good luck relying on an ancient browser version & node dependencies. There will probably still be tons of job-security in the next couple decades, but it's not forward-looking technologically.
Ironically you mention the jvm which further proves the existence of the flat circle.
We've done it before... We will do it again.
At some point wysiwyg editors fell out of favor as they generated both unmaintainable styles and markup.
Style sheets took hold and the insanity that was inline styles were dropped in favor of external style sheets.
Today we have tailwinds.css and inline styles are coming back in vogue.
Wysiwyg editors are coming back in the form of code generators that convert designs into react components.
This author is even a proponent of inline event handlers which were the standard way of doing things before JavaScript really became a powerful language and added "addEventlistener".
Flat circle repeated over and over again.
Part of me wonders if these authors are just too young to remember those days. Otherwise why wouldn't they mention the historical context when writing these kind of articles?
It's funny when younger people espouse these new ideas as new and revolutionary when really they are a return to older patterns that fell out of style for whatever reason and are now being resold with different packaging.
Thus, History is doomed to repeat itself as software technology moves horizontally forever, with practitioners never knowing if the current abstraction was better than the previous one.
Top quote in the article
> I don't think computing is a real field. It acts like a pop culture, it deals in fads, and it doesn't even know its own roots. And worse than that it does not know about the really good things that were done in the past. — Alan Kay
React was designed to address complexities. It is an abstraction.
Now we want to go backwards. Getting rid of the abstraction to get rid of complexities. But getting rid of complexities was the whole point of react.
The purpose of react was to simplify the complexities of front end web development. Just like the purpose of the DOM was to do the same thing.
Now this article is pointing to going back to the DOM for a similar purpose. The cycle on the great circle of life occurs because we are repeatedly attempting and failing to fulfill the singular purpose of building a clean API for ui construction.
The dom was a failure, react was a failure. What do you think going back to the DOM will do?
It'll give me that extra 50% effort back. Although I've used React for years, I have never been on the bandwagon. Having built many React SPAs with different teams at this point I'm confident it has always been a step backwards.
By stepping back we are just going back to the same problem.
The next abstraction will attempt to solve the same problem again. Very likely in a similar way react failed, the next abstraction will introduce new issues and there will be another trend to go backwards again.
I'm saying we had problems with vanilla js initially and we've never moved forward. The fact that we are going back to vanilla js is reopening all the old issues are a sign that we are in stagnation.
Nothing has changed. It's a circle of attempting to improve and failing.
The front end UI isn't a collection of evolving standards. It's the same standard with more and more cruft added on top.
HTML wasn't designed for what we are doing with it now. Each additional layer... css, JavaScript, the dom, typescript, react, is a new layer over an old thing. It's like never buying a new car just modifying your old one from the 50s to stay up to date. That's why the entire front end API feels so bad. It feels disorganized with complexity that exceeds necessity.
The complexity of the spec even took years for browsers to get right. This is not a sign of good design. It's a sign of endless designs layered on top of each other all in vain effort to modernize everything and keep it backwards compatible.
You're right the dom will remain in the picture for a long time. Doesn't change the fact that it's horribly designed.
Facebook (rightly) said the VDOM was needed at because of rough edges around the performance of DOM implementations in assorted browsers. The DOM has improved over the past 15 years or so to the point where things like HTMX and AlpineJs are viable for more use cases. React and the DOM have not failed, they are tools that have their uses and limitations. Looking for one solution to rule them all is ultimately an exercise in futility and disappointment. Instead we should be looking at ways to integrate React and hypermedia so they interoperate more smoothly (e.g., web components or similar solutions).
>Looking for one solution to rule them all is ultimately an exercise in futility and disappointment
React and the dom were also exercises in futility and disappointment. They didn't seem that way at the time but as time went on it became clear what their problems were. The same thing can be said of htmx and alpine and whatever big framework that comes next.
Additionally who says their can't be one solution to rule them all? You think if your quotation eludes to some fictional story of lotr suddenly it makes sense? There is nothing in reality or logic that says we can create a design that can do better than all the apis that currently exist.
This idea that you can only male tools that do one thing well is fundamentally illogical. There are tons and tons of tools that do multiple things well. Take your car. It doesn't just get you from point a to point b. It air conditions you, it plays music... It provides safety, it gives you directions.
I don't think of it as "going backwards", so much as reassessing and questioning the tools we are using and using the best one at hand. I don't know of anyone who suggests using hypermedia for all applications, just use it where appropriate and use React when simpler technology falls short.