You're literally a stereotypical Hacker News commenter. I also find the modern frontend a bit too complicated but this is just an unreasonable statement.
Of all the problems I have with React, and I do have a few, JSX is not one of them.
If you are going to be using a language to generate HTML, you are either going with a component approach that wraps HTML in some object library that then spits out HTML, or you are stuck with a templating language of some sort. (Or string concatenation, but I refuse to consider that a valid choice for non-trivial use cases.)
JSX is a minimal templating language on top of HTML. Do I think effects are weird and am I very annoyed at how they are declaration order dependent? Yup. But the lifecycle stuff is not that weird, or at least the latest revision of it isn't (earlier editions... eh...). The idea of triggering an action when a page is done loading has been around for a very long time, and that maps rather well to JSX's lifecycle events.
> React alone provides little to nothing
Throw in a routing library, and you are pretty much done.
Now another issue I do have is that people think React optimizes things that it in fact does not, so components end up being re-rendered again and again. Throw Redux in there and it is easy to have 100ms latency per key press. Super easy to do, and avoiding that pitfall involves understanding quite a few topics, which is unfortunate. The default path shouldn't lead to bad performance.
> The concept of components and the idiotic life cycles
Page loads, network request is made. Before React people had listeners on DOM and Window events instead, no different.
Components are nice if kept short and sweet. "This bit of HTML shows an image and its description" is useful.
> Do I need to explain how much stuff can be packed in 400kb?
No, I've worked on embedded systems, I realize how much of a gigantic waste everything web is. But making tight and small React apps is perfectly possible.
And yes, if you pull in a giant UI component library things will balloon in size. It is a common beginner mistake, I made it myself when I first started out. Then I realized it is easier for me to just write whatever small set of components I need myself, and I dropped 60% of my bundle app size.
In comparison, doing shit on the backend involves:
1. Writing logic in one language that will generate HTML and Javascript 2. Debugging the HTML and Javascript generated in #1.
And then someone goes "hey you know what's a great idea? Let's put state on the back end again! And we'll wrap it up behind a bunch of abstractions so engineers can pretend it actually isn't on the back end!"
History repeats itself and all that.
SPAs exist for a reason. They are easier to develop and easier to think about. And like it or not, even trivial client side functionality, such as a date picker, requires Javascript (see: https://caniuse.com/input-datetime).
SPAs, once loaded, can be very fast and scaling the backend for an SPA is a much easier engineering task (not trivial, but easier than per user state).
Is all of web dev a dumpster fire? Of course it is. A 16 year old with VB6 back in 1999 was 10x more productive than the world's most amazing web front end developer now days. Give said 16yr old a copy of Access and they could replace 90% of modern day internally developed CRUD apps at a fraction of the cost. (Except mobile support and all that...)
But React isn't the source of the problem, or even a particularly bad bit of code.
> Throw in a routing library, and you are pretty much done.
Ok routing library, now make an http request please without involving more dependencies....
> Throw Redux in
See, exactly what I said: we are getting to the endless pages of dependencies.
> 100ms latency per key press
100ms latency??!?!?!? In my world 100ms are centuries.
> 1. Writing logic in one language that will generate HTML and Javascript 2. Debugging the HTML and Javascript generated in #1.
I don't have a problem with that. At the end of the day you know exactly what you want to achieve and what the output should be, whereas react it's a guessing game each time. We are at a point where web "developers" wouldn't be able to tell you what html is. With server-side rendering, from maintenance perspective you have the luxury to use grep and not rely on post-market add ons, plugins and ide's in order to find and change the class of a span.
The term SPA first came to my attention when I was in university over 10 years ago. My immediate thought was "this is retarded". Over a decade later, my opinion hasn't changed.
> jsx is a retarded idea because it adds an abstraction over something brutally simple(html).
what programming languages do it better?
one of reacts greatest boons, it's greatest innovations, in my mind, is that it gave up the cargo cult special purpose templating languages that we had for almost two decades assumed we needed. it brought the key sensibility of php to javascript: that there was no need, no gain, by treating html as something special. it should be dealt with in the language, in the code.
if you have other places that have done a good job of being ripe for building html directly, without intermediation, as you seem to be a proponent of, let me/us know. jax seems intimately closer to me to what you purport to ask for than almost any other language that has come before! your words are a vexing contradiction.
> Ok routing library, now make an http request please without involving more dependencies....
please stop being TERRIFIED of code. many routing libraries with dependencies aren tiny. stop panicking that there is code. react router v6 for example is 2.9kb. why so afraid bro?
this is actually why the web is good. because there are many many many problems, but they are decoupled and a 2kB library builds a wonderful magical consistent & complete happy environment that proposes a good way of tackling the issues. you have to bring some architecture in but anyone can invent that architecture, the web platform is in opinionated ("principle of least power" x10,000,000), and the solutions tend towards tiny.
redux is 2kB with dependencies as well.
Yup that's crappy. The ease of it happening, the Work At A Startup page used to have this issue (may still, haven't looked lately) shows that it isn't hard to make accidentally happen.
As I said, it is a weakness of the system.
> sx is a retarded idea because it adds an abstraction over something brutally simple(html)
Have you seen how minimal of an abstraction jsx is? It is a simple rewrite to a JS function that spits out HTML, but JSX is super nice to write and more grep-able than the majority of other templating systems.
I have a predisposition to not liking templating systems, but JSX is the best part of React.
Notably it doesn't invent it's own control flow language, unlike most competitors in this space.
> My immediate thought was "this is retarded".
Well the most famous SPA is gmail and it's rather popular, you may have heard of it. It is bloated now, but when it first debuted it was really good. Webmail sucked, then suddenly it didn't.
Google maps. Outlook web client. Pandora. Online chat rooms, In browser video chat, (now with cool positional sound!)
SPA just means you are just fetching the minimum needed data from the server to fulfill the user's request, instead of refetching the entire DOM.
They are inherently an optimization.
Non-SPAs can be slow bloated messes as well, e.g. the Expedia site.
> My immediate thought was "this is retarded".
It's generally frowned upon to use retarded in this manner. Not only is it insulting to people, it brings down the overall tone of your argument.