[onion2k]

So many more problems solved…

Those problems aren't 'solved'. The author has an implementation of a solution. It's one that they think is good, which is ace and I'm happy for him, but if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is the code so verbose?'

The massive advantage of a framework is that the people who choose it have agreed to share a solution to the common problems. This cannot be overstated - as soon as your team grows to more than one developer you move from 'solve the problem' to 'solve the problem in a way that people agree on', and that is far more complicated than just solving a problem. Sometimes you get lucky and work with people who think the same way as you, or with people who are willing to compromise on their ideal solution and accept yours, and then things still work, but if they're 'passionate' about being right then it's horrible, slow, and results in bad code.

A framework is an upfront agreement about how to build something. That has no practical advantage for a dev working alone. It's incredibly useful for two or more devs working together. Which framework doesn't really matter, except the ones with more devs behind them make it a lot easier to find people who've already accepted that way of working. That's helpful.

[Kon5ole]

>if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is the code so verbose?'

I agree with the problems you list, but I don't think a framework solves them. The same complaints can be made by the second developer because the first developer chose the "wrong" framework. Solved the wrong way, not covering the edge cases of your domain, too verbose etc.

Additionally a framework will likely be bloated and inefficient because they try to solve every problem for everyone, and you introduce a random breaking point where any framework update could in theory break your system.

[Rohansi]

> The same complaints can be made by the second developer because the first developer chose the "wrong" framework.

Exactly this. There's so much fragmentation within the browser ecosystem that there is no guarantee your second developer will be comfortable/familiar with what the first developer chose. Even if you went with React you could be using state management they don't understand, a styling system they don't understand, etc... Even if you choose the most popular everything at the start of the project there is a lot of churn where things eventually fall out of favour.

I'd also be skeptical of web developers who work with React but aren't familiar with vanilla JavaScript. It's probably a good indicator that they aren't the best candidate but we can't all be picky.

[bellowsgulch]

A lot of web development problems are solved. That's what this author and many other very experienced jaded principal engineers try to say year after year.

Because you think whatever you want to pretend your web software isn't MVC isn't solved doesn't mean it's true. Oh brother, MVVM, Model-template-view (no offense, Simon), come on.

You define resources on an HTML page, the browser loads them, renders a page, loads scripts, and makes AJAX calls.

You don't need build scripts for this. More over, these frameworks and build scripts DON'T SOLVE PROBLEMS. They move them. They want you to become a React developer. Not a software engineer who writes web software.

They don't solve routing, because you rewrite it every year. They don't solve bundling, because you change bundlers every year. They don't solve event handling, because they just move the chain of calls where you define the listener.

It's all a lie.

[winrid]

you just agree on a set of conventions for components and state management, it's not that hard. This is basically how Rails works...

yes it's still a framework, duh. it's just less abstraction than react etc.

[onion2k]

Sure, and if you like working with the conventions and abstraction Rails offers that's great.

Other people make different choices. That doesn't mean they're wrong.

[winrid]

To write good React you have to follow conventions, too. You can't get away from conventions.

People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".

[onion2k]

People keep touting react etc but I swear every mobile ordering app I use lags like hell..

I don't doubt it. People make terrible websites with React.

However ... what might be happening is that you go to some websites, and some of them are great and others are terrible laggy garbage. When it's a bad one you open up devtools and see React, and that leads you to conclude that React is bad. But reality is that the good ones also use React, because most big websites use it.

Your reaction to the good ones is to assume they're well-built using whatever tech you happen to think is great (Rails, Vanilla JS, Vue, Svelte... whatever) but you're not actually looking. Hell, a great website isn't even a website, it's the experience of interacting with the business behind it. You don't even think about the tech when the website is actually usable.

Your reaction to the bad websites is to look under the hood, and you often find React.

That either means React websites are bad, or that React websites are good or bad, and it's not really React that's the issue. It's the team who built the site (and often not even the tech team; there's often some Product or commercial pressure that's driving the team to release something that's not really ready yet.)

[winrid]

I'm not sure I'd say "React Bad", I'd rather say "React Not Really Super Necessary and More Often Than Not Leads to a Worst Experience at Maybe a Slightly Lower Initial Cost" :)

I did an experiment recently, I actually wanted to launch a dashboard and picked React because I knew I could throw React + Tailwind + popular_component_and_charts_frameworks at Opus and get a decent result. But actually, I realized a lot of fairly simple button clicks had like a 100ms-200ms delay, and I just did not like it. I ported it to Java/Javalin with J2HTML and kept tailwind, and it's very snappy and works great. It's currently 96k lines of java ^_^

[torginus]

I've had someone tell me to not bother with list virtualization under React, since the 'computer's fast, it won't matter'.

We shipped it like that. Turns out the computer's not fast and it does matter.

[winrid]

Your computer is fast and can display hundreds of thousands of divs a second. :)

[dcow]

So React is like C++?

[pkphilip]

Absolutely agree. I hate the state management mess in these frameworks.