Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React.
Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly.
There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by default at the beginning should be seen as unnecessary complication.
Especially because it's 100x easier to move from html+css to a framework than it is to move from a framework to literally anything else.
Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer.
Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static.
I think what you’re really complaining about is that people use React for static content and don’t statically render it first. That is sloppy, I agree. But it’s not React itself that’s the problem but rather the developers who don’t care what they are doing.
HTML will be around long after React is dead. What guarantee does a React codebase have that its toolchain will still work in 5 years? We've seen build tools come and go, whole approaches deprecated. What if a security update requires upgrading to a non-compatible version of React, therefore necessitating a considerable refactor?
Meanwhile, the original Space Jam website still renders perfectly.
The standards are superior to the frameworks built on top of them. Abstractions come and go, but web standards, once adopted, have a solid track record of sticking around.
In theory, you can completely statically render everything. In practice, every static site I've seen built with React also uses dynamic client-side components, either as a prerendering mechanism, or because there are dynamic toggles and things on the site that are easiest to build as React components. This usually means that a lot of excess Javascript gets loaded on the client that isn't usually necessary.
The islands/RSC work seems to offer some improvements to this, but most of these websites still include a full copy of React on the page to essentially do what the speculation rules API and a `<dialog>` element could do just as easily.
You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that.
But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyperlinked webpages, and you often know that right away, even when you don't have many details sorted out at all.
I'm not suggesting building a complex system from scratch. I'm suggesting building systems using tools designed to support the kind of system you're building.
Do you think your quote is true in all cases? Or are you implying that choosing to build using a framework implies building a complex system frame scratch?
Consider a different kind of system. Does every triple-A video game evolve from a simple framework-free implementation, or do most of them choose a graphics engine to build on top of? If a game studio chooses Unity from the start, for instance, is it building a complex system that won't work?
How is it any different to choose a web application framework from the start when building a web application?
You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.
Yes but if it turns out that you really are building an application, but you didn't think you were up front, it is likely that you started to add "just a little bit of js here and there", because after all each little thing you're doing is not that hard and it feels silly to block any one of those little things on "let's add a framework now". So then you find that you have a "non-framework JS" application that is hard to migrate. That's how path dependency works.
It's true that there is path dependency in the other direction. You implement a framework up front, but then it turns out you're making something too simple for that to really be worthwhile. But very similarly, no individual thing you're doing is a forcing function to simplify things, so you keep doing your simple thing with an overly complex tool.
It always strikes me that people want there to be one right answer for how to start a project, either always choose a framework up front, or never do that. But in my view it's just not that easy, you have to think about what you're doing and make the right decision for that thing.
And if you can point me to an example of that I will happily lampoon them.
If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top.
All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.
