But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements.

Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in terms of architectural design can it? We're in odd times.

Of course, it's easy to be a hater on the sidelines. I am guilty. Nextjs likely just does too much in it's own made-from-scratch clever way. use-client vs server is just out-of-the gate ridiculous. But then I suppose the real question is "well if you want isomorphic environment, how else are you going to do it?". My answers is "I wouldn't!" but then vercel and the powers that be seem to have won the mindshare of the product crowd. At least for now.

I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.

React _is_ a whole new way of thinking. Back in the days of jQuery it was very painful to stitch together web experience across HTML+CSS+JS. jquery provided much needed DX around utilities to navigate across these pieces. But it was still way too easy to treat HTML like your database and model user-state across a Frankenstein of server, json, html, and javascript.

React was a paradigm shift. "Screw it, everything is javascript." The web depends on js runtime, we know we're going to need it. It starts to makes the best future-forward sense to use the only full programming runtime available. From DX pov this was spectacular to speed up prototyping. And you can finally truly model state purely from data.

What followed was a huge a mess (redux), but I always say, what do we expect? The web is a mess, and it's great because it's useful. Humans are a mess!

--- VUE: similar to angular I just don't align with "super-powered html attributes". It just doesn't make sense as a mental model. Because it's _not_ HTML spec and HTML is not a programming language. The more powerful the framework gets the more we reinvent a pseudo-programming language _through_ HTML. Angular was full-stop a no-go when I first saw it's for-loops in HTML.

edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not relearning basic programming primitives in a made up _markup_ language.

my issue with angular is it's neither real html nor any programming language. its made up pseudo-programming language for no other reason than it fools people into thinking "it's just HTML". that's my gripe.

There's not a difference in capability of expression of the two models. It seems to be a purely aesthetic or comfort difference.

I guess different people like different things.

For example with any iterator/loop you may want to filter, or find, or transform. in ruby you have the entire Enumerable API to dig into or Array prototype for js.

a templating language would have to reimplement functionality one by one in an allow list.

it's just fatigue at that point, yet another API i've got to mentally track.

edit: of course if you export the view data "clean" before hand it compels you to not have intense logic in the view. I get that but after a decade+ in product, views are never pure, even just ability to highlight the active tab takes conditional and select logic in a loop.

I would rather that all the developers were "encouraged" to do the filtering and sorting in some kind of logic block rather than having an attractive footgun lying around that makes it easy to cram in one more last data adjustment.

To each their own I suppose.

Angular and vue's template language are no more made up than JSX is.

`v-bind:id` and `@click.prevent` are something else. There is nothing like this in JSX. It’s not HTML. It’s not JavaScript. It’s some other language.

The best library are the complete ones.

I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost certainly never be used except under edge conditions! Sure, React can do conditional components, but conditional hooks are just too much for us!"

I'm pretty sure this is also untrue. AFAIK React has never used that phrase (and at the very least, I can't find it anywhere official right now), it came from other people convincing newcomers that hooks aren't something more complicated like objects (comparing to class-based components). React has always treated them as special functions, hence always prefixing them with the word "use".

Yeah I think you're right

There are only two rules:

1. Only call Hooks at the top level

2. Only call Hooks from React functions

Per https://react.dev/reference/rules/rules-of-hooks

Not sure I understand the conditional beef, perhaps you can give example? I would assume if you want `if condition, useEffect(...)` you could simply replace with `useEffect(() => if condition...)`, no?

My conditional beef: in my app, users can choose between using the built-in mic for speech recognition or a 3rd party service (LiveKit). If the user chooses the built-in mic, I still must allocate memory for LiveKit's services because it's exposed as a hook, even if the user will never use it. This problem compounds - every option that I expose that uses a hook requires that I allocate memory for an option that may never be used. Also TTS - users can choose to use the phone's TTS, or a remote service, etc. Every option I offer, if the library exposes it as a hook (and they virtually always do), if I naively implement the feature, allocates memory for a hook that might never be used.

Fuck. React. Hooks.

My workaround is to conditionally render empty fragments. These fragments wrap hooks, which I then inject into the context. This makes it so I can conditionally run hooks. This is why I complained that React can handle conditional components, but not hooks. Concretely: https://pastebin.com/sjc3vXTd I'm using Zustand because god I need a lifecycle outside of React.

Y'know how people complain about how Async "colors" functions? Hooks are also a type of function coloring. And they don't compose with Async.

I think you actually can conditionally render a hook but that choice has to last for the entire rendered lifetime of the component. But that doesn't really help you when your user can switch between them.

All the oddness about hooks fall out of that implementation. They can only be used inside components because they rely on component state management, and having to be called at the top level is a simplification of "hooks must always be called in the same order the same number of times" (no conditionals or loops) because otherwise the setState index gets messed up and you're getting the wrong state back when it's called.

Just because you're in React land doesn't mean you can't still write regular old js/ts and hook in only when you need it. I imagine you'd do something quite similar in any other framework.

Some libs do not expose "vanilla" js/ts functions that I can call - e.g. `LiveKitRoom` https://github.com/livekit/client-sdk-react-native

It only takes 1 hook to pollute your entire factory pattern; the comparison to colored async functions wasn't spurious. Hook-only options seem especially prevalent in the React Native ecosystem (ironically, given the memory constraints of phones).

Of course, I could fork/go down to the native layer, but this just proves my point that React DX is hot garbage.

I do actually believe a more PHP/Rails-like programming model would be beneficial for React; Vercel just missed the extremely important detail in how Rails is so dang productive. Its not their decisions when it comes to HTML templating; its Active Record.

That is very optimistic. Most React projects never get to the optimization stage, and end up with seconds of rendering and transition delays that significantly harm UX. And the amount of time spent battling hooks, re-renders, compatibility issues, etc amounts to hundreds of hours over the course of a medium-sized project, thousands for larger companies.

I won't say most react apps performs like this. But it's what you will get if you ship a big react app without optimization at all.

Other framework mostly have a much saner default (for example, component without argument change does not re-render). So it will work well (not best though) even in large scale. But in react they are all opt-in.

It's not that hard to maintain API stability folks! Try a bit harder!

It's crazy that the best React DX is provided through Vue's community projects.

Well not technically switch, I never learned React properly because I didn't like it when it first came out and by the time I gave it a second look there were already a gazillion React devs so I just stuck with Vue.

Vue just seems much more intuitive and sane to me. Sane is relative for front end frameworks of course. Don't get me started on Angular I got PTSD and couldn't code for a couple of months from a large Angular project with an offshore team.

I do get the benefit of using these framework for teams, and they are nifty once you get what is happening, but I still scratch my head when I see all the steps and files to do simple things I used to bang out in a few dozen lines of jQuery.

There's like an escalation ladder in my mind:

- just write HTML

- statically generate the HTML

- dynamically generate the HTML

- dynamically generate the HTML at a smaller granularity (HTMX et all)

- augment your HTML with custom web components that have client side behaviour.

Only if you've exhausted that should you bother with something like React. And even then SolidJS does a much better job of it than react itself does.

So yeah, I am just not seeing it. Former (and perhaps future!) React.JS dev btw.

For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.

There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.

being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web"

edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.

So yeah, once there was a benefit for using the same language. IMO, it never was worth the cost. But it doesn't exist anymore anyway.

agree as a 10+ year customer facing product person doing tons of react.

In practice, at scale, in an ecosystem instead of a toy project, excessive choice is counterintuitively a bad thing.

It's hugely beneficial to have common ground and shared interfaces when integrating code from third parties, or collaborating across multiple teams.

> You can pick

A golden rule of large enterprise is that there is no "you".

As soon as there are two people working independently, not to mention different business units or teams, different choices will be made. Incompatible choices.

React is used in enterprise when teams need to move fast and break things (e.g. Microsoft Edge's UI after switching from Trident/Spartan/EdgeHTML to Chromium) and tend to be replaced with something else when dev teams / managers realise that they need to rebuild it anyway just to keep it maintained and/or gain more performance. (e.g. Edge "WebUI 2.0" moving their browser UI from react to web components)

Vue is used a lot in Asian enterprise markets.

It ran locally in dev mode just fine. Once I deployed it on CFP, the router broke. No errors in the console, it just didn't work.

If I'm forced to use Vercel to make a simple SPA work, which then forced me into paying for their service, that's the problem.

https://opennext.js.org/cloudflare

But this won’t support all framework features. The default expectation for Next.js is with a server runtime for SSR.

/snark

React router have completely bungled their marketing and PR, but they still make the best web framework out there

These things are adding up. Web would be much more pleasant without React. There are many better options out there.

React was never [1] fast [2] - that is one of the biggest misconceptions in frontend development in the last decade.

[2] https://css-tricks.com/radeventlistener-a-tale-of-client-sid...

[1] https://www.zachleat.com/web/react-criticism/

When I used react for the first time I cried with “where has this been all my life? It would have saved me years of work”.

Whenever I see claims like yours I always have hardcore doubts. React may not have “enabled” new things just like ai coding doesn’t “enable” new things … as long as you consider time to be in infinite supply. If you care about getting shit done, there is no comparison.

https://medium.com/@fulalas/web-crap-has-taken-control-71c45...

    Even as Next seppukus itself,
    people will likely just fall back 
    to React on Vite…

And Tanner is already a huge name in the typescript/react world, so I think there is actually a chance.

I think React by default is weird because most things don't actually need that degree of reactivity. Like, if most of the time only one thing is displaying or updating a value React just adds a lot of headache. And the amount of useEffect I see? (By necessity mind you) with the need for linters in order to figure out if you missed something in a dependency list.. I just think it's the wrong model for most projects

If Mcdonalds starts taking a backseat, it’ll because its no longer really good. And, to be fair: I’ve started to see this happen. Mcdonalds & Coca-Cola have totally taken over the food industry world, and they’ve proven to make quite poor nutritional decisions. All great empires are destroyed from the inside, not out, and I think its possible Coca cola could do this to Mcdonalds. But also even as Coca-Cola seppukus itself, people will likely just fallback to Mcdonalds on Pepsi (or, there’s Pepsi Zero Sugar that’s I think still under development, but might end up being big).