Author here. I’ve been working on this for the past ~12 months, lately full-time.
I wasn’t happy with the current state of web development, so I decided to write a completely new ecosystem from scratch. I went back to the “good old days”, and took advantage of innovations like progressive enhancement, separation of concerns, and semantic web design. The result is a powerful alternative to frameworks like Vue, React, and Svelte as well as toolchains like Vite, Next.js, and Astro.
Nue ecosystem is work-in-progress and today I’m releasing the tiny, but powerful core: Nue JS. It’s an extremely small (2.3kb minzipped) JavaScript library for building user interfaces. It’s like React or Vue, but there are no hooks, effects, props, or other unusual abstractions on your way. Know the basics of HTML, CSS, and JavaScript and you can build server-side components and reactive interfaces with ease.
All projects will be released under the MIT license.
Happy to answer any questions.
…..so you remade AngularJS v1? but server side I guess?
Feels like your website needs a front page code snippet with an elevator sales pitch. I wandered around it for 5 minutes and saw barely any actual code.
The Nue JS documentation is mostly here: https://nuejs.org/docs/nuejs/
There is very little correlation with Angular. Much more with Vue 2.0 and Riot.js. The ecosystem is more about website / webapp generation, which is a bigger topic than Angular.
I’ll admit that what annoys me the most about the Javascript Ecosystem isn’t any particular individual tool. It’s that:
Nue doesn’t address proglem #1. Does it address problem #2 enough to warrant violating problem #1?
Note: I’m not being critical of you working on this. Building your own tools is fun I do it all the time. It’s more to inform whether I should be interested in taking a look at it or not.
Is 2 still true? It definitely has been a huge problem historically, but I feel like things have gotten better and I’m not fighting my tools quite as much anymore.
That said, Vue 2 to 3 was a huge PITA with a ton of churn. I had to drop vue-cli and switch to Vite just to get a decent build story as part of the upgrade path. I do feel like people should tell the JS world that ideally the number of times to bump the semver major version is zero, whereas in the JS ecosystem it’s expected that you break compatibility once every year or two for some reason.
#2 relates to project maturity. Nue is definitely not mature and 3 month delay would probably break things (yet to see). React and Vue are obviously more stable.
[Comment removed by author]
Lock files help a lot but you still have problems when Node makes a breaking change in itself unless you lock your Node version too.
nvm or Volta has been used to specify Node versions for every project I’ve either started or joined in at least the last five years. Before that, I saw people lose days battling mysterious build errors only to find they weren’t using the magically correct version of Node. I wish a version manager and integration with the
enginesfield (which really ought be created by default for apps) was built into Node.Go has added that for the most recent version, and it makes a lot of sense to me. It’s sort of odd how it’s been outsourced to random other tools like NVM and whatnot.
[Comment removed by author]
The forward compat issues usually arise around modules with binary deps where the locked version doesn’t build against a newer node version, or more rarely, it doesn’t provide binary versions and the source install doesn’t work on newer versions of Xcode on Mac due to e.g. clang setting more warnings as errors.
[Comment removed by author]
Nue is committed to semver, but as stated above more mature projects have less issues than brand new ones like Nue.
Easy, just focus on the backend and let GPT4 write Vanilla JS frontend code. This method solves #2.
This is true.
Sometimes I wish we can go back to the old days where JS was ran in the browser just to add the interactivity.
But nowadays there are so many JS frameworks that it becomes which one to focus and each framework is trying into solve shortcomings of each other.
For example you take React then NextJS came a long which tried to solve a problem of routing , adding SSR and etc
Why can’t we just settle on one framework that does the job well
I hear you. JavaScript in particular suffers from package fatigue. For the answers:
It’s impossible to address the #1 problem with a new project. This is a chicken-egg problem. Something needs to be done to fix the bloated, complex situation of the frontend developer. It has to be something very different, but not a new project. I don’t really know how to address #1 without starting from scratch.
Not possible to address problem #2 without violating #1. Chicken-egg speaking here as well.
Small note: the backstory says it was written in 2024 (so this project must be from the future 🙃) https://nuejs.org/backstory/
LOL. Fixed. Thanks!
I understood progressive enhancement to be a general strategy of conditionally enabling features for browsers that support them, not a specific resource loading order. But reading up, I see that it’s both.
Progressive enhancement is primarly about “content first” and in this context CSS is more important than JS because it makes the content render visually correct. JS last because it just “spices up” the content. Just like the pyramid figure says on the Wikipedia article. This is a little different in SPA context, where everything is rendered by JS:
Nice to see you still out in the wild writing code and working to solve problems in our ecosystem @tipiirai
Thanks! This warms my heart
This feels very similar to Astro. Static, hybrid SSR, lightweight compliments, fast builds, not having to choose a build tool. At what point does Vite start to feel heavy?
Astro is indeed closest of the bunch, but there are some key differences:
Vite is a pretty heavy. A “Hello World” app created with create-vite-app weights 31MB and it’s designed for projects with hundreds/thousands of components.
When I hear “ecosystem”, I think of it as consisting of more than one vendor, which this doesn’t (yet). From a single vendor I think I’d call it “suite” or similar.
Hmm… good point. I might want to change this
This looks like Svelte + SvelteKit roughly. What’s the large difference? I keep seeing it compared to Vue & React, but those seem quite different. Nue, like Svelte, is focused first on small bits of view code and adding logic or state comes later and optionally.
It’s also mentioned in other comments that state is a separate thing from Nue, but the Why page of the site says Nue is for web apps which are primarily about state, is there something I’m missing?
From what I’m seeing the UI library aspect is a simple templating system, with interactivity + state management via vanilla js?
I can imagine some of the react/svelte users will find this a tough pill to swallow, but in simple cases it is 10x+ easier I’d agree. Even in medium complex components it’ll probably be fine.
I do imagine we might be in a different world today if declarative frameworks & some form of modules in javascript didn’t become mainstream together.
Nue JS is a reactive UI library much similar to React and Vue. The server-side stuff is a “simple templating system” because there is no state/reactivity. It’s one shot render with data.
I see, I was confused by the listbox, it seems like the logic & state is tracked outside of Nue JS.
Is it sometimes easier to do this kind of stuff outside of reactive state? Or was there another reason to do it this way?
The reason to do it this way is related to “separation of concerns”: ie the visual parts are done by Nue JS and the “business logic” is pure JS.
What is the business logic in this case?
I’d guess its the list of options, and which is selected.
From what I’m seeing 60-70% of the code in
menu-functions.jsis DOM wrangling, which to be clear I don’t think that’s bad, but its not pure business logic.Maybe “model” would be a better term here. Everything else but the view code.
I would try this but I’ve committed to only write front-end code in Rust from this point on (for my own projects) and try to never touch js/ts ever again.
I’m also thinking of using something else than JavaScript for the model part and compiling it to wasm, but keep using Nue for the view part. This would make a great example at least later on.