5 ms·

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.

by ko27 1y ago

CharlieDigital 1y ago
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]: > As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS. 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=35932617 https://news.ycombinator.com/item?id=35932617 [1] https://github.com/sveltejs/svelte https://github.com/sveltejs/svelte [2] https://github.com/sveltejs/svelte/pull/8569 https://github.com/sveltejs/svelte/pull/8569 [3] https://news.ycombinator.com/item?id=35892250 https://news.ycombinator.com/item?id=35892250
- unchar1 1y ago
  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.
  - CharlieDigital 1y ago
    TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it. function fn(x: string) {} Will happily accept: fn(2) At runtime (and thus the need for schema validators like Zod, Valibot, et al because dev-land "static typing" is a façade) > Rich and the rest of the Svelte team are still using typscript 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/src/compiler/utils/builders.js https://github.com/sveltejs/svelte/blob/main/packages/svelte... [1] https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/compiler/preprocess/public.d.ts https://github.com/sveltejs/svelte/blob/main/packages/svelte...
    - tossandthrow 1y ago
      And this is definitely a problem. Had I had the opportunity to choose a language across the entire stack with mature wide adopted frameworks and libraries, I had done it. Had there been something line Rust, Go, Java, C#, etc. that would work end to end, that would have been amazing. In practice, even the weak safety typescript provides catches so many bugs before they hit production that it is indeed worth it - I have more than 140k LOCs of Typescript in production, and that would not be manageable without types.
      - CharlieDigital 1y ago
        > I have more than 140k LOCs of Typescript in production, and that would not be manageable without types The Svelte team achieved it with JSDoc. Google's JS style guide also focuses on JSDoc for the same reasons[0]. And to be just a tad pedantic: you have JS in production; your TS is only in dev. > Go, Java, C#, etc. that would work end to end, that would have been amazing. It's not that you can't; it's that you choose not to (and yes, generally for good and valid reasons). There are end-to-end solutions for C# (e.g. Blazor), for example, that are perfectly fine depending on your use case (not great for all use cases). Fable is another example using F#[1] There are also libraries like Bootsharp[2] that are doing interesting things, IMO, and has some of the same energy as OP's project (moving the typing and logic into a runtime that supports runtime static types and interfacing minimally with JS) [0] https://google.github.io/styleguide/jsguide.html#jsdoc https://google.github.io/styleguide/jsguide.html#jsdoc [1] https://fable.io/docs/ https://fable.io/docs/ [2] https://sharp.elringus.com/ https://sharp.elringus.com/
  - mplanchard 1y ago
    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.
    - oynqr 1y ago
      > The types only matter during compilation. That's pretty much the definition of static typing.
    - recursive 1y ago
      This is the real-est static typing that exists. "Static" refers to build time. By definition static types are checked at build time, not run time. If you want types to be checked at run time, that's called "dynamic" typing.
      - mplanchard 1y ago
        Sure, you're technically correct. But TS is compiled in to JS, which is dynamically typed at runtime. You're still ultimately in a dynamically typed language. In addition, in a typical statically typed, compiled language, your only place where you interact with data that isn't guaranteed to be type-conformant is at a foreign function interface, whereas in Typescript all your interaction with third-party libraries is via regular JS and may or may not be type conformant.
        recursive 1y ago
        Is there such a thing as a statically typed language? CPU opcodes don't type-check their parameters.
        throwaway894345 1y ago
        Rust compiles into WASM, x86, etc, which are dynamically typed for all intents and purposes. They certainly don't understand or enforce Rust's type system invariants any more than JavaScript enforces TypeScript invariants. If you call a Rust function from WASM and pass it malformed data, the WASM runtime will happily execute it. (pretty sure WASM actually has some integer types, so I guess maybe it is technically "statically typed" but not in any interesting sense--we could similarly say that JavaScript is "statically typed" because every variable has a static "any" type).
- IshKebab 1y ago
  JS with JSDoc is basically just awkward Typescript.
  - joquarky 1y ago
    You're speaking as though it is a fact, but I think it depends on your coding style and temperament for iteration delays.
- tshaddox 1y ago
  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.
  - CharlieDigital 1y ago
    It's not an "aesthetic preference"; it's a functional preference for debugging and iteration speed as cited by the team.
    - tshaddox 1y ago
      Fair enough. Perhaps what I mean is that they don’t have a strong aesthetic opposition to JSDoc, which is presumably rare among TypeScript developers.
    - nsonha 1y ago
      https://news.ycombinator.com/item?id=43548647 https://news.ycombinator.com/item?id=43548647
    - joquarky 1y ago
      This is why I prefer to stick with JS and JSDoc. I have been doing pro webdev since 1995 and since I got my initial experience without all of the contemporary tooling, my process has evolved to require very rapid iteration: the delay of a compile step can often break my concentration and prevent a flow state.
  - sureIy 1y ago
    Which is quite hypocritical coming from a compiling framework and thus such a ridiculous stance. We hate build steps in our build step.
- chamomeal 1y ago
  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
- johnfn 1y ago
  Svelte uses JSDoc and has TS validate that. Nue uses nothing. This analogy makes no sense.
- troupo 1y ago
  > 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
tipiirai 1y ago
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.
- tossandthrow 1y ago
  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/span#technical_summary 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.
  - zelphirkalt 1y ago
    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.
    - tossandthrow 1y ago
      There was a time where front-end devs would have sat down and cried had they had to make closing tags.
      - joquarky 1y ago
        Ever heard of XHTML? There's a reason it's dead.
  - tipiirai 1y ago
    This is a great idea!
- dimal 1y ago
  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.
joquarky 1y ago
Some people like things that you might not like.

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.

by ko27 1y 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.

CharlieDigital 1y ago

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]: > As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS. 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=35932617 https://news.ycombinator.com/item?id=35932617 [1] https://github.com/sveltejs/svelte https://github.com/sveltejs/svelte [2] https://github.com/sveltejs/svelte/pull/8569 https://github.com/sveltejs/svelte/pull/8569 [3] https://news.ycombinator.com/item?id=35892250 https://news.ycombinator.com/item?id=35892250

unchar1 1y ago
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.
- CharlieDigital 1y ago
  TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it. function fn(x: string) {} Will happily accept: fn(2) At runtime (and thus the need for schema validators like Zod, Valibot, et al because dev-land "static typing" is a façade) > Rich and the rest of the Svelte team are still using typscript 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/src/compiler/utils/builders.js https://github.com/sveltejs/svelte/blob/main/packages/svelte... [1] https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/compiler/preprocess/public.d.ts https://github.com/sveltejs/svelte/blob/main/packages/svelte...
  - tossandthrow 1y ago
    And this is definitely a problem. Had I had the opportunity to choose a language across the entire stack with mature wide adopted frameworks and libraries, I had done it. Had there been something line Rust, Go, Java, C#, etc. that would work end to end, that would have been amazing. In practice, even the weak safety typescript provides catches so many bugs before they hit production that it is indeed worth it - I have more than 140k LOCs of Typescript in production, and that would not be manageable without types.
    - CharlieDigital 1y ago
      > I have more than 140k LOCs of Typescript in production, and that would not be manageable without types The Svelte team achieved it with JSDoc. Google's JS style guide also focuses on JSDoc for the same reasons[0]. And to be just a tad pedantic: you have JS in production; your TS is only in dev. > Go, Java, C#, etc. that would work end to end, that would have been amazing. It's not that you can't; it's that you choose not to (and yes, generally for good and valid reasons). There are end-to-end solutions for C# (e.g. Blazor), for example, that are perfectly fine depending on your use case (not great for all use cases). Fable is another example using F#[1] There are also libraries like Bootsharp[2] that are doing interesting things, IMO, and has some of the same energy as OP's project (moving the typing and logic into a runtime that supports runtime static types and interfacing minimally with JS) [0] https://google.github.io/styleguide/jsguide.html#jsdoc https://google.github.io/styleguide/jsguide.html#jsdoc [1] https://fable.io/docs/ https://fable.io/docs/ [2] https://sharp.elringus.com/ https://sharp.elringus.com/
- mplanchard 1y ago
  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.
  - oynqr 1y ago
    > The types only matter during compilation. That's pretty much the definition of static typing.
  - recursive 1y ago
    This is the real-est static typing that exists. "Static" refers to build time. By definition static types are checked at build time, not run time. If you want types to be checked at run time, that's called "dynamic" typing.
    - mplanchard 1y ago
      Sure, you're technically correct. But TS is compiled in to JS, which is dynamically typed at runtime. You're still ultimately in a dynamically typed language. In addition, in a typical statically typed, compiled language, your only place where you interact with data that isn't guaranteed to be type-conformant is at a foreign function interface, whereas in Typescript all your interaction with third-party libraries is via regular JS and may or may not be type conformant.
      - recursive 1y ago
        Is there such a thing as a statically typed language? CPU opcodes don't type-check their parameters.
      - throwaway894345 1y ago
        Rust compiles into WASM, x86, etc, which are dynamically typed for all intents and purposes. They certainly don't understand or enforce Rust's type system invariants any more than JavaScript enforces TypeScript invariants. If you call a Rust function from WASM and pass it malformed data, the WASM runtime will happily execute it. (pretty sure WASM actually has some integer types, so I guess maybe it is technically "statically typed" but not in any interesting sense--we could similarly say that JavaScript is "statically typed" because every variable has a static "any" type).
IshKebab 1y ago
JS with JSDoc is basically just awkward Typescript.
- joquarky 1y ago
  You're speaking as though it is a fact, but I think it depends on your coding style and temperament for iteration delays.
tshaddox 1y ago
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.
- CharlieDigital 1y ago
  It's not an "aesthetic preference"; it's a functional preference for debugging and iteration speed as cited by the team.
  - tshaddox 1y ago
    Fair enough. Perhaps what I mean is that they don’t have a strong aesthetic opposition to JSDoc, which is presumably rare among TypeScript developers.
  - nsonha 1y ago
    https://news.ycombinator.com/item?id=43548647 https://news.ycombinator.com/item?id=43548647
  - joquarky 1y ago
    This is why I prefer to stick with JS and JSDoc. I have been doing pro webdev since 1995 and since I got my initial experience without all of the contemporary tooling, my process has evolved to require very rapid iteration: the delay of a compile step can often break my concentration and prevent a flow state.
- sureIy 1y ago
  Which is quite hypocritical coming from a compiling framework and thus such a ridiculous stance. We hate build steps in our build step.
chamomeal 1y ago
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
johnfn 1y ago
Svelte uses JSDoc and has TS validate that. Nue uses nothing. This analogy makes no sense.
troupo 1y ago
> 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

tipiirai 1y ago

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.

tossandthrow 1y ago
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/span#technical_summary 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.
- zelphirkalt 1y ago
  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.
  - tossandthrow 1y ago
    There was a time where front-end devs would have sat down and cried had they had to make closing tags.
    - joquarky 1y ago
      Ever heard of XHTML? There's a reason it's dead.
- tipiirai 1y ago
  This is a great idea!
dimal 1y ago
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.

joquarky 1y ago

Some people like things that you might not like.