Comment by tipiirai 11 days ago
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?
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.
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).
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.
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.
> There are plenty of large projects written in Python.
There are, but they are certainly a pain in the ass to work with.
I once had to work on a semi-large Python codebase and got so frustrated that I wanted to port the code to some other language. The best part? I wrote the majority of that codebase myself, just months earlier.
I ranted about it here: https://avi.im/blag/2023/refactoring-python/
Yeah I mean, I've worked on a multi-million-line Python 2 codebase. It wasn't easy, but it certainly wasn't impossible.
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.
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]:
> 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.
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
[1] https://github.com/sveltejs/svelte
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.
function fn(x: string) {}
fn(2)
> Rich and the rest of the Svelte team are still using typscript
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...
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.
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.
> 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
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.
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.
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.
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.
> 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.
>"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.
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.
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.
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.
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).
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
if (!user || typeof user.nam !== 'string') {
throw new Error("Missing or invalid 'nam' on user");
}
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"/>Are you going to write ifs for every permutation of possible typos? (Let's ignore for a second that it's not just typos)
> 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.
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.
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.
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.
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.
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.
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 :)
> ... 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.