(no title)
erlich | 2 years ago
I look at React from a Backbone lens. In Backbone, you had view with a model that managed a dom element tree. You could render whenever you wanted and exactly when needed.
> functional components...reducing development complications
Hooks and the like just feel like an entirely different programming language. It's impossible to trace what is actually going on. Yet, everyone ends up having to learn all the nuances and rules and know somewhat how they are working under the hood, and then also contort their code to work with hooks too.
React and these big frameworks draw people in because under the hood they are so damn complex that people feel like they could never write something like this themselves. But they don't realize that the code they actually need is extremely simple and something they can easily step-through with their debugger.
> we got directed data flow
We kind of didn't need it though. Think about your SQL database backend. It's a big ball of mutable state, and people get by fine with it. If I have an object, and just listen to changes to it, and re-render, its much easier than having some complicated event-sourcing thing going on.
So much of React's design is chasing this functional-programming purity kind of thing. Contrived examples can be made to look super elegant and clean, but then there are all these edge cases and the realities of interop with a big ball of DOM state. Instead of chasing these kind of concepts, the goal should rather be day-to-day developer experience. Which mostly involves debugging and tracing through code.
> Flow
Ocaml was a terrible choice. Things moved so slowly. No one could contribute. There were just so many usability issues and waiting for things to compile. Just an excuse to use shiny tech. And oh boy did they tell you often about how Ocaml was a great choice for such a project.
...
The peeve I have is the distortion of the ecosystem. For many years to come, no one can stray too far for React to innovate because of the familiarity and risk. Look at projects like Solid, Qwik, etc. It's not Meta's fault but more the community hype machine.
jauntywundrkind|2 years ago
In Backbone, many people over-rendered like crazy. And in a far more disruptive & costly redraw process than React's VDOM. React made rendering much faster & eliminated the complexity in figuring out what and when to render: just redraw, and it will be fast. This joins with Flux/Redux's advantage, to which you say:
> We kind of didn't need it though.
You talk about SQL being a big ball of mud / mutable state & saying we were fine with it. But what we get from Flux/Redux is selectors, where we can react to changes in data & only redraw what we need. Direct data flow let us make our apps much faster, and in a way where we didn't have to explicitly carefully manage all the data-flow dependencies ourselves: here's a pattern to subscribe, here's a pattern to write, and the store works it all out. It was hugely useful.
If anything, the battle here has just subtly intensified over the years. Observables keep simmering along. Lenses were a thing for a bit but faded. Signals seem to be the up-and-coming, with dozens of incredibly high performance frameworks and big names like Angular tracking to them, to much more precisely manage these data-flow problems, all in the name of doing what Redux did: letting the computer quickly figure out what work & rendering actually needs to be done.
Having a formal system for data also has huge upside. The Redux dev tools are an incredible window into what is happening in your app over time. Having a well defined world enables incredible powers of observation: it's a stunning & massive win.
> Hooks and the like just feel like an entirely different programming language. It's impossible to trace what is actually going on.
Anecdata here, but I've been at quite a number of pipelines with strong hire-from-college & hire-from-bootcamp pipelines, and my heavens. These newcomers definitely take to hooks much better, in my view. And it's much easier for me to code review & see the intent & to suss out weaknesses.
Contrary to your claim, struggle to think of coworkers ever actually having to dive into React codebase to understand or optimize code. Understanding when to useCallback is a micro-lesson, but makes sense if you know DOM. If you understand vdom basics you should understand why deps are there and what they're for, but that's still a micro-lesson that needs teaching or sometimes re-teaching, but usually takes 20 minutes. If anything, I think it's staggering & threatening how little people understand their frameworks, but it just doesnt matter.
> there are all these edge cases and the realities of interop with a big ball of DOM state.
What's the use case here? What are we talking about? Why do you need to interop with the DOM? I generally find that writing event handlers in React is no problem at all. Is that what you're talking about? What's the situation?
> Ocaml was a terrible choice.
In retrospect maybe perhaps, but I still think of Ocaml as a brilliantly smart programming language with a huge stock of incredibly talented developers. Maybe yeah it didn't work out, but I can absolutely see the signs of promise, and see why the vision here could have worked out and could have made sense & could have been powerful.
More generally, I don't think this is the avenue of consideration I'd be looking after. What about Flow was bad or overly complicated or otherwise bad? There's arguments against the community failing to take off, sure, but good tech badly supported is a different argument than the "overly complicated" "big ball of mud" grievances.
> For many years to come, no one can stray too far for React to innovate because of the familiarity and risk.
In this I share laments. I myself want to embody the radical revolutionary trying new things ever improving spirit, and the long era of React has been such a giant damper after so many years of tuning in daily to be thrilled with new ideas on Ajaxian & feeds. We have so much more to explore & improve, and we cannot stop here.
But I also think it's unclear what is worth switching for. There are some really alluring interesting concepts out there. Qwik's resumable-ness is a fascinating concept, and a compelling alternative to the typical SSR hydration. I am so excited to see where Solid goes and hope we can see some more shape towards 2.0 emerge. Threads on signals & new signalling libraries get semi-regular traction here on HN & are such a point of excitement & possibility. I keep hoping we'll distill out clear paths for WebComponents, and it seems like Lit does get shipped a decent bit but few others do. Overall it doesn't excite me but I recognize most people are trying to solve business problems, and they are replete with known viable choices & options if they stay somewhere in the huge React ecosystem. It's not just the hype machine to me: there really aren't the clear technical wins yet for most alternatives to become established worthwhile options one can feel confident picking.