| > Everything they do is just so overly complicated, and so many layers of abstraction rolled up in a messy ball of mud. With a historical lens, these all seem like great improvements over where we were at the time. Their implementations certainly grow in complexity, but there are core simple ideas that Facebook emerged that were incredibly valuable. With React, the web got one of it's first immediate mode rendering schemes. Instead of trying to ongoingly modify the page with event handlers - a bedevillingly complex game of guessing your current state & figuring out the next one - developers could just re-render the thing, and vdom would make it fast enough. With React, we iterated towards simplicity. The VDOM keeps doing it's thing, but the tools around how we create it keep getting nicer. Class components were fine but with complex dynamics that required careful understanding. Higher Order Components helped us isolate concerns. Functional components are so much easier to review & read & handle. If anything, from a DX, I feel like React went from excellent at beating the complications of the web, to being phenomenally out of this world great at reducing development complications. With Flux/Redux, we got directed data flow. We gained a real place where data lived, we gained a way to ask for that data, we gained a way to update data. We'd had countless informal systems, but this created a well known structure usable across teams that provided once again just enough constraints to bring order. With Flow, we got typing. I don't know a ton about Flow, but Flow was quite early, and it certainly helped pioneer the way forwards & was the right direction. For a while Flow was the clear winner for a lot of people in the typing wars, but TypeScript's ability to improve & iterate & their overall approach slowly clawed them towards being the default sensible choice. Jest doesn't delight me but seems fine. React Native is a brilliant approach to take crufty complex native app building & to deploy the world's most popular software stacks to the problem. In a cross platform way. Brilliant revolutionary attempt. The reality hasn't always been sun & roses, but the team keeps working forward and keeps iterating. The new component style is a great iteration towards simplicity, a modern take on the things. GraphQL again paved the wild. I don't particularly have love for it, but it nicely intermediated a complex problem of how data is made accessible on the web. It again paved the many many cowpaths & built a paved road stable well defined way to do the job. And it had some really great upsides, like letting you build really complex objects that could draw data from all over the place, but then only need to fetch/compute what you need, which I've seen be a huge boon for systems. GraphQL is like an deeply flexible serverside join engine, and that is very powerful to have, and eliminates ton of having to carefully craft APIs ahead of time & orchestrate services yourself. I always am curious what perspective people judge from when they say something is overly complicated, when they call it a "ball of mud". It's also interesting to note the distinction between internal & externals: much fewer devs are out there to judge how clean or how many levels of abstraction there are inside the implementation. From the outside though, most of these projects seem, to me, to present a clear idea or two, and not to be burdened down by being many-layered. I'd like to hear the naysayers also find one good thing to say about each project. Even if you don't like it, what are the things you acknowledge or can appreciate? I feel like anti- views especialy lack depth & nuance, so frequently tend to flat denials, where-as those with positive outlooks bring nuance & complex thinking; there's a meta here, about what forces we let drive us, that I think is so crucial to finding the better light of humanity, that deserves the challenge, to push for higher. |
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.