Claude tends to disregard "NEVER do X" quite often, but funnily enough, if you tell it "Always ask me to confirm before going X", it never fails to ask you. And you can deny it every time
Calculators are a particularly bad example for your case. There was absolutely hyperbole against calculators when they were introduced. [1]
With similar sentiment as well
"They make us dumb"
"Machines doing the thinking for us"
Cars were definitely seen as a fad. More accurately a worse version of a horse [2]
If you looked through your other examples, you'd see the same for those as well.
Some things start as fads, but only time will tell if they gain a place in society.
Truthfully it's too early to tell for AI, but the arguments you're making, calling it a fad already don't stand up to reason
We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages.
By every performance metric, the new app was faster.
But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.
I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
You can write memory safe code in any language, but having a machine i.e. the Rust compiler check it for you is less error-prone than if a human does it.
Also if you look at the repo, only 3% of the codebase is in Assembly.
IMO if >95% project is in Rust, you can definitely claim it's a Rust project.
Parts of it could probably already exists in the LLM's corpus, but being able to join them together to build new things is what makes "vibe coding" so useful.
Even though, from personal experience, at scale it still falls apart
> To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
Interesting that you say it's more about providing "bindings", and not really "using". Much of the types in the svelte codebase are never exported outside of svelte, and they are only consumed internally.
The problem they were having was with transpilation, since the browser doesn't run JS.
From Rich Harris (months after svelte switched to JSDoc) [1]:
> removing types from your own code is clownish, epically misguided behaviour, but whatever — to each their own
I would suggest going through the issues and PRs in the codebase to see how invested the Svelte team is in typescript.
> TypeScript is not "real" static typing in the same sense as Go, Rust, C#.
That is true for Go, Rust, C#. But the same thing is also true for languages like C, and Generics in Java.
I'm sure both of those languages have weak type systems, but are definitely statically typed.
I think the fact that type information is lost after being compiled isn't really a classifier for typed/non-typed. Ultimately it all comes down to machine code, and that certainly isn't typed either.
Nue seems to be in an odd space. It's an untyped framework, built on top of "web standards".
But if you wanted web standards + web component, Lit already fills that space.
If you want untyped JS or little/no JS at all, there's HTMX.
Or if you're just tired of React, and want something faster + simpler, there's Svelte/Solid.
I'm not sure what problem Nue is uniquely solving.
USB microphones usually have audio converters built into them. So if you're going for a cheap wired headphones, it's usually better to go with one with a 3.5mm jack.
Using a targeted eval suite (like a test suite) tells us that.