8 ms·

Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. N

Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. Nue flips it: presentation stays clean and semantic, web standards do the heavy lifting, and real static typing (like Rust or Go) shines in business logic where it counts. Thoughts on this?

seivan 2y ago
Jesus, this is a regression not a feature, for christ sake. Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.
isqueiros 2y ago
This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget. It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.
- joquarky 2y ago
  WebStorm and the like do a fine job inferring types, saving me a lot of time.
dalmo3 2y ago
That's one way to find a niche audience.
tossandthrow 2y ago
> ... slapping TypeScript on everything—even CSS—which is overkill Yikes, this framework will never fare well in any decent sized or above project. Even Typescript is problematic sometimes, as it has several forms of coercion. I manage 2 large scale production apps using Typescript (Along with the rest of the infrastructure) with a small team. This simply would not be possible, had I not been guaranteed that things at least type check when reading diffs from PRs.
- mplanchard 2y ago
  This is a silly take. There were certainly plenty of large projects written in JS before Typescript existed or became popular, some maintained by small teams or single individuals. There are plenty of large projects written in Python pre-typing, in PHP, etc. I personally choose to work with typed languages most of the time, and I’m thoroughly convinced of their value, but acting like it is literally impossible to write a large project without types is just inaccurate.
  - andai 2y ago
    The only way it's possible is if you keep them in your head.
  - tossandthrow 2y ago
    No, you are right, it is possible. But it would be significantly more expensive. So I should probably preface and say that it is not possible within the budget I have (We are ~2 full time developing and maintaining everything on a 140k LOC platform spanning from infrastructure, backend, multiple frontends).
    - tshaddox 2y ago
      Yeah, it just means those teams had to do a lot of work themselves which type systems do automatically. Given that the entire point of computing is automating things which a human could have done by hand, it makes more sense to talk about cost rather than capability.
    - Nijikokun 2y ago
      That feels more like you're being abused rather than a framework problem.
      - tossandthrow 2y ago
        We are not really over worked. Nobody puts in more than 30 hours, and we deliver the features the business need. However, we do have types and don't do type coercion. Types are sound full stack db -> backend -> frontends. We don't do any funky things. We don't use SSR (as the business does not require it). We test well, but not too much. We keep a sane architecture. We can also skip out on a lot of project shenanigans and mostly focus on our work. We don't (yet) use AI as a part of our workflows, and frankly, I don't see we can keep this way of working with the current gen AI.
mmkos 2y ago
I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.
- joquarky 2y ago
  I respect those who use and enjoy TS, but I have less respect for the argument that it should be used in place of JS everywhere. You’re replacing runtime trust with compile-time trust, but at the cost of flexibility and speed. That’s not always worth it. TypeScript solves problems I stopped having 20 years ago.
jack_riminton 2y ago
Uh oh, you've summoned the typesetters
ko27 2y 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 2y 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 2y 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 2y 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...
anentropic 2y ago
I am not on the React bandwagon, currently using HTMX But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.
davedx 2y ago
I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript. I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).
turnsout 2y ago
At that point, why not just use vanilla JS and no framework? Literally zero build time and zero bytes of framework code. And it's fast as hell.
herrherrmann 2y ago
I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.
arewethereyeta 2y ago
how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts
mexicocitinluez 2y ago
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill "We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.
- ellinoora 2y ago
  Making zero sense of your own take of the argument makes absolutely zero sense
  - mexicocitinluez 2y ago
    what?
    - leptons 2y ago
      >"We don't use Typescript because there are people that exist who use it for CSS when using React" This not at all what was being conveyed, you made that up in your head. The OP didn't say they were not using Typescript because someone else used it for CSS, but that's what you seem to have written.
      - vile_wretch 2y ago
        I mean it's quite literally "we don't use typescript because some developers over-use it" which is essentially the same thing
      - mexicocitinluez 2y ago
        > React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill It's actually EXACTLY what they're saying. They're using it as an example of why they don't use Typescript (ie people use React take it too far by using it for React). What does React that have anything to do with not using Typescript?
littlecranky67 2y ago
I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc. Any typos or invalid props/value will result in a compiler error.
madeofpalk 2y ago
> slapping TypeScript on everything—even CSS—which is overkill Nope. Hard disagree. I want the developer experience of autocompletion of CSS variables, and I want build errors when someone makes a mistake. Type everything.
troupo 2y ago
Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"
- joquarky 2y ago
  if (!user || typeof user.nam !== 'string') { throw new Error("Missing or invalid 'nam' on user"); } Contemporary JavaScript has optional chaining, default values, and reflective tools like Object.hasOwn, which are all web standards. You just have to know how to use them.
  - troupo 2y ago
    You really don't understand what types give you, do you? Where are you going to put the code above in this: <section @name="user-details" class="user"> <media :image="/app/icon/cc/{cc}.svg" :title="name"> <p>{ email }</p> </media> <dl :if="org"> <dt>Company</dt> <dd>{ org }</dd> <dt>Country</dt> <dd> { country }</dd> <dt>Company size</dt> <dd>{ size.desc } ({ size.label })</dd> <dt>Website</dt> <dd><a class="action">{ website }</a></dd> <dt>Plan</dt> <dd><pill icon="dot" :label="{ plan }"/></dd> </dl> <media-thumbs :items="shots"/> <chat-thread :thread="thread"/> </section> Are you going to write ifs for every permutation of possible typos? (Let's ignore for a second that it's not just typos)
spiffytech 2y ago
Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help. In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win. Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.
- mubou 2y ago
  I agree. It's far too easy to make a change to your model that removes/renames some property, but not update one template that you forgot uses it too. Without screendiff testing, that sort of bug will easily make it into prod. This is one of the reasons I like C#'s .cshtml (Razor) syntax. The entire file is compiled to C#, so when you do `<div>@Model.Foo</div>` the build will fail if Foo doesn't exist. String-based (rather than compiled) view templating is, IMO, a mistake.
barrell 2y ago
There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers. I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them. So personally I find standard js a huge selling point :)
Etheryte 2y ago
Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.
jeffhuys 2y ago
Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously. ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us. /rant.
- tipiirai 2y ago
  Please. It's me typing: Tero "tipiirai". I’m Finnish, not a bot. Documentation? Mostly me, some help from contributors. Comments here? Check my HN history. This stuff is impossible to prove.
  - jeffhuys 2y ago
    Of course it's impossible to prove, which is why so many people are doing it, like you/your team, at least recently. At some point in the past your blog seems to have gone from "real" to "slop". I've seen enough LLM sh*t to know. I know you'll never admit this. I don't care about that. But please understand that your credibility goes out of the window with this; it doesn't make it look more professional, especially to developers. If I'm extremely wrong here, I genuinely apologize, but I would be very, very surprised.
tshaddox 2y ago
I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.
johnfn 2y ago
Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.

seivan 2y ago

Jesus, this is a regression not a feature, for christ sake. Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.

isqueiros 2y ago

This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget. It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.

joquarky 2y ago
WebStorm and the like do a fine job inferring types, saving me a lot of time.

dalmo3 2y ago

That's one way to find a niche audience.

tossandthrow 2y ago

> ... slapping TypeScript on everything—even CSS—which is overkill Yikes, this framework will never fare well in any decent sized or above project. Even Typescript is problematic sometimes, as it has several forms of coercion. I manage 2 large scale production apps using Typescript (Along with the rest of the infrastructure) with a small team. This simply would not be possible, had I not been guaranteed that things at least type check when reading diffs from PRs.

mplanchard 2y ago
This is a silly take. There were certainly plenty of large projects written in JS before Typescript existed or became popular, some maintained by small teams or single individuals. There are plenty of large projects written in Python pre-typing, in PHP, etc. I personally choose to work with typed languages most of the time, and I’m thoroughly convinced of their value, but acting like it is literally impossible to write a large project without types is just inaccurate.
- andai 2y ago
  The only way it's possible is if you keep them in your head.
- tossandthrow 2y ago
  No, you are right, it is possible. But it would be significantly more expensive. So I should probably preface and say that it is not possible within the budget I have (We are ~2 full time developing and maintaining everything on a 140k LOC platform spanning from infrastructure, backend, multiple frontends).
  - tshaddox 2y ago
    Yeah, it just means those teams had to do a lot of work themselves which type systems do automatically. Given that the entire point of computing is automating things which a human could have done by hand, it makes more sense to talk about cost rather than capability.
  - Nijikokun 2y ago
    That feels more like you're being abused rather than a framework problem.
    - tossandthrow 2y ago
      We are not really over worked. Nobody puts in more than 30 hours, and we deliver the features the business need. However, we do have types and don't do type coercion. Types are sound full stack db -> backend -> frontends. We don't do any funky things. We don't use SSR (as the business does not require it). We test well, but not too much. We keep a sane architecture. We can also skip out on a lot of project shenanigans and mostly focus on our work. We don't (yet) use AI as a part of our workflows, and frankly, I don't see we can keep this way of working with the current gen AI.

mmkos 2y ago

I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.

joquarky 2y ago
I respect those who use and enjoy TS, but I have less respect for the argument that it should be used in place of JS everywhere. You’re replacing runtime trust with compile-time trust, but at the cost of flexibility and speed. That’s not always worth it. TypeScript solves problems I stopped having 20 years ago.

jack_riminton 2y ago

Uh oh, you've summoned the typesetters

ko27 2y 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 2y 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 2y 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 2y 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...

anentropic 2y ago

I am not on the React bandwagon, currently using HTMX But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.

davedx 2y ago

I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript. I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).

turnsout 2y ago

At that point, why not just use vanilla JS and no framework? Literally zero build time and zero bytes of framework code. And it's fast as hell.

herrherrmann 2y ago

I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.

arewethereyeta 2y ago

how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts

mexicocitinluez 2y ago

> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill "We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.

ellinoora 2y ago
Making zero sense of your own take of the argument makes absolutely zero sense
- mexicocitinluez 2y ago
  what?
  - leptons 2y ago
    >"We don't use Typescript because there are people that exist who use it for CSS when using React" This not at all what was being conveyed, you made that up in your head. The OP didn't say they were not using Typescript because someone else used it for CSS, but that's what you seem to have written.
    - vile_wretch 2y ago
      I mean it's quite literally "we don't use typescript because some developers over-use it" which is essentially the same thing
    - mexicocitinluez 2y ago
      > React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill It's actually EXACTLY what they're saying. They're using it as an example of why they don't use Typescript (ie people use React take it too far by using it for React). What does React that have anything to do with not using Typescript?

littlecranky67 2y ago

I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc. Any typos or invalid props/value will result in a compiler error.

madeofpalk 2y ago

> slapping TypeScript on everything—even CSS—which is overkill Nope. Hard disagree. I want the developer experience of autocompletion of CSS variables, and I want build errors when someone makes a mistake. Type everything.

troupo 2y ago

Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"

joquarky 2y ago
if (!user || typeof user.nam !== 'string') { throw new Error("Missing or invalid 'nam' on user"); } Contemporary JavaScript has optional chaining, default values, and reflective tools like Object.hasOwn, which are all web standards. You just have to know how to use them.
- troupo 2y ago
  You really don't understand what types give you, do you? Where are you going to put the code above in this: <section @name="user-details" class="user"> <media :image="/app/icon/cc/{cc}.svg" :title="name"> <p>{ email }</p> </media> <dl :if="org"> <dt>Company</dt> <dd>{ org }</dd> <dt>Country</dt> <dd> { country }</dd> <dt>Company size</dt> <dd>{ size.desc } ({ size.label })</dd> <dt>Website</dt> <dd><a class="action">{ website }</a></dd> <dt>Plan</dt> <dd><pill icon="dot" :label="{ plan }"/></dd> </dl> <media-thumbs :items="shots"/> <chat-thread :thread="thread"/> </section> Are you going to write ifs for every permutation of possible typos? (Let's ignore for a second that it's not just typos)

spiffytech 2y ago

Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help. In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win. Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.

mubou 2y ago
I agree. It's far too easy to make a change to your model that removes/renames some property, but not update one template that you forgot uses it too. Without screendiff testing, that sort of bug will easily make it into prod. This is one of the reasons I like C#'s .cshtml (Razor) syntax. The entire file is compiled to C#, so when you do `<div>@Model.Foo</div>` the build will fail if Foo doesn't exist. String-based (rather than compiled) view templating is, IMO, a mistake.

barrell 2y ago

There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers. I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them. So personally I find standard js a huge selling point :)

Etheryte 2y ago

Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.

jeffhuys 2y ago

Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously. ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us. /rant.

tipiirai 2y ago
Please. It's me typing: Tero "tipiirai". I’m Finnish, not a bot. Documentation? Mostly me, some help from contributors. Comments here? Check my HN history. This stuff is impossible to prove.
- jeffhuys 2y ago
  Of course it's impossible to prove, which is why so many people are doing it, like you/your team, at least recently. At some point in the past your blog seems to have gone from "real" to "slop". I've seen enough LLM sh*t to know. I know you'll never admit this. I don't care about that. But please understand that your credibility goes out of the window with this; it doesn't make it look more professional, especially to developers. If I'm extremely wrong here, I genuinely apologize, but I would be very, very surprised.

tshaddox 2y ago

I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.

johnfn 2y ago

Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.