IMO, don't touch this. All of this has been tried before. It also looks like lists are unkeyed. If you receive another list from the server, you have to do the diffing yourself.
It's disappointing that a framework proclaiming to solve all issues of frontend dev, while evidently understanding none of them, will go uncriticised by HN.
Will go uncriticized? The comments are full of these kinds of posts dismissing it off hand based mostly on self-declared "understanding".
The ceremony and huge verbose architecture astronaut frameworks has been tried before. But the people on this enterprisey very professional corporate busywork hype train are probably too inexperienced to rember the SOAPs and J2EEs and Enterprise Java Beans and dependency injection frameworks and Boosts to understand what drag they are to development and software quality.
It'll blow over again in a few years but it's quite sad that the same mistakes have to be repeated.
I am from Finland but Pekka is the beginning of my surname. The nick is just some old system-assigned login name that stuck (your's seems the same).
Thank you for Nue and bringing much needed simplicity and elegance to frontend dev! I'll be sure to at least try out Nue for the next frontend project that could benefit from a framework.
Keys are unnecessary in Nue, just like many, many other framework abstractions. If you receive another list from the server, Nue takes care of it automatically. No need for diffing.
"Keys are unnecessary" in what way? The only reason they are necessary in React etc. is to keep DOM mutations to a minimum. Are keys unnecessary because you always re-render the whole list, making for very inefficient updates?
True. When the array changed, the view is indeed re-rendered. Nue is probably not a good pick ATM for UI's with hundreds of rows and when list re-rendering performance is critical. I'll add the key- support if this becomes a frequent issue.
It's not just about performance, although that is of course a big part. What if I have child components with state that I don't want re-rendered? Suddenly I have to track the state in the parent to keep it from disappearing on every array change.
This has big architectural implications, and it worries me a bit that you only see it as relevant for benchmarks.
This becomes a frequent issue in any app at scale.
If your app is at a small enough scale that it doesn't run into this issue, I would not recommend using a framework: just use vanillajs &/or some modular utility components.
If you're working on a small app & want to do it in a framework because you anticipate scale, use one with key support.
Hardly a frequent issue. I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 — that all needs to be completely changed in one operation without re-rendering.
It's a common theme in benchmarking apps though, which will ultimately be the main reason for adding the key support.
1) In general, in the open-source community, there's a LOT of JS frameworks and many of them have caused developer frustration. This has lead to people being generally more skeptical of ANY new framework, just because there's so many & its considered a saturated space, so critique will be more strict.
2) With JS taking over as the "everything language", there's also some general backlash against JS itself.
3) On HN, this is even more pronounced for some reason.
However, apart from the above, most of the negative comments seem to just be direct replies to certain claims you've made on HN (keys unnecessary & the ES6 DSL): there aren't as many negative comments on the actual submitted website. Personally I quite like it - I particularly love the narrative history lesson & to-the-point inline examples; you're a great communicator. As for thte library, there's elegance in simplicity, & while the framework may not be practical at the moment for some applications, there's still value in using software that is essential grokkable.
You're trying to upset the applecart by saying your "framework", which has been developed in relative isolation, is better than the other top 4 contenders. Well, you better have some hard proof of that.
I was talking about the applications I personally use frequently, like Slack for example. Unlike the parent said that "this becomes a frequent issue in any app at scale", I just don't see this happening on the UI's I personally use.
Having said that: they key-optimization thing will be implemented. The more frequent issues get a higher priority. Maybe it's this one.
I built an app that listed all 20,000+ of my blade computers on a single long page. They were arranged in a grid that mapped to the way they were racked in the data center, which made it super easy for a technician to get an overview of the status of the entire system. 12 blades per chassis and 1-8 chassis per rack.
The page took about 2-3 seconds to load (mostly downloading the json data to render the page), but once it loaded, it rendered and more importantly, updated very quickly as new data would roll in. If I had to re-render the entire dom every time there was an update, the page would have been unusable.
It feels like you can't see past your personal use case. You're trying to convince HN that your framework is better than the top 4 projects out there and HN is pushing back and saying... umm... no.
Note that Nue will probably work just fine for your use case. The list is not re-rendered when individual items on the list are updated or when new items are added. Currently only re-rendered when the whole list is sorted or replaced with a new one. Based on the feedback here looks like I need to optimize these two mass-operations as well.
Indeed. It's rare to see real-world scenarios where thousands of items are mass-manipulated on the client side. They exist, but rarely. The lists are typically appended/prepended or individual items are updated.
> Indeed. It's rare to see real-world scenarios where thousands of items are mass-manipulated on the client side. They exist, but rarely.
I'm not sure this is correct. Almost all apps that I write that display live data are built by replacing the whole client-side array with updated server-side array data, and the other commenters seems to work similarly. With your current approach I'd have to write a complete diffing logic to modify the array in-place locally, especially if I don't want child components to be re-mounted.
Having just count=0 is stupid and you will learn it the same way as Svelte did. Comparing it like that when they explain all the issues in Svelte 5 is even more dishonest. Any variable can be state and/or be reactive and they arent marked? GL with that. You need to manually call update after fetching data, why?
> Having just count=0 is stupid and you will learn it the same way as Svelte did.
I obviously disagree. This is not only compact, but also standards- based. It's an ES6 variable. I don't expect Nue to change here, like ever. Svelte internals are quite different.
I think you are insane for this take. It should be very clear from a cursory glance what is reactive and what is not if you want your code to not become spaghetti rapidly.
Signals w/ getter/setter are incredibly nice for this.
Insane is cool. Nue is a heavy promoter of the separation of concerns pattern — which is the most effective way to avoid mixing different kinds spaghetti ingredients together. These small, extra $- characters are minor factors.
I love your attitude. This library is not for me right now but I appreciate the pioneering. React also got a lot of hate in the beginning ("re-render on every change is insane"), people forget. Good luck!
I'm not sure I'm convinced. If I open a random file in a project and see `count=0`, how do I know if it's a global variable used by legacy code, a reactive variable, or something else entirely?
This explanation can be used for any library though, consider that you know how the internals work, then it's rather obvious. If you don't know Nue and stumble on this it's just another flavor of unknown black box. Sure, the syntax might be nice for you, just like Awk and Vim are nice for some people, but it doesn't mean other people have a chance of understanding what's going on without looking up the documentation.
Speaking of which, how do you interface with global variables in that case? Say I want to instantiate a global variable when the component is created, how do I do that?
The core difference is that in that case what's happening is clear from the code, functional components start off with a function declaration whereas class components start off with a class declaration. This isn't true for Nue, you have to have read the docs to understand anything that's going on, otherwise you have no clue. In general though, while I understand it's your project and you have strong emotions towards it, looking through the rest of the comments it doesn't shine a good light on the project if you argue tooth and nail against any and every criticism. Many of the criticisms are perfectly valid, a lot of these things have been tried before and there's reasons why there were abandoned.
Hmmm.... I think that's because to use one of the React hooks you need to import them from React. If you create your own hook it'll eventually use something like "useState" internally, which leads you to "import { useState } from 'react'".
Functional components on their own are not distinguishable from a good old Javascript function. I guess the presence of JSX and/or hooks give it away. I'd say it's half true that glancing at a random .js file it might not be immediately obvious if it's React or a function, but with some digging you should be able to find out by following the imports.
It's absolutely not an ES6 variable. count=0 may be valid ES6 but in a NueJS setup it's not parsed by the JS interpreter: it's preprocessed. What actually gets served and parsed by the browser is an entirely different piece of code & that makes it inherently changeable in future releases.
Also, while count=0 is technically valid ES6, most of the larger examples on the page are not; this is a DSL like any other, with all the drawbacks that brings. Masquerading as ES6 syntax won't fix that.
It is _absolutely_ an ES6 variable. Nue transpiler takes the code between the script tags and creates a true ES6 class instance from it. The larger examples are no different from the count=0 in here.
The argument being made here is that the pre-compiled code is not ES6. Of course the compiled code is - I can't see how that's relevant, that's the same for every JS FE DSL.
The code inside the script tags is ES6, the pre-processor does not "masquerade" it as the parent commenter says. It's taken as is. Also not sure what in this discussion is relevant.
> The code inside the script tags is ES6, the pre-processor does not "masquerade" it as the parent commenter says. It's taken as is.
This is flatly untrue - multiple commenters have outlined why this is untrue above.
> Also not sure what in this discussion is relevant.
It's relevant because the original comment is advocating for Nue.js on the basis that the DSL is standards-based, which is untrue. Designing something that looks like a standard without actually adhering to that standard does not equate to being standards based, nor does it benefit from any of the advantages of a standards-based approach.
---
fwiw, while my use of the word "untrue" above seems strong, I want to state clearly that I don't believe you're deliberately trying to mislead anyone here. Your intent seems benign, but I would just suggest learning a little bit more about the approachs of various frameworks, templating systems & DSLs over the years.
for my surprise, count=0 is indeed ES6. I thought const, let or var were mandatory but it seems to not be the case.
On Nue.js case tho the count=0 is misleading as it is a class variable that can get a setter and getter but in Nue.js code it is a normal variable that can't have a getter/setter. So the code doesn't really do what it is supposedly doing.
a Nue "count = 0;" isn't the same as a ES6 "count = 0;". It needs compilation. I think trying to convince developers of the opposite won't help much grow a community.
When a Nue component is compiled it creates a native ES6 class directly from the contents of the inner script tag. The ES6 code is not traversed at all, let alone altered. That is: count = 0 is a native ES6 class instance variable.
The update() method is there because Nue does not make a difference between reactive variables and other variables and it's impossible to know if a state changed when there is no specific DOM event or array manipulation call.
I think its kinda great its on the front page, I only work in backend so this looks quite appealing like ALL tech demos do. Love to see it pulled apart in comments with explanations I understand haha
This is the cycle of JavaScript frameworks. You create something deceivingly simple that tramples upon idiomatic usage but looks great for a todo app. Beginners realize the hard way that this doesn't scale because deep reactivity shouldn't be a default, they no longer know what a vanilla JS variable should behave like, and code is un-readable.
Let the bundler minify your JavaScript. Less characters !== simple.
I prefer thinking scalability more literally (like Chris Coyier): an approach that works for a small site and remain the same approach for a large site. Nue's approach is MVC, which is a project not released yet. Check: https://nuejs.org/tools/
Less characters in source code is obviously a better metric for simplicity than what there are on the minified code (Nue wins on both btw)
I appreciate your effort on creating a full ecosystem from the ground up. I'm doing the same, the more the better. It brings me an old time hackers vibe.
We don't need 10s of VC-backed frameworks trying to lockdown users to cash them. I hope you plan to continue doing this work by yourself in place of launching a PaaS/SaaS on top of it.
The best kind of JS framework is no framework, especially for small teams.
Especially now that self encapsulating modules are a thing and server side templating can fill in html's lack of import tags. Reusable components sound great in principle, but trying to replace one that's used in 30 different locations with small nuances in each spot leads to complete debugging hell, just like typical overzealous polymorphism.
Allegedly we're even getting optional typing soon, so TS will become obsolete as well.
I was referring to just general JS modules that can import other modules but don't see the global scope, which was arguably the main problem with vanilla JS. But web components are awesome as well, albeit not as critical.
Author here. After releasing Nue JS here just two weeks ago[1], the most common questions were: “How does reactivity work”? and “How is this different from Svelte”? This article attempts to answer those.
I don't need to "justify" their immaterialness. The OP needs to explain how it is material.
But whatever...
The merits of ES6 are also present in typescript. Thus claim 1 is immaterial.
Claim two is rebuked by intellisense and very strongly argued against in a shared-code world.
Claim 3 is presumptive that TypeScript would be the only transpilation, despite nue itself being a transpiler. In addition to all the other bundling modern products use for treeshaking, minification, etc. This is an insignificant and thus immaterial point.
Jenk — can you help me with a list of valid reasons to choose JavaScript so that the TypeScript community is pleased? This would help me a lot. Thank you!
I would love to but I just can't see how it could be done.
I am interpreting the task as "how can we make people who favour strong typing favour not use strong typing?" - something that I just don't think is possible.
I guess the nearest experience you'll get is a zealous API convention that is inuitively consistent/discoverable, but then I would still favour a type system to remove that concern anyway.
The question is more like: "What are the benefits of choosing JavaScript over TypeScript?" You must know that there are pros and cons in every language. There is a reason languages like JS, Python, Zig, C, Go, Rust.. exist.
I was asking you to take a little distance from the TS-world and use your experience (and maybe emphaty) to look about the pros of JS. Preferrably a list that pleases the TS community. The fact that JS is an "universal language" and runs natively on browsers and Node is a definite one, but then again.. this was a question for you.
2. Code completion can be done also without static typing. Also relying on code completion is a strong smell of a bad codebase. The "very strong arguments" rarely have any empirical basis.
3. Transpilers/compilers are bad and more transpilers are worse. I would prefer a pure browser framework though. A lot of projects would be and are fine without treeshaking, minification etc. And those are practically never needed for development where the compilation step causes most harm.
More than a few lines in a Hello World example is a very damning argument against a framework.
Less code is better and DRY is by far the most important principle in software engineering.
Sadly every second generation seems to have to learn the hard way that the mega enterprise architecture astronaut stuff is a huge waste of time and produces bad software.
DRY is by far the most overrated software engineering principle and constantly pushing for it only leads more developers down the way of creating wrong, irreversible abstractions.
Interop, achievable via web components, is far more important than syntax, the last ms of performance, or shaking of 1kb in large applications contexts.
Hence, I strongly encourage the author to compile to web components instead of a custom output to increase/achieve interop.
Please read the whole sentence. It starts with: If React is “Just JavaScript, then...” React users often say that "It's just JavaScript" but then they write:
The "it's just javascript" part comes from having no hidden getters, setters or proxies littered in code that may or may not behave as how we expect, and not littering the html with react-specific attributes for iteration, events, etc
It surely is. React is a good pick for frontend engineers who prefer to use JavaScript or TypeScript. Nue is designed for UX engineers, who prefer a HTML- like syntax for defining the structure & layout.
It's funny how React and other frameworks spent so much effort abstracting the render loop, meanwhile Nue is just like "call update()". And in the end, Nue looks a lot simpler to use.
Than what? I couldn't imagine react being hard, maybe for novice developers that just start with programming in general.
> React and other frameworks spent so much effort abstracting the render loop
Considering how big is community adoption and teams that are working on big 3 frameworks, they're doing it not "just because" and not to make your app slower. There are reasons for this and this new library will learn them as well, just like svelte did with their reactive variables approach.
Now I'm curious. Why do you suppose the render loop's performance was so important to the React team, then? It surely wasn't for no reason, and I'm not going to be convinced that React is more complex "just because."
I am very impressed by the examples, they are so easy to read. I have zero experience with React, Svelte and JS in general, but after reading the examples make me want to learn more.
same old template based data binding, just like observable never existed.
Most of the problems with data binding stem from the fact that there is not a prorammable understandable primitive for us to reason about it. Yet time and time again people try to hide such primitive behind some magic templates, hooks, runes and that kind of nonsense
have you heard of RxJS or Mobx? They both can be used in any mainstream front-end framework, though the combination is usually RxJS for Angular and Mobx for React.
I love the idea of this and see great potential. The one blind spot I have is how to scale and DRY the application with shared libraries and outside plugins.
This the same as in standard JavaScript DOM event call. If you want to call a returned function in JS, you can do: <button onclick="getFunction()()">. Similar behaviour in Vue (and Nue)
The onclick="addFruit" calls an instance method between the inner script tags. Similar to how JS would call a global window.addFruit with a similar syntax.
Not sure why but separation of concers was hammered so hard for a while that I cannot accept any inlined javascript or css at all. For me the reason is clear, I do not need to scan the html to know what a particular piece of code is doing and will just assume these ids are somewhere out there.
Are you talking about Svelte- like two-way data bindings? Like here for example: https://svelte.dev/blog/write-less-code — Same works in Vue. MVVM is Not implemented in Nue yet.
When building larger projects you should consider using a MVP (model-view-controller) pattern to separate your view code from the business logic. This way you can keep the view code simple, and the model code out from view-specific abstractions. This is called separation of concerns and is the primary way to build scaleable applications. I'll tackle this topic in detail along with a more complex demo application when Nue MVC project is released: https://nuejs.org/tools/#nue-mvc
Nue will be absolutely fantastic for scaling large applications and teams!
I'm starting to become a fan of your motivation (although count = 0 is still not ES6 classes variables). Good luck scaling it! Are you creating this framework out of your own necessity or just because it can be done? Any medium/large app using it to showcase?
> ES6 classes make your code look amazingly compact and clean. You can add variables, methods, getters, setters, and async methods with the cute and short syntax.
Huh, I didn't know that. I still don't know that :)
As Svelte move away from this, I think it is valid that some framework will pick on it and continue developing this route. It was one of the reasons I ditched Svelte so it won't make me use Nue.js.
Going through the nue the tldr I got is "bring back simple html friendly declarative directives (hello AngularJS)"
Nice to see people trying to push boundaries
Nue might not be a great option for building large scale web apps; it however could be a great way to add reactivity to simple websites. We don't need to have the full fledged webpack monstrosity for every little site.
Nue is a breath of fresh air. Those who are suffering from a prisoner's dilemma under React will obviously say "How can you do this?" You should mostly ignore them. Hope the ecosystem around Nue flourishes. Can't wait to use it.
- It re-renders on click
- It mutates pop/push/... to observe arrays
- Otherwise, you have to manually call `update()`
IMO, don't touch this. All of this has been tried before. It also looks like lists are unkeyed. If you receive another list from the server, you have to do the diffing yourself.
It's disappointing that a framework proclaiming to solve all issues of frontend dev, while evidently understanding none of them, will go uncriticised by HN.