I think it is an interesting exercise to think about the worst thing to happen to web development in the past 20 years, but I don't think I have an answer for that right now.
In theory you could find a nice widget set and have components like a desktop app framework like WPF or Java FX but often people wind up with several different component sets, each of which has an idiosyncratic approach to CSS or something just plain psychotic like pre-grid layout bootstrap.
On my own account I make apps that are not JavaScript heavy unless I want to do something exotic like use three.js.
React has the strong advantage that it is easy to make video game like animations that work over the application globally, but I think it is a strong minus for most of what management really values…. That is, having an application that works, having it developed quickly, being able to update it quickly.
Definitely XMLHttpRequest becoming available to JavaScript in 2006.
> if you choose to forgo a framework, what you're really choosing is to build your own bespoke framework
Any sufficiently complicated framework-free program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.
What works best for JS is the "meta" framework approach. That is, collections of really well done libraries that solve one single problem extremely well and play together nicely without any actual knowledge of each other.
In principle I like the virtual DOM and how you can use components much like in WPF or Java FX but React does not have a good story for complex applications where data flows sideways, not just up and down.
I did. Reusable components with lifecycle events were a pain. Now if I want to add some complex lifecycle logic, I can package that up into a neat, tidy function (which is all hooks are, stateful functions) and call it.
In my experience, many people who don't see the value of hooks have never experienced the pain points that they solve, or they're just newer to React and have never dealt (extensively) with class components.
On such a site SSR not only can mean faster time to content for new viewers (especially with server side caching, but even without your server may well be faster than a low end mobile device), but it also means that some basic sight functionality like navigation might even work with JavaScript disabled. (For that, you simply need to ensure navigation uses `<a href="..."` tags, with JavaScript click handler that intercepts clicks and hands them off to the router. People with JavaScript disabled will make a server request, which will SSR the new destination and return it, which is better than having literally nothing work in that scenario.)
Indeed, next.js is really about allowing you to use react to make more of a classic server rendered site that supports progressive enhancements (client components), but using react just an SPA. They even prefer a server side router. This has advantages like the JavaScript code bundle downloaded by the browser being much smaller, as only the code for client components is needed, while all other components are server rendedered only, so don't need to be in the client bundle.
If in practice everybody comes to one url for your app, people come specifically to interact rather than for content (so time to content being visible is not an important metric, while time to interactivity is important) then sure SSR and next.js are probably not really useful for you.
You also get easy to use build/start/dev scripts which takes the hassle out of setting up your project, which is pretty nice.
That’s really all there is to it. It doesn’t handle things like state management or data fetching.
That thread is just a niagra of nonsense. The most impressive thing is how much OP mentions the most obvious things with such great profundity. "Gib ssr, gib routing..." thanks man. We can't read docs or landing pages it seems.
Lately though I have been using htmlx which doesn’t address all the problems that React does, particularly highly complex applications where an update can change other components on the page. It is easy though, when classifying things, to have a list of the 5 Last things so if the mouse clicks twice I can change the select and it posts to the server. I have a few htmlx features bolted on top of a system which otherwise would look like a web app from 1999…. And I can say boy is it fast.
Meta was probably using php for their backend and didn't need any server side part, hence 3rd party frameworks like NextJs and Remix. I've seen companies use .Net or other languages on the backend also, they are also less interested in a React server side solution but if it does not stop other server solutions from being used it may not hinder much either.
Given that the remix author complete broke react-router for our use case (to the point where we can't upgrade to v6), I wouldn't trust that remix could meet our needs, either.
(There is a temptation to fork react-router v5 and maintain it independently. But, we're good just pinning the version for now.)
https://gist.github.com/mjackson/b5748add2795ce7448a366ae8f8...
Philosophically, he just decided that there was no value to a Redirect component.
There are some simple React applications where you can keep the state near the top of the application and let it percolate into the components via props. (Like my app for controlling my smart speakers.) In a case like that framework can be part of the problem as much as a solution.
When you've got complex state all over the place and an update to component A's data can cause component B and C to update and particularly if the app is dynamic so you don't know when you're writing it exactly what will cause what to update than you really need a framework.
It also gives you the ability to use local state when it makes sense. You really don't need the intermediate state of a text input at the top level state for example.
There's just not enough to do on the client-side to justify a framework. The browser handles so much already.
https://twitter.com/RyanCarniato/status/1617623647803539456
It appears he considers SolidStart to be a concession to the current ecosystem reality, rather than the idealized version of how things should be done.
- chrome extension
- simple app that is a small step above Retool/AppSmith
