Comment by tipiirai
3 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?
> ... 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.
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).
3 replies →
> 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/
3 replies →
The only way it's possible is if you keep them in your head.
> There are plenty of large projects written in Python
I've worked on one of those, and I would not recommend it.
> There are plenty of large projects written in Python pre-typing, in PHP, etc.
Just a nit. Modern PHP is typed and has been for years.
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.
WebStorm and the like do a fine job inferring types, saving me a lot of time.
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.
22 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.
5 replies →
> 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.
1 reply →
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.
4 replies →
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.
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.
Making zero sense of your own take of the argument makes absolutely zero sense
what?
3 replies →
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.
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
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).
That's one way to find a niche audience.
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.
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`"
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.
You really don't understand what types give you, do you?
Where are you going to put the code above in this:
</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)
> 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.
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.
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.
Uh oh, you've summoned the typesetters
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.
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.
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.
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 :)