Tell HN: Unpopular opinion: All Meta's open source front end stuff sucks

Wow, a legitimately unpopular opinion. Strongly disagree, I worked on complex frontends before React, and React was SUCH a breath of fresh air

It's a legitimately unpopular opinion only because React is on that list. Take React off this list and the opinion will be stale.

I also don't know what it means for FB to be "leading" in this space because they don't push any of their other solutions on you. In fact, React being a stand-alone library may be a long-term strategic mistake as it seems the ecosystem is tending towards mega-frameworks.

I'm at the point where I question whether almost all tools that we use for the web need to be revised. HTML, CSS, and JavaScript have served us well... but I think all of them are showing their age, and everything built above them is a hack at this point. But they are all so engrained that nobody can imagine how things might be done better...

JavaScript was obviously never intended, or designed, for 90% of the things it's used for. Also, as a language, it's so flawed that we have stuff like `left-pad` and `is-odd` on npm which is just atrocious...

CSS, and styling pages in general, has always been a mess. Either have a disaster trying to name all your classes, or abuse HTML by using a billion utility classes a la Tailwind.

HTML was obviously never made for utility classes, encourages bad practices like inline styles, was never designed for DOMs of such massive size, and the number of strange new HTML tags that don't quite do the job is quite large.

> CSS, and styling pages in general, has always been a mess. Either have a disaster trying to name all your classes, or abuse HTML by using a billion utility classes a la Tailwind.

In my book this is not a problem inherent to CSS but, well, how to name classes and stuff in your HTML. At this very moment writing CSS is just amazing and many of its "new" features are what many of us have dreamed about for years.

Still I have another unpopular (and for many of you, stupid) opinion: I'd like it if HTML, CSS and JavaScript had all the same syntax. Like QML's.

I mostly agree, and usually feel like a grouchy old man for it. Been doing FE for a long while, jQuery into stuff like Meteor, then early Angular and Ember... There were a lot of frustrations but I found that they were more easily overcome, and past a certain point I've felt like we aren't getting any more technologically superior with reimagined frameworks, but rather just finding a new flavour of the month.

Conversely, React Native (and other similar solutions, even Electron which I love to hate) are AMAZING and I feel like it's such a breath of fresh air compared to pure native app development. They have their ups and their downs, and they're not always the best solution for a given problem, but they've brought so much opportunity for dev efficiencies within companies and allowed solutions to be built that would've otherwise been cost-ineffective in the past.

I'm not sure about overcomplicated, but I agree that it's not the best path. Have you used Meta's products?

As a regular user of Meta Business Suite and other Meta social products I can tell you that they are terrible and full of issues. The creators of React make web apps that are awful to use. What chance do the rest of us have?

React brings some complexity but at the benefit of better state management and DX. If you have ever worked on large projects where each button has a click handler to do 20 different things, you will find that it's easy to miss some edge cases and have state drift.

Maybe your definition of simplicity does not satisfy all relevant needs.

just gonna leave this here: https://reagent-project.github.io/

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

> guessing your current state & figuring out the next one

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.

> In Backbone, you had view with a model that managed a dom element tree. You could render whenever you wanted and exactly when needed.

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.

lol this is the most popular opinion on HN. every single thread about javascript or React is literally most of the thread saying "jquery is good enough" and "react is horrible" and lamenting the state of frontend frameworks.

I think modern react is legitimately good and most of its flaws are Javascript's.

And I'm pretty sure this is a popular opinion on this website, at least for people who had to work with front-end dev (it's like 5% of my current job tbh)

as the creator of htmx.org... that's bait