Coming from a Rails background, it's pretty jarring. It's like the difference between being told, "Here's how you build a house" and "Here's how you use the tools in this toolkit".

React offers more freedom at the expense of guidance, and you get much less standardization as a result.

I think the root cause of this is react not really being a framework, rather just a library that allows you to write declarative code involving state that in the end, outputs a DOM tree. IMO it does that quite well.

It doesn't have very many opinions on how you should structure your code, how you should organize your state, how your routing logic should work etc. I think that's where frameworks come in. React was quite popular long before frameworks like nextjs, meteor, remix, ... became 'mainstream', causing lots of developers to invent their own (poorly maintained) frameworks.

I was shocked at how much time some teams spent on reinventing wheels rather than using some off the shelf components. "We need everything to be done in house so we can document it and have full control". But... designing all your own widgets is going to take months. "React makes it easy though, so don't worry - we know what we're doing' Yet... they didn't - untestable components that couldn't support what the original requirements called for months earlier, etc.

You know how people crap on PHP because there's so much 'bad' PHP out there? But others say "it's just how you use it - frameworks XYZ are great!". I feel the same way about React. There's probably some great examples out there, but I somehow tend to see a lot of lesser quality stuff.

Most of the use cases I've seen up close... there wasn't any real magic or benefit to React vs something else, but everyone was jacked to get more React experience on their resume for their next gig. It didn't really matter if the resulting output was good or not, just that they used React.

I don't hate React - it's a library. I'm tired of much of the B-team players requiring it to be considered "professional" (while simultaneously) eschewing testing and documentation).

For people who have chosen it, and get to stay on the same project for several years, honing their skills on one codebase and iteratively improving, great. Enjoy.

Drawing canvas: https://www.tldraw.com/

Code playground: https://replit.com/

Supabase dashboard: https://supabase.com/

Vercel dashboard: https://vercel.com/

Workout tracking: https://workout.lol/

Chatbot: https://chatgpt.com

Note-taking: https://www.usememos.com/

Tax filing: https://ustaxes.org/start

Python notebook: https://marimo.io/

LoL info: https://www.op.gg/

Sports matches: https://www.sofascore.com/

Trading news: https://seekingalpha.com/

Website builder: https://mmm.page/

Podcast maker: https://podcastle.ai/

The issue (and this isn’t React’s fault) is that every single web app is so obsessed with measuring analytics and engagement metrics and loading multiple ad containers and and and…

Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.

There is likely a bit of observer bias going on with your comment, as many popular sites these days run React and they happen to run like crap due to the reasons I listed above.

My assumption would be that if you haven't seen anything, even from the creator, then you just have different expectations to the people who do get value from React

refine: https://github.com/refinedev/refine appsmith: https://github.com/appsmithorg/appsmith

there are heaps what are you talking about!

> Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.

False dichotomy, and a somewhat strange one, given jQuery and React aren't even remotely aimed at solving the same problem?

You're free to stick to a functional paradigm in JS without requiring the overhead of React (and all the cruft that tends to pile up around React - build systems, compile times, masses of dependencies, the inevitable CVEs for those dependencies, etc.)

But more importantly, I'd respectfully note that you're pre-supposing that UI state rightly lives in JavaScript, which is a point of view already limited by framework-centric assumptions.

What's surprising to me is that React 19 seems to be doubling down on hooks, adding more cognitive load by increasing the number of hooks you need to be aware of and their particular behaviors and requirements. Doing that instead of moving toward the more universal reactivity model that MobX, SolidJS and even frameworks like Svelte 5 are starting to adopt.

>as for why I personally choose React was due to the job market

From my experience, this is the problem, and I don't know that anyone is to blame for it. React's success has created skill drift away from the web platform. When I first started as a web team manager, my new hires knew the fundamentals of web standards: html, css, js, and some libraries to make those easier to work with.

Now, most entry level web devs know some flavor of React, full stop. These aren't Bay area web engineers, these are the web mechanics that need to get into whatever is thrown at them and keep it working, or make it start working again. I know losing grip of the platform is short-sighted in principle, and for the purposes of my team is immediately impractical.

benefit from ... Redux

>_< had a good laugh, thanks! I imagine writing a hierarchical reducer every time I have to update x in {a:{b:[...,x,...],c:{{{...}}}}}-like structure. Mobx is close, but in the same "unengineering of overengineering" category.

(Edit: I don't think that parent comment deserves graying out, I'm always happy to elaborate on subj)

At no point do you change your focus to what works best for the user. Who is the user; what kind of devices does he use; what does he want to accomplish on your website; what does he need to accomplish that; etc.

React pre and post 16.8 are two completely different libraries. I remember 2019, hooks we presented as a replacement to lifecycle methods and class-based components at all, not as alternative. The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.

>in 2019, they were presented as a more convenient alternative to lifecycle methods

Again, no one presented hooks as an alternative, it was strictly a replacement for class-based components which were obsoleted.

From the rest of it I see you have a very big problem with react, "you might not need an effect" article was written for folks like you. Update the state during render? what? if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref; there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.

Disproportionate amount of energy I would rather spend learning JavaScript, something that would last.

Using React since 2013. Each release is an excitement, until I realise some chunk of concepts which altogether took months to fully grasp, are gone. Some even needed to be unlearned.

A lot of abstractions.

React doesn't make you a better developer, it makes you a better React developer.

I don't feel that with Vue. I don't feel that with most libraries I use.

And anecdotally, if your team is not ready/willing to dig in react, all its benefits will fail to materialize, you'll have a bunch of patched up libs and components trying to do what htmx or similar seem to offer (async actions over REST) for just a few lines in your html template.

9 years of professional experience.

Having worked and paid to do so with Java, Scala, Kotlin, Python, JavaScript, Typescript, Python

Been working with Rust since 2015, have prior experience with C++, had to work with C, Haskell and logic programming (not prolog) at University.

Also did C#, Golang, Lua, Zig and many more.

Does that give more authority to my statement? I sincerely hope not!

FE tooling is never a one-size fits all thing like Postgres, but people want it to be (god help you if you have 2 different FE libraries that serve different usecases, even though 90% of the time you just need simple tooltips or a multi-select box that play nice with static server HTML) and the cost is giant, unmanageable, extremely expensive piles of JS where the entire frontend is pushed inside of it.

1. Beyond self-learning, there's two types of education. Formal, college education that delves deep to both the CPU level and mathematical proofs of correctness, and coding bootcamps which teach how to do things, but little about how things work.

Frontend isn't taught in formal college education, so there's a big void in industry knowledge. Some people learn about compilers, interpreters, have used GDB and implemented malloc for school, but they aren't the ones doing frontend. Others are doing frontend but never think about memory usage, closure scopes, or garbage collection.

This leads to bad frontend code, that misuses resources.

2. JavaScript long had fame for being a "toy" or "joke" language. I noticed the tide slowly change by the mid 2010s— that's not that long ago.

Proportionally and compared to other technologies, how many engineers have had time to develop long careers, learn from mistakes, and become that serious, dress-shirt wearing, super-senior engineer sitting at the back of the room making sure young developers don't get too unhinged? This proportion is probably especially stark if you consider just how in-demand web development is.

This leads to bad frontend code, that misuses resources.

3. Finally, with the two above in mind, re-writes. Unexperienced teams are the first to opt for re-writes. It's a story as old as time; "we don't know how to fix A, so let's instead build a brand new thing B, which works differently to A and thus won't have its problems".

Re-writes always go well at first, because the fresh codebase will be smaller, faster, nicer and because everyone is especially cognisant of the problems A had, which are very much not present in B since it works differently.

Eventually of course, B grows bigger, and gets permanent hot-fixes, its requirements change, and bugs start to surface that nobody bothers understanding. A is also far enough in the past that nobody is thing about the problems A had anymore, and has more mind-space to notice the problems that are unique to B.

But before that happens, you get this sort of comments.

It's a form of technical smugness that pervades this site for any frontend JS thread.

You rarely see frontend devs criticise backend devs on their tech stack.

And React is worse than the alternatives. All it has going for it is the huge ecosystem.

HTMX philosophy is to be timeless and agnostic as HTML is, is just a nice extension on top.

Like for example: https://shoelace.style/

HTMX allows you to learn the very basics: the HTML which is almost verbatim turned into DOM which the browser renders. It's the FE. Everything else is layers upon layers of abstraction which ultimately compile down to the DOM representation of HTML.

...or to put it differently, quoting HTMX's author: using HTTP to transfer HTML? How queer!

That's a really weird statement, do you keep your application state in a mutable data structure instead of immutable? Do you know what a pure component is?

Been there and done that with and without. Junior (and Senior) devs fundamentally don’t read the docs. That and requirements churn are the problems.

Given that, it ends up so much better with React.

Async, await, iterators, futures etc. are pretty much standard constructs in almost all programming languages / concurrency frameworks.

Whereas Actions, Transitions, Pending State, Reducers etc. are React-specific idiosyncrasies.

I guess that's the main issue people have with React, when you learn it you have to spend so much time to learn all these React-specific constructs and idiosyncrasies that are not transferable anywhere else.

However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day.

UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.

So new projects have to actively not follow the recommended approach in the docs if they want to use vanilla React.

But otherwise, Svelte has a very low surface, everything else is just standard vanilla JS/Html, also one thing that Svelte has over other frameworks is that vanilla JS libraries just work, no need for a wrapper any.

FWIW I liked Redux enough that I once half-reimplemented it for Brightscript so the UI guys would have something familiar to work with when they had to touch Roku apps. I always taught Redux initially using different terminology, though, because I found that most of my time learning it (which, mercifully, still wasn’t that long, because it’s small and pretty sensible) was figuring out the vocabulary (“do… do they just mean ‘event’? Well if so surely they’d write ‘event’, so I must be wrong…”)

This is genuine question; I've not used Vue or Svelte.

I don't know, there's been a lot of stuff since 2014.

In client-side React we've seen stuff like react-query, mobx, etc which weren't there a decade ago. Back in 2014 everyone was still using redux (ugh).

Or Svelte and SolidJS which have brought massive improvements in performance and reducing JS with signals, compiler, etc.

Whatever the case, I think very few companies have reached the excellence of native macOS interface design in the context of a web app. Figma is a lone exception; for anyone else to achieve what they have, they'd have to reinvent the wheel yet again in so many small ways. (Have you noticed in Figma how moving the mouse down and to the right diagonally from a menu item to its associated submenu does not cause the menu item and submenu to be deselected? That detail, and so many others, are straight-up macOS-inspired UI craftsmanship.)

We need a reusable toolkit that lets ordinary developers achieve Figma-level UI excellence in web apps.

grid and flexbox are probably closer to actually being a one-stop easy-to-use paradigm with less nasty edge cases than tables, but all the table code stuff is still there if you really want to do it.

---

> I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world.

I actually think this is orthogonal. The power of frameworks like React is that nobody wants to write the same app five times (windows/mac/linux/ios/android) using sometimes wildly different native coding paradigms, and coordinating feature development across native platforms is like herding cats.

The difference is, in SwiftUI you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup, no intermediate steps to transpile the code into something you can’t recognize and the “backend” that deals with the logic is the same language with the same paradigms. Mind you, SwiftUI is considered a downgrade when it comes to tooling. Yet everything fits and you didn’t spend mental energy to try to make the tools work as intended.

My mantra now is to use the tool that is built to do the things I want to do and stop trying to make make it work in ways it’s not intended to. That’s why when I want to have a web interface I simply work with DOM directly. That’s how the creators of the web browser intended:) No virtual DOM, no libraries doing magic and managing the DOM for me. I'm sure there's place for ReactJS too, it's just that its not for most use cases.

All I want is tools that I can fully fit in my working memory and don’t spend time trying to make things work so I can do the work I care about. Simplicity and robustness is the paramount.

It’s great.

Btw the web tech has come a long way since. Native browser API is amazing, CSS is wonderful and I’m particularly excited for Web assembly. Drop the virtual DOM stuff and all other Frankenstein BS and working on the browser is actually fun again.

What's the solution?

You have no idea what you are talking about.

The original `createClass` API was indeed deprecated and removed all the way back in 2017 [0]. You can still use them today with the separated `create-react-class` package.

ES6 class components still work as-is even in React 19 - it's just the legacy context feature that's been removed. They're generally discouraged, in that function components are now the standard way to use React, but they're still not "deprecated" in the sense of a warning or removal.

[0] https://legacy.reactjs.org/blog/2017/09/26/react-v16.0.html#...

Pinia is Vuex, it was made by the same people specifically for Vue 3 due to otherwise having to introduce a lot of breaking changes and is a lot simpler than VueX was, as it leverages the composable pattern and gets rid of the need to do things like `mapGetters`/`mapActions`. And VueX 4 is still an option for those that prefer that approach.

> ... class mixins

Those were a pain point, but no longer relevant in Vue 3 as mixins have been deprecated. Again, composition takes its place and is in general much more powerful while being simpler. For a great example of what composables can achieve, I'd recommend taking a look at VueUse (https://vueuse.org/)

> Today, 33% of vue downloads in the last 7 days are for vue 2.

Another way to look at that is that the majority of the community is on Vue 3 :)

> If you want to use vue with a .tsx file you might as well use react.

`.tsx` is very much a personal preference thing and isn't really considered idiomatic despite Vue having support for it (unless you're a library author like Vuetify that you linked). I personally can't stand working with `jsx` and find Vue SFC's superior, and again, typechecking these days is much better than it ever was and will work just fine in 95% of situations. Especially with things like component generics being introduced, it's only gotten better and actively getting better.

I'd highly recommend you give Vue 3 a try with an open mind, because things have only gotten more powerful while getting simpler since the Vue 2 days.

Native development is definitely a pain point, unfortunately there's few options other than React Native there. Problem being that React is backed by Meta, so obviously it has a lot more money being thrown at it compared to competitors like Vue or Svelte.

But gun to my head, Shadcn would probably be my choice. For Vue it'd be PrimeVue. Those are the two highest quality ones I've tried in small projects, so no clue how they scale in real-world projects.

If building a SPA site with vite use tanstack/react-query and react context. There are other great libraries like zustand and jotai that can make sense in certain kinds of more complex applications.

We’re not just assigning variables directly, current JavaScript frameworks use a compiler.

   [foo, setFoo] = useState(1);
   [bar, setBar] = useState();
   setFoo(10);
   setBar(foo * 2);  // Is bar 2 or 20 at this point?

What aspects of Django do you think still stand out compared to Phoenix? It seems like a very solid framework, specially with the recent release of Phoenix LiveView 1.0, which seems like a pretty solid approach to frontend. For context, I’ve worked with Django before but didn’t particularly enjoy the experience—not because of the framework itself (its documentation, ORM, and admin tooling are excellent) but because I’m not a fan of Python, particularly its packaging ecosystem and approach to async, which I find lacking. I haven’t used Phoenix or Elixir before, so I’m curious to hear from someone who has experience with both.