alsiola

Looked at the backend demo, and the first lines suggested to look at were importing things. Exactly what I really don't need to be reviewing

We could call it the

The Universal Reasoning In Novel Groundings

test

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.

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.

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.

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>

Used Astro for a pro bono project. Found it fantastic, well documented, provides solutions for the hard parts, gets out of the way for the easy parts. Documentation is well written, but I find I don't need it much because mostly it works how I would expect.

Been here seven years. Next is hot garbage and you couldn't pay me enough to work with it.

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

> Besides, in the UK, SMS spam is almost non-existent in my experience.

This is not my experience. Perhaps 3-5 years ago was the peak of SMS spam, but I still regularly (1/week minimum) get one of the various "package delivery" | "tax refund" | "diesel emissions" scam/spam texts.

Step 1: Stop wasting money subsidising their bullshit.

Step 2: Take a slice of advice from the revolutionary French.

The Crown Estate is where the sovereign grant comes from, and it's weird. It's "owned" by the current monarch, but only in their role as head of state (the Crown). Realistically it belongs to the country and to the public, and were we to abolish monarchy, would not become the private property of the Windsor family.

So while they don't rely on tax money (outside of the huge amount of tax money spent on their police protection, transport in military aircraft, etc. etc.), they do rely on money which rightfully belongs to the people of the nation.

Came here with that exact quote in my clipboard. I have a medical background prior to software, and one of the key learnings there is that wherever there is scope for a human to make a mistake, that mistake will (eventually) be made. It's therefore crucial that wherever possible the capability of making that mistake is eliminated. I see automated deployment as falling into a similar category of utility.

Will watch the TED talk, thanks for sharing. I come at this from a medical/epidemiological background prior to building software, and no doubt this shapes my view on the language we use around experimentation, so it is interesting to hear different reasoning.