HN user
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>
<form onSubmit={event => event.preventDefault()}>...</form>
<form @submit.prevent="onSubmit">...</form>
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.
Here's a short list of things the current citizens of England didn't do:
- Genocide against the people who lived in America
- Bring India to its knees, from one of the richest to one of the most impoverished nations in the world
- Addict China to opium
- Irish potato famine
Furthermore, the narrative that Scotland is subservient to England, and not equally complicit in the historical crimes of the *union of England and Scotland* is misleading. The 1707 Acts of Union [1] were introduced by both nations.
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.
This is what I was driving at in my original comment - the intermediary steps are not of interest (from the POV of the hypothesis/overall experiment), so why mention them at all.
On point 7 ((Testing an unclear hypothesis), while agreeing with the overall point, I strongly disagree with the examples.
Bad Hypothesis: Changing the color of the "Proceed to checkout" button will increase purchases.
This is succinct, clear, and is very clear what the variable/measure will be.
Good hypothesis: User research showed that users are unsure of how to proceed to the checkout page. Changing the button's color will lead to more users noticing it and thus more people will proceed to the checkout page. This will then lead to more purchases.
User research showed that users are unsure of how to proceed to the checkout page.
Not a hypothesis, but a problem statement. Cut the fluff.
Changing the button's color will lead to more users noticing it and thus more people will proceed to the checkout page.
This is now two hypotheses.
This will then lead to more purchases.
Sorry I meant three hypotheses.
Writing an article about developer mistakes is easier than redesigning your rubbish API though.
Most experience with DynamoDB, which isn't without challenges, and has a steepish learning curve to get the most out of it.
I work in pre-market fit startup though, so hyper-scaleability is not really a consideration right now, and would much prefer to be running postgres.
Civilised society might prefer no weapons?
Really do not share your experience with CosmosDB, some of it's attributes that currently make me miserable include...
- Scaling is not infinite, it's up to 20gb per partition key (1), which can't be changed after document creation.
- One set of global indices, no equivalent to DynamoDB's secondary indices.
- Still can't run their docker container on mac (2) natively.
- Weird SQL-like dialect that's required for all but the simplest queries. JOINs are spectacularly awkward.
- Tooling is horrific. Based on the previous point, no existing tooling works for it (and nobody is building tooling for a DB with such minimal market share). For example, I needed to manually deleted 30 or so documents/rows yesterday - only way to achieve this is with 30 separate click-to-deletes in their UI.
- Minimises analytics options. There exist a plethora of business intelligence type tools that will happily sit on top of most common DBs. None of them like CosmosDB. So you're stuck with synapse link or whatever MS calls it now.
Overall it seems to combine the worst aspects of both RDS and document stores, with the worst aspects of both traditional and serverless infrastructure.
(1) https://learn.microsoft.com/en-us/azure/cosmos-db/partitioni... (2) https://learn.microsoft.com/en-us/azure/cosmos-db/local-emul...
In for HN toon