A bit out of date, but I like the point-of-view of "The single most important factor that differentiates front-end frameworks" : https://mjswensen.com/blog/the-single-most-important-factor-...

I was deep in Vue 5-6 years ago, so much that I offered internal training for it and had sessions with more than 20 people attending.

IMHO, React wins because you can just treat templates as variables. You don't need "slots" or other special stuff. It's simply more composable.

Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch.

The real discussion would be between React's vdom and something like Solid's signals.

The company I work for uses Vue. I think the non-backwards-compatible move from Vue 2 to Vue 3 burned a lot of the current devs, so now they're stuck working on Vue 2 apps that are in maintenance mode with no viable case to clean up the mess by moving everything to Vue 3. The experiments to do it with Copilot mostly failed, although that was in the early days so another try today might work better. If we're doing something drastic to improve though, we might as well solve our "Vue devs are hard to find" problem by rebuilding it all in React at the same time.

I remember in 1999 being so psyched about changing a button image on mouseover. Went hard on jquery, little bit of angular and bootstrap. React was big for me because it’s one way data binding solved the kinds of bugs I had spent years dealing with. Vue svelte and others are cool but they are all very similar to me. I always encourage people to work at first without any framework because then you gain an appreciation for why these things exist (or you stay vanilla and constantly blog about it)

same here thus I'm with vue

Currently rewriting nextjs app into sveltekit. It’s going surprisingly smoothly. Don’t know about svelte vs react yet BUT sveltekit is far more straightforward than nextjs has far better DX and is somehow faster

Svelte is cool although I didn't have some big epiphany. I'm not going to use Svelte because "it compiles" and "is faster" when my existing React app performs very well. Plus there are some libraries for my specific use case that didn't exist in Svelte. I know people love things besides React, and I would be happy to see it unseated. Sure I'm part of the problem but it's been good to me and I have bigger fish to fry.

More library support for React over any other framework. I also like explicit state change over implicit.

I mean, that means someone at your work liked React enough to choose it over the alternatives.

I see a lot of personal projects, solo founder applications etc running made in React. I respect your opinion but other people definitely do choose it when they have fully control of what they use.

React wins because it has a predictable interface that has become industry standard. Industry standard saves money. Not everything must be creative.

I don't see why "inertia" or adoption should be excluded when deciding what library to use for the job. If you are manufacturing a physical product you will need to consider how easy it is to source any component before adding it to your bill of materials. I don't see why software engineering should be different. There is a reason why we are all working in boring languages and not Haskell or LISP despite their supposed technical superiority.

They are actually speaking to trying to make an in-app back button use the history stack so that it _doesn’t_ “break” your browser’s back button.

The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…

That's not a react thing, it happened before React was even a thing. It's just self-centered website programmer design.

This has been a non issue when using proper routing libraries that push history entries on the stack properly and render routes from the top of the component tree down.

You hate BAD react SPAs that break the fundamentals of how the web works. Good ones take care to not do that.

React fundamentally doesn't cause this issue either. You can use a different framework than react or even vanilla JS and still produce the same bugs.

It’s an absolutely not true that react is especially bad for this behavior.

I think that lots of more traditional websites have very poor back button designs, especially around editing and form submissions. Remember clicking back and the browser prompting for form resubmission? Very poor design since you have no clue how the server will even handle form submissions. Or getting stuck deep in an application, hard to get back to the root. Or, consider encoding current page data that you’re editing into the URL, and back buttons don’t return to root and just strip query params. Often a very frustrating experience.

Often, “go back to what I was doing before” is what I actually want, not “go strictly to the previous state in the URL bar.”

Sure, plenty of people mess that up too, but the reality is that controlling the navigation stack can help you build more useful designs.

I never thought about doing that. Thank you.

Re-read it. We needed to preserve scroll position when you went back. If you just linked back to the inbox it would kick you to the top of the screen.

Came to ask this myself. Oddly enough, I think they’ve kind of slipped under everyone’s radar.

Yes you could, or even just a vanilla DOM event handler on a button click.

The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer

There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.

I wrote a polyfill in order to take advantage of the navigation API for this exact problem: https://github.com/kcrwfrd/navigation-ponyfill

React uses an algebraic effectful function model which is elegant once one understands it: https://overreacted.io/algebraic-effects-for-the-rest-of-us/

> I never get this take. A react component is not just a function,

Exactly.

I did a somewhat longer writeup a while back.

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

The pull request is still open :-)

Maybe you would prefer React's class-based syntax. It's still there if you want to use it

Years are a pretty short time frame as it relates to technology, though. Even for software.

The solution might be well out of grasp now, but think 10, 20, 100 years from now. Somebody smart with a new perspective will eventually come around and tear out the roots, and we'll all be better for it. Perhaps what's holding us back isn't the problem itself, but the way we approach it and the assumptions we bring.

Trying is at least worth the effort, especially since "better" is very achievable, rather than total perfection.

What does being intuitive have to do with software optimization? You can write poorly performing code for anything. Most people never touch profilers.

No they are implementing Functional Reactive Programming, it isn't the same thing, even though common folks would say React.

https://wiki.haskell.org/Functional_Reactive_Programming

I wouldn't say Compose UI/Flutter/SwiftUI are "implementing React", but if your point is that other platforms have better solutions than JSX (plus all the bloat React adds to applications), I absolutely agree.

I wouldn't call Elm dead. Development has frozen, this is true, but X11's development was frozen and it still powered so much for decades. This is actually super common in the Clojure community -- many libraries look dead, but they're just feature-complete and FP is usually quite bug-free, when implemented correctly.

Totally recognize and agree with the lack of libraries -- that's really Elm's weakest side.

Not the person you were asking, but I shall share my experienc..

>how it scales for apps that may have reusable components or sufficiently complex

It is a lot of boilerplate, but it is mechanical, straightforward changes. I think it is entirely possible to automate it (not even using LLM).

> state..

I have used ELM ports to interact with JS and localstorage/indexeddb.

In my experience, the biggest problem in Elm is how unintuitive TEA's docs are. In some ways, Elm really feels like Haskell -- you want to avoid creating "stateful" modules and you prefer stateless modules.

For example, https://harmont.dev's app (landing page is not Elm) has a component to render a pipeline graph called DagGraph. In React, you'd do something like

  function DagGraph() {
    const steps = useState<Jobs[]>([]);
    const selectedJobIdx = useState<number | null>(null);
    return ...;
  }

  function DagGraph({ steps, selectedJobIdx } : IDagGraphModel) {
    return ...;
  }

  function PipelinePage({ graphMode, selectedPipeline }: IPipelineModel) {
    return (
      graphMode === GraphMode.DagView
        ? <DagGraph steps={selectedPipeline.steps} selectedJobIdx={selectedPipeline.selectedStep} />
        : <TableView steps={selectedPipeline.steps} selectedJobIdx={selectedPipeline.selectedStep} />
     );
  }

  namespace PipelineState {
    interface Model {
      steps: Step[];
      selectedStep: number | null;
    };

    interface ISelectStepMessage { stepIdx: number };
    interface IUnselectStepMessage;

    type Message = ISelectStepMessage | IUnselectStepMessage;

    function update(m: Model, msg: Message): Model { return...; }
  }

  // main model
  interface Model {
    pipeline: PipelineState.Model,
  }

  type Message = PipelineState.Message | SomeOtherMessage | ...;

  function update(m: Model, msg: Message): Model {
    switch (msg) {
      case PipelineState.Message as msg:
        return update(m, msg);
      ...
    }
  }

At the end of the day, there's a trade-off -- my logic is no longer localized to the "component" relevant to rendering the pipeline DAG. I never have one file open editing Elm code, but I'm a vim user so it doesn't bother me. In some ways, semantically, I think it makes sense to split the "state backend" of your UI from your UI, in my opinion.

Most of my app states are represented as state machines (coming from embedded this is quite natural) and UI is represented as pure transformations of that state.

With Elm, it really feels like you reason about state and UI separately, and I actually prefer that, both for testability and that's just how my brain works.