Comment by davedx 11 days ago
This is what they're replacing react with: https://nuejs.org/docs/view.html
It's an untyped view layer kind of along the lines of early angular 2.0.
The model files are plain javascript.
So no typings anywhere. Which is fine, I guess this is targeting the vuejs crowd. Maybe their marketing should pivot a little bit in that direction, most react people now use TypeScript because first class types in your view layer are super useful
> ... 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).
> 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/
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.
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.
> 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.
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.
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 :)
Vue with SFCs is not actually typescript because typescript can not parse the SFC syntax, you need a forked typescript called `vue-tsc` for that.
Shows what a hack vue really is.
Sadly not because it's been about 6 years since I looked at it! (We ended up switching to React.)
IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.
I'm sure I would find many more issues if I was using it in anger, because it's building on a foundation that didn't have Typescript in mind. E.g. see this thread:
https://www.reddit.com/r/vuejs/comments/l456fl/is_vue_3_real...
> most react people now use TypeScript because first class types in your view layer are super useful
Most people use TypeScript because React apps have grown to 200k lines of mostly entangled code with business logic and are unmanageable without it.
If one goes in a different direction there's less need for it.
I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.
Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.
If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.
There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.
You could always massively reduce the frontend by not duplicating half the backend business logic in the browser. By not having isolated backend/frontend teams off in their own worlds and only using fancy JS where fancy JS is actually needed.
Server rendering of JS only gets you partially in a better state when the fundamental idea is based around generating a massive amount of JS for the browser.
> I guess this is targeting the vuejs crowd
Typescript support and usage with Vue is very large. Vue itself is written in TS and most large libs are also written in TS. According to /r/vuejs and my personal experience also most new apps.
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?