[alsiola]

> the opposite of being under appreciated

> despite there being alternatives that are better in almost every way.

This right here is the under appreciation. The new way to signal to others on forums that you are a really really great dev seems to be to bring up how much better some bizarro templating engine that abuses a niche JS language feature is.

[array_key_first]

React has fundamental problems that lead to both:

- horrible performance characteristics

- needless complexity

These are not tradeoffs, these are bugs. We don't gain anything from them.

That's why React introduced a compiler. Because problem 1 is a big deal. But it's not a code problem, it's a React problem. Other tools simply do not have that bug. Which is why the exact same react code can be compiled and run much faster.

[jwr]

You haven't described those "fundamental problems" that you call bugs, but I think these are irrelevant for me from a ClojureScript point of view. As an example, immutable data structures mean that equality comparisons are cheap and I can often avoid re-computing and re-rendering huge parts of the tree.

More importantly, I don't have a React performance problem. I don't really need "much faster".

[array_key_first]

> More importantly, I don't have a React performance problem. I don't really need "much faster".

Sure, but ultimately you're using a library with performance bugs that lead to orders of magnitude more rendering than necessary.

If you don't mind the buggy software, that's fine. It's still buggy.

[recursive]

I'm curious what makes a template language bizarro, and why JSX is or is not bizarro?

[alsiola]

JSX is just sugar around JavaScript, and interops nicely with it. I'm okay with that. The more I write JSX, the better I become at the programming language I'm using. Concepts and patterns in JS can be adopted in my components.

If I learn Vue's templating language, then I'm spending my time learning a system with no wider applicability, a much narrower tooling space, that doesn't utilise my previous or future experience from JS. That's not a good calculus for me.

[recursive]

I don't understand how Jsx is syntax sugar in a way that vue templates aren't. Neither of them are valid JavaScript but they both compile to it.

[alsiola]

A concrete example then. Commonly want to prevent form submission default behaviour.

Vanilla

  <script>
    const form = document.getElementById("form");
    form.addEventListener("submit", event => event.preventDefault())
  </script>
  <form id="form">...</form>

React

  <form onSubmit={event => event.preventDefault()}>...</form>

Vue

  <form @submit.prevent="onSubmit">...</form>

React's API has guided the developer to learn about events. If they move outside the React ecosystem they have transferable knowledge. As someone unfamiliar with React, but used to the DOM you're surely comfortable here. Yes, the syntax isn't identical to how you might use this in vanilla JS, but it's clearly the same concept. It's just been made a little nicer to use - the sugar.

Vue's API has reinvented the wheel. There's one place this syntax is useful and one place alone - Vue itself. It hasn't used my existing knowledge, or pushed me to become more familiar with the platform upon which I'm building. That's not sugar, that's a new language.

I've probably got the vanilla example wrong - when you don't do it frequently it's not the most ergonomic thing in the world. React takes that API, doesn't deviate far from it, and makes it easier to use. Sugar.

[tobr]

Fun example! Strange conclusion. React actually uses a synthetic event system that is subtly different from the native one in all kinds of little ways. In reading the docs it’s hard to even get an overview of what’s different. Bubbling is a bit different, onChange works like the input event for some reason, various props and methods have been added. This is not the case for Vue! It just uses standard events.

The .prevent modifier in Vue is completely optional, you can call .preventDefault() yourself. Note that React also uses a kind of modifier but only for capturing events (onClickCapture etc). It does not have any way that I know to add a passive event, for some reason.

Vue is the one that actually offers syntax sugar, and does so much more consistently, with the semantics identical to the browser. React changes the semantics for unclear, historical reasons, and then adds half-baked syntax sugar on top.

[alsiola]

I'm not claiming React is perfect by any means, and like any popular relatively longstanding project is is bound by sometimes unwise historical decision. It just seems to be currently in vogue to take a pop at it. If you want to extol the virtues of Vue/Svelte/whatever then great, but React is still IMO a great option and deserves some defense.

[paulhebert]

This seems like a very hostile and uninformed take on the alternative tools.

Have you tried building anything with Vue or Svelte recently?

Can you provide some concrete issues you ran into beyond them being “bizarro”?

[alsiola]

I consider this example fundamentally broken, in a non-obvious way that reflects, in my opinion, a poor API choice.

  <script>
    let numbers = $state([1, 2, 3, 4]);

    function addNumber() {
      numbers.push(numbers.length + 1);
    }

    const sum = numbers.reduce((x, y) => x + y, 0);
  </script>

  <p>{numbers.join(' + ')} = {sum}</p>

  <button onclick={addNumber}>
   Add a number
  </button>