“If you use React, you should be using a React framework.” | Hacker News Reader

“If you use React, you should be using a React framework.”

twitter.com

24 pointsromellem53 comments

For another point of view, the Solid.js author prefers advocating for better modular tooling (like Vite) rather than comprehensive monolithic frameworks.

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.

I suspect that OP is indirectly if not casually admitting that react core is bad or terrible DX. Can we discuss technicalities of our decisions and not just shill react frameworks?

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.

The one reason I am still interested in React for my side projects is that react-three-fiber exists. So far I have avoided using competitive frameworks because I use React at work and really mastering it makes me more productive globally than being a dilettante at Vue or Svelte.

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.

I think the discussion comes from the view that React has not had any server side framework and that may be very useful. A lot of the comments fail to differ between client side and server side tech.

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.

A lot depends on the complexity of your application.

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.

Honestly I'd argue you don't. I like the explicit nature of top down state and passing down actions via props because then you can see directly, via props, what mutates what. I've built quite sophisticated applications that involve financial forecasting, logistics planning, etc.. using exactly this technique.

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.

Is there any real content here? Its just "they're better" half a dozen times?

Well, this is just the common point that if you don’t use a framework you end up building your own poorly specified/documented framework. I’m not sure I disagree.

Agreed, Greenspun's tenth rule and all. You are shadowbanned by the way.

Personally, I can't go with this advice. We're on 2.5 years rolling our own, and it's been really clear that we made the right choice in not going with next.js, which was the only such framework at the time.

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.)

What was it about v6 that made upgrading not feasible? Curious about your use case if you can talk about it more.

We rely heavily on Redirect components, to support a "legacy" URL structure being forwarded to the current URLs. We are able to resolve these forwards server side during SSR. That whole feature was ripped out, with the suggestion that everyone just use the history API to redirect users, or write a whole bunch of separate controller logic in the server process. This, of course, was not a suitable substitute. When we looked at the "compatibility" plugin to help v5 users migrate to v6, they didn't include this feature in it at all.

https://gist.github.com/mjackson/b5748add2795ce7448a366ae8f8...

Philosophically, he just decided that there was no value to a Redirect component.

But React is a framework, itself built upon HTML, CSS and JavaScript. Recommending to use a framework on top of a framework is madness. If React doesn't do what's needed, just make another new framework instead.

React is a UI rendering library. They’re pretty explicit in their docs that they are not a framework

I don't know a ton about Andrew Clark; I've gathered he's an author of React, but what is his experience using React to actually build frontends?

Nah. The beauty of React is in how small and focused it has remained. This leaves developer choice to add (or not) as much complexity as your app needs. Framework lock-in is the nightmare route that Angular went down, and Next.js in particular is a bloated mess I wouldn't touch with a ten foot pole. The promise of these frameworks is to solve every problem for you, but the reality is that each one is half-way solved poorly.

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.

I dunno…. Hooks are something I didn’t ask for. The good news is that the React team seems to have painted themselves into a corner so development is slowing down and they won’t be introducing more bad ideas.

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.

> Hooks are something I didn’t ask for.

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.

Personally I know how to do very complex things with class components and make them reusable but that's because I have been doing object oriented programming intensively since 1994. (Kinda tried writing serial communication code in C++ in 1989 but I never really got OO until I got into Java.)

My perception of hooks is that nobody really understands them or what the real rules for using them are, but it usually works when people copy stuff out of stackoverflow until it doesn't. The fact that it is functions and not methods seems to make some people squee ("It's functional!") but it is pure insanity and not functional at all because the order that hooks get called matter.

Why do you think Next.js is bloated?

Can someone tell me exactly why I would need Next.js? SSR seems pointless for most apps and routing is trivial with react-router. What am I missing?

It’s mostly just those 2 things. SSR, routing, and having them work together nicely.

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.

SSR is fairly desirable for some apps, especially ones that have parts that have significant static content. That might be linked to from elsewhere. Think like a blog.

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.

Building something like a blog or ecommerce site where SEO is important, yet you still want to use some JS here and there for interactivity. It's basically PHP but better, due to a typed language like TypeScript, and having composition over inheritance (components vs classes/mixins).

I'm having a hard time understanding why. You need like 3 or 4 libraries to have a pretty featureful experience with React (routing lib, some kind of HTTP client library most likely, state if you don't want to do that in React proper... probably some kind of form library unless React has stopped sucking at that since last time I used it) and one of those is React itself. You can add more if you want but you probably don't need them. When one of those libraries falls out of favor and goes stale, it's easier to replace one of them than to migrate to a new framework.

There's just not enough to do on the client-side to justify a framework. The browser handles so much already.

I am impressed with the form features in HTML 5. You get progress bars for free and don’t have to fight npm to manage a 3rd party library that inevitably is going to have some weird ideas about styling things with CSS.

The React framework has a framework called framework?

React continues to describe itself as only a library, and IMO that's still all that it is. The author argues this point:

> if you choose to forgo a framework, what you're really choosing is to build your own bespoke framework

It's hard to take the "library" claim seriously, when React has its own source code language that needs to be compiled to be used in any practical way.

JSX predates React, React does not require JSX; it's not "its own source code".

Bootstrap was written in Less, that needs to be compiled. Is Bootstrap a library?

Approximately no one uses React without JSX. Probably because writing react that way kills a lot of the utility of it.

It's possible to use only the built output of bootstrap as a static CSS file. The nature of react is that your own code is in the other language, so it's fundamentally different than the bootstrap situation.

I think it has more to do with JSX being really good, rather than killing the utility of it.

I mean, JSX is fine. (mostly) But the fact of its existence, and ubiquity of its use shows that, as it's actually used, React is much closer to a framework than a library. It has a step in the build. That's not library behavior.

Fine, let's call it a "framework". Then I still think the was it's actually used is with another "framework" (and it's annoying)

The better argument is that JSX is just syntactic sugar. It's just Javascript driving around in a fancy HTML-colored car.

React is pretty hard to stomach without that sugar. It's practically pretty hard to use without. The way it's actually used in the real world (with JSX) it doesn't quack like a library.

> It's possible to use only the built output of bootstrap as a static CSS file

Correct, it "needs to be compiled to be used in any practical way". That was your criticism of React, and the reason it didn't qualify as a library.

Bootstrap was written in Less, that needs to be built. Is Bootstrap a library?

No, JSX was created by Meta (Facebook) when they developed React. It dos not predate it.

A framework framework?

Greenspun’s Tenth Rule is evergreen:

Any sufficiently complicated framework-free program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.

I feel like this is very much a political tweet more than a technical one, there's incredibly valid cases (as seen throughout this thread) for not using a framework, and it's a pretty broad generalization to make.

I just use vanilla React and Redux, but mostly for lack of knowledge. What would people recommend for:

- chrome extension

- simple app that is a small step above Retool/AppSmith

Are there frameworks people recommend that don’t require JavaScript on the backend?

I maintain that React is the single worst thing to happen to front end development. Certainly for the poor end user.

Protip: you can turn your hate posting & rage into something interesting & useful by explaining why. Use your anger!! Dont waste it.

Beautifully said.

Sorry, you're right. I hate it because I come across so many broken SPA sites, the vast majority of which would be better as a page of server-rendered HTML. I can only assume that these sites are tested in a clean browser on a clean network and with no browser plugins installed - the number I've come across that are non-functional just because I have Google Analytics / Tag Manager blocked is quite something.

Well, with more SSR frameworks like NextJS coming in, you can get your server side HTML and the developer can use the DX of React. This is what I do, since I too dislike SPAs but love the DX of having components, as well as incrementally being able to use cool libraries like framer-motion and react-three-fiber for progressive enhancement interactivity, so the page works fine without JS (since only HTML is sent over the wire) and for those who have JS on, they can use more enhanced features like interactive elements.

Couldn't agree more.

This is a weird take, since most end users have no idea what React is. They just access websites (always have, will continue to do so).

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.

Generally I don’t complain about React apps I use, but I know how the sausage is made (I make them) and my guess is users are getting worse apps than they could be getting because of all the half-baked hacks that go into React apps. It is not just React but the tower of complexity that gets pulled in.

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.

Java applets maybe?

> 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.

Definitely XMLHttpRequest becoming available to JavaScript in 2006.

Reply on news.ycombinator.com