Comment by ko27
3 days ago
Having the author come out and say that being untyped is a feature, is definitely one way to kill of any potential interest for that framework.
3 days ago
Having the author come out and say that being untyped is a feature, is definitely one way to kill of any potential interest for that framework.
For the record, author is not crazy.
Svelte team also switched to JS with JSDoc a few months back[0].
You can see the majority of their repo is JS and not TS[1]
The cited reason[2]:
There was a lot of noise when this happened. Rich Harris (Svelte team) even had a comment on this on HN[3]. Dev sphere similarly thought they were crazy. But Svelte seems fine and no one seems bothered by this now.
As long as author ships type def, it should behave just like a TypeScript library for all intents and purposes.
[0] https://news.ycombinator.com/item?id=35892250
From the link [3] you posted,
> If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you.
Rich and the rest of the Svelte team are still using typscript, just through JSDoc + type definition files.
In contrast the Nue team seems to want to keep the view layer untyped.
From the parent comment
> real static typing (like Rust or Go) shines in business logic where it counts
it seems they don't consider typescript to be "real" static typing.
TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.
Will happily accept:
At runtime (and thus the need for schema validators like Zod, Valibot, et al because dev-land "static typing" is a façade)
To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
Their codebase (as in the actual code they are writing) is undoubtedly JS[0] with `.d.ts` bindings for TypeScript[1]. Author can also do the same and provide TS bindings at any point in the future.
[0] https://github.com/sveltejs/svelte/blob/main/packages/svelte...
[1] https://github.com/sveltejs/svelte/blob/main/packages/svelte...
13 replies →
It’s not real static typing. A compiled typescript project is just javascript, which will still gladly accept incorrect types. The types only matter during compilation.
7 replies →
Svelte is a bad example. They have roughly identical type checking before and after that switch. The switch is mostly just an aesthetic preference for one syntax over another and an ideological stance about being able to run code directly in a browser without a build step.
It's not an "aesthetic preference"; it's a functional preference for debugging and iteration speed as cited by the team.
3 replies →
Which is quite hypocritical coming from a compiling framework and thus such a ridiculous stance.
We hate build steps in our build step.
> Svelte team also switched to JS with JSDoc a few months back
1. They still use types via JS Doc
2. They only switched to that for their internal development
3. User-facing code has all the type support and TS support you'd expect
> Rich Harris (Svelte team) even had a comment on this on HN[3].
And here's literally what he said:
--- start quote ---
Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won't affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever
--- end quote ---
Compare that to Nue's author's take
Svelte uses JSDoc and has TS validate that. Nue uses nothing. This analogy makes no sense.
Svelte still exposes types though, right? Like as a svelte user, you wouldn’t know it was written in JS?
I don’t use svelte, that’s just my understanding from when the TS -> JS switch was announced
JS with JSDoc is basically just awkward Typescript.
You're speaking as though it is a fact, but I think it depends on your coding style and temperament for iteration delays.
Author coming out here: Types matter, and Nue’s take is to use them where they truly shine. Adding them to naturally untyped spots like HTML or CSS? That’s just extra weight we can skip.
I prefer types over tests everywhere. If I’m passing props to a component and I get a TypeScript error, that’s a test I didn’t need to write or run. I love finding errors like this at compile time instead of at runtime. Just because HTML and CSS are untyped by default doesn’t say anything about whether types are useful for them. Does Nue have any way to protect against those kinds of errors or does some other architectural decision obviate the need for this kind of protection?
I’m not hating on Nue. At first glance, there’s a lot to like here, but I have to disagree on this point.
Neither HTML, nor CSS are naturally untyped.
Actually, React is not typed enough.
Looking at the mozilla docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sp...
You can see that eg. <span /> is not allowed to hold all types of elelemts.
How awsome weould it be, if th type system actually captures this.
I guess many web developers would climb on a roof and throw stones, because then they really needed to learn HTML and using its elements semantically. And probably many of their web components would no longer type check either, forcing them to reimplement or use simpler elements.
2 replies →
This is a great idea!
Your views are not "naturally untyped spots like HTML or CSS". They are custom templates with custom syntax and logic. And they would definitely benefit from types.
Some people like things that you might not like.