Show HN: Nue – A React/Vue/Vite/Astro Alternative | Hacker News Reader

Astro Alternative

nuejs.org

370 pointstipiirai275 comments

Author here. I've been working on this for the past ~12 months, lately full-time.

I'm releasing two things today:

1. Nue JS: https://nuejs.org/docs/nuejs/ — A tiny (2.3kb minzipped) JavaScript library for building user interfaces. It's like React/Vue core, but there are no hooks, effects, props, or other unusual abstractions on your way. Know the basics of HTML, CSS, and JavaScript and you are good to go. Nue JS supports server-side rendering (SSR), reactive components, and "isomorphic" combinations. It takes inspiration from Vue 2.0 and Riot.js. (I'm actually the original author of Riot).

2. Nue ecosystem: https://nuejs.org/ecosystem/ — This is the ultimate goal and once all the sub-projects are finished, Nue will be a serious alternative to things like Vite, Next.js, and Astro.

The thing is that I'm not happy with the current state of web development, so I want to write a completely new ecosystem from scratch. I'm taking advantage of the "old" innovations like progressive enhancement, separation of concerns, and semantic web design. Benefits highlighted here: https://nuejs.org/why/

All projects will be released under the MIT license.

Happy to answer any questions.

Open articleView on HN

I think you want the getting started to be the first thing people see on your homepage. Like instead of that thing which is showing you size difference put a snippet to show how easy it is to make a hello world app then a link to click to take them to a TODO style app.

I know some devs do care about bundle size but most f/e devs I've worked with don't really care about that. They care more about their Dev Experience so you should be showing them how it's the same or better with your new tool.

That is true, the first thing i ask myself when i read "Frontend Troublesolver - Nue is a powerful React, Vue, Next.js, Vite, and Astro alternative. It might change the way you develop for the web forever." ... was, how?

And then came a code size comparison, this example is ok, but display it later, show first a simple example in which way it change it, e.g. a small code snippet? How does Nue look?

It looks like Svelte honestly. I'm really trying to figure out how it's all that much different

Agreed, compare 10x less code in not meaningful matrix for most cases with custom code or UI components as we can resue them. I could only think of it as opinionated framework that it has to be your patterns where Astro is unopinionated.

The only comparison with Astro is missing. https://nuejs.org/compare/component.html

As important as a simple „getting started“ is a more complex showcase with modularity, some integrations etc. Many frameworks on FE and BE die on that hill, being easy to start, but hard to scale.

The TODO app is mandatory

I hear you

Here you go: https://nuejs.org/todomvc/

The TODO app points to https://github.com/nuejs/www/blob/master/todomvc/todo-compac...

but the link is broken, it's actually: https://github.com/nuejs/www/blob/master/todomvc/todomvc-com...

I agree, but if Nue is going to mean I have to write 10x less code, then that should definitely be called out.

There are so many JS frameworks, more every day, why should I care about 'yours'?

The examples will show me if this is true or not, and how easy it will be, also important

10x less code is impossible. Either it adds much hidden magic code or it pumps the other language examples, or it lacks on functionality.

Nue is small, so it adds no hidden magic. Some examples are really huge.

10x less code is definitely possible and it's my duty to prove it. I'll add better examples to the website next week.

The 10x less code is false—see my other comment here [0]. The short of it is that Nue implementation uses 10x less code because it has 10x fewer features: no typeahead, no multiselect, no aria support, no customization options. It's an apples-to-oranges comparison that should be removed.

[0] https://news.ycombinator.com/item?id=37517988

Yes, thank you. Scrolled the whole thing looking for the Hello World only to be disappointed

Here's Todo MVC made with Nue js:

https://nuejs.org/todomvc/

Source code:

https://github.com/nuejs/www/blob/master/todomvc/todo-compac...

More details to come

Nue JS examples: https://nuejs.org/docs/nuejs/examples/

Nice project, well done!

However, it is more like an alternative to Petite-Vue or Riot.js rather than full-blown Vue or React. Therefore your comparison vs headlessui-react/vue is like apple vs orange/banana: headless UI listbox is much more complicated than your implementation. You can easily make a listbox in Vue using a similar amount of code as Nue.

One thing which is lacking in your Getting Started (https://nuejs.org/docs/nuejs/getting-started.html) is how to use Nue without a build step, in order to progressively enhance existing HTML websites like Petite Vue: `<script src="//unpkg.com/petite-vue" defer init></script>` or Alpine.js: `<script src="//unpkg.com/alpinejs" defer></script>`?

How is Nue performance compared to other JS frameworks? Could you add it to https://krausest.github.io/js-framework-benchmark/current.ht...?

Thank you!

You are right: Nue takes inspiration from Vue 2.0, petite-vue and Riot.

I'll make the comparison more fair, but it doesn't take out the fact that React/Vue promote use of "spaghetti" code where logic/layout/styling are mixed together making the code hard to read and causes the size to grow. Everywhere I look the projects are unnecessarily big. Very often in the factor of 10x too big.

Pretty sure Nue JS will always need a build step. I don't like the idea to load the compiler and run JS exec() on the client side. Heavy and unsecure.

Haven't checked performance yet. I want to see this project getting more traction before deep diving to benchmarking

I jumped straight to comparison (as it’s listed first) and was let down because the comparison seemed borderline deceiving. The other examples had hundreds of lines of logic and types for example.

Also, it was comparing a headless library with a concrete (and rigid) implementation. You could use the a similar amount of React code to get the same concrete implementation.

Probably not intentionally deceitful, but it a ridiculous comparison.

Having a zero-build-step bundle is a quick & easy way to experiment with a library and add simple interactions to existing static HTML websites, which is a big plus.

However, according to BundleJS, only nuejs-core's compile() method is 36.2KB minified gzipped: https://deno.bundlejs.com/badge?q=nuejs-core@0.1.0&treeshake... - it is nowhere close to 2.3KB as on your website. Compare it to petite-vue's bundle, which is only 7.3KB: https://deno.bundlejs.com/badge?q=petite-vue@0.4.1

petite-vue is about 3x bigger than Nue. here's the script:

https://nuejs.org/@nue/js/nue.js

local gzip on my machine is 2.3kb

Yes, but it's only the Nue runtime which is 2.3KB, the compiler bundle is 36KB. Petite Vue includes everything in 7KB.

Here is what some of it looks like.

``` <div @name="media-object" class="{ type }"> <img src="{ img }"> <aside> <h3>{ title }</h3> <p :if="desc">{ desc }</h3> <slot/> </aside> </div>

<div class="art-gallery"> <media-object :for="item in items" :bind="item"/> </div ```

I really don't like the opinionated, magical/weird syntax (like vue's :@v-for-OnClick="fn()"), I prefer how close and true to vanilla html/js react is, rather than stuff like this.

Yes. Nue is indeed HTML-based and takes inspiration from Vue. It is designed for UX developers who prefer to use HTML/CSS and minimal JavaScript to communicate with the business model layer, that the JS developers are building. That is: separation of concerns.

I can understand that this syntax is not a preference for JavaScript/TypeScript developers who opt to JSX and want to write everything (logic, layout, styling) in JavaScript.

    <p :if="desc">{ desc }</h3>

That </h3> should be a </p>, I think.

Thanks. Fixed

My problem with these :ifs and v-ifs and {#ifs} is I cant place a breakpoint and step through _my_ code with a debugger.

React is far from vanilla HTML. It uses JSX with attributes e.g. `className` or `htmlFor` instead of HTML's `class` or `for`. And JSX requires compiling to HTML rather than being HTML from the beginning.

Both className and htmlFor are native.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...

Woah.

Yes, but it's JS, it isn't vanilla HTML.

It's almost identical to vanilla DOM, though, which does use className and htmlFor.

I'm not sure that the compilation aspect is relevant - pretty much all modern frameworks using a template language have a compilation step. ngFor doesn't exist in the browser after all! ;)

You're confusing the XHTML/HTML and JavaScript API naming schemes

I'd say it's JSX doing that because those attributes are clearly on the declarative/markup side of the divide, not the procedural/imperative dom manipulation side.

To push that point further, I’d say JSX is opinionated, adding magical/weird templatey syntax to Javascript.

React has a lot of opinionated, "magical" boilerplate. useThis, useThat, ... In my experience, Svelte did a much better job and is closer to vanilla html/js, but for some reason it seems to fail to gain significant traction.

I agree -- I don't love Svelte but it feels much closer to just writing plain HTML+JS+CSS than any other fancy JS framework I've tried.

The goals of this project and Svelte seem very similar, so I'd be interested to see a more in-depth comparison.

Hooks are just normal javascript functions though, they're not syntax.

No special syntax but they do have special semantics, as per the "rules of hooks".

"use" is just a convention for hook function names, react doesn't require or enforce it.

It's "just" a convention, but a strongly encouraged one. The React docs say:

Its name should always start with `use` so that you can tell at a glance that the rules of Hooks apply to it.

And it is required and enforced if you use the ESLint react-hooks plugin (which I'm guessing most large projects do).

https://stackoverflow.com/questions/66151248/do-react-hooks-...

> In my experience, Svelte did a much better job and is closer to vanilla html/js

I just looked at some Svelte examples and it's a mix of magic keywords (on, bind) with magic symbols (: | @) and new, completely unrelated syntax to both JS and HTML (#each, #if, :else). I guess it looks way more idiomatic if you have an IDE that highlights and lints it correctly. React with its few rules of hooks seems way closer to vanilla JS.

This is fantastic. As much as the web changes and people complain about "new frameworks" everyday, all the major frameworks are surprisingly similar.

Rethinking things from the ground up and making it smaller and more RAM efficient, is absolutely brilliant.

More frontend devs needs to stop following the herd and think for themselves and look back at how hackers used to work back in the day to use as little memory as possible.

These days I look at apps like Slack and feel such terrible sadness and despair.

Projects like Nue at least have the right spirit and attitude.

This. So glad to see there are still people who care about minimalism! I asked here on HN the other day that "why your login screen loads 6.4MB of resources" and they said that VSCode is ~200MB and gdocs is ~30MB so it's not that bad. That's the spirit these days.

I want to make things very, very differently. Not just because of the size, but maintaining a codebase with 5k lines is so much easier than maintaining 500k lines.

The problem is more in the ecosystem side than the core libraries side. Many front end devs build UIs for a day job and when they’re developing some new product requirement they don’t think twice before pulling in react-widget, react-ui-this, react-router, react-accordian. This is the main issue that creates bundle bloat and maintenance pain down the line.

I don’t know what the solution is there.

Better education or being more informed would help. Knowing the basics well, like HTML and CSS, to already avoid some of the JS. Then knowing a backend language can help with actually considering simply rendering templates on the server using some template engine, like done for decades. Some knowledge about setting up a HTTP server would probably also help. Knowledge would help being able to take a step back when needed and think: "Do I actually need much interactivity here?"

Question is how we get web developers to learn those, instead of the next (ha) hyped JS frontend frameword.

We're competing with $15/hr labor. Businesses are happy to hire developers who deliver 6.4MB login pages quickly, until their customers start to complain.

I'm all about caring and using resources efficiently, and in a sense that's how we get such inefficient tech even though it's not what I mean. Money defines efficiency, and we're getting heavy apps for pretty cheap while lighter apps are more expensive in terms of specialized labor costs.

If engineers with this right attitude collectively work for rates competitive with global head shops and still deliver as quickly then we can have our light weight app cake and eat it too. I'm personally selling my services for $15/hr already, and anyone who hires me will get a pretty well engineered solution with minimal dependencies; who's with me?

Since most frontend jobs these days seem to be about having to use one of the big frameworks, I have withdrawn from frontend work mostly. I do have quite OK JS knowledge and have done things in TypeScript when I needed to. I even did explore React (and NextJS, and VueJS) stuff a bit, but it left me disappointed. I have the skills, but no motivation at all to spend time with that kind of frontend work. Until this changes, I will most likely not engage in any frontend work or "full-stack" development.

Thank for for sticking up for external stylesheets.

When I was starting out with HTML, inline styles were considered to be a hack, and the goal of writing good HTML was to separate the data from the presentation as completely as possible. It seems that nowadays people place more emphasis on encapsulation rather than separation, they want their style to live with the component. Separation and encapsulation are in opposition: vertical vs horizontal architecture of code.

Personally I prefer separation. While components are a good way to divide up functionality, when it comes to presentation users are perceiving the UI of your entire website, not the individual UIs of each component. Separating the style into a stylesheet gives you global control over presentation and makes you more aligned with how the user is perceiving things.

Separation also has drawbacks. You have to go to open a different file and search for things by ID or class name. It’s like aspect oriented programming.

In almost every IDE you can open two files in a split view and you can ctrl-click on an ID to go to the definition.

That's not good enough. I want to look at a tag and immediately see how it's styled. No cascading or hidden/indirect styling. It should be all there, completely isolated from the rest. In fact, I should be able to copy/paste just the HTML (or component) into a completely different application and it should remain exactly the same.

This is a really good observation. If I can add on, I feel like a lot of the disagreements in modern front end development boil down to this: Some people actually like developing with HTML/CSS, and other people see it as an implementation detail and would rather abstract it away with JavaScript.

People in the first camp tend to like Vue, CSS/Sass, Htmx, server rendering, etc.

People in the second camp like React and React Native, CSS-in-JS, Tailwind, etc.

I don't agree with that separation. I feel that e.g. Tailwind appeals a lot to developers of templates for e.g. Laravel.

And I like to be an expert in HTML+CSS (at least I try), and still prefer JSX to e.g. Vue's template syntax.

It's a tradeoff, prototyping speed vs maintenance

prototype (or throwaway code you don't care about)? JS and tailwind something you have to maintain? TS and external stylesheet

Seems legit observation to me

> Separating the style into a stylesheet gives you global control over presentation and makes you more aligned with how the user is perceiving things.

This only works for trivial stuff. Presentation is more than just colors, fonts and margins. Layout is deeply intertwined with the structure your HTML, attempts at mitigating this have made a monumental mess of CSS. The sooner you recognize it as the pipe dream that it is, the more time you will have to work on your actual goal.

I also feel the opposite about what the user perceives. The user perceives the result of applying all your CSS rules - which is closer to inline styles everywhere rather than separating things out.

> Separating the style into a stylesheet gives you global control over presentation and makes you more aligned with how the user is perceiving things.

Can you elaborate on this? Do you mean that the separation through external stylesheets creates a more cohesive UI for the user?

The HTML has its say on layout part, so the presentation is not exclusively on the CSS. Also, the core part of defining the whole UI is usually delegated to some global CSS rules, usually known as the theme in CSS-in-JS libraries. I don't think having external stylesheet helps that much.

First of all, congrats for launching. It takes guts and a whole load of effort, I know that first-hand.

And to make it to HN FP and deal with the ensuing onslaught of comments and feedback is no mean feat! I hope the next few days are insightful and fun and you can maintain a positive outlook about it all.

I haven't looked in great depth yet at what you've made available so please take all of this with a pinch of salt, but I wanted to share my honest 5-minute scan-through braindump with you as if you were watching me do the review in person:

- _Another_ front-end framework (le sigh) - tell me again how you're trying to fix burnout and fatigue 8]

- Let's look at the source for the homepage: https://github.com/nuejs/www/blob/master/index.md

- Oh, this 'Nuemark' actually looks interesting! Is that available yet? No

- Where's the word 'solver' here? It's not here, it's embedded in the CSS. OK :/ not sure if this is intending to be an example of how to do this properly...

- That CSS looks... funky... like a Python developer from 2004 decided to come up with their own terse syntax

- That's not going to play well with current tools. Plus, there MUST be a compilation step, so why choose to make the compiler do a load of work here every time? Saving a few keystrokes feels like very little benefit overall

- The homepage claims that its own HTML, CSS and JS add up to under the "14K" limit (is that kB?) but according to my math (which has been known to be wrong at times) it comes in at 19kB - this is still great, but the content of the page is potentially misleading

I am always open-minded about new tools and will do a thorough and fair review, but a part of the problem for me is the time I invest has to be worth it - like, if I switch, I'm going to use this tool A LOT

As I say, this is just a braindump of a very quick review, so add salt to taste

I hear you. I'll try to convert you ¯\_(ツ)_/¯ in the upcoming months when I address your points with the new tools and code examples.

Hey fellow devs. I'm heading to Finnish forrest to practise disc golf. Will answer to all the critical questions later this evening. I'm so happy this launch went well and I'm super motivated to build a great, minimalistic frontend toolchain that is closer to web standards.

As a non-Suomi guy who ended up living in Finland part-time, I can relate so much. Enjoy the forest!

Svelte is mentioned on the site but not in here. Is it harder to put Nue, or another framework, forward as an alternative to Svelte/SvelteKit? I think SvelteKit is batteries-included while still being fairly small and easy to understand.

Svelte is indeed a bit different to how the internals are implemented and what kind of compilation results are created. However it is a component-based UI framework and they also compare themselves to React a lot. When Nue ecosystem is completed, it can be compared to Nuekit.

Well, I like Svelte, and so far I don't want to write code in Nue, based on the examples. The last I looked on HN there were 67 upvotes and 34 comments. That's less than double the number of upvotes to comments. I think it's being ratioed not because people dislike the attempt at writing a web framework with a different syntax, but because the site and the text claim it's competitive with all these frameworks.

It's me replying to everything in here :)

I think "ratioed" is a pretty weak signal in general, and especially here. At least compared upvotes to commenters, not comments.

ListBox/PopupButton … The React version is 2500 lines of JavaScript

Is this idiomatic? I refused to use React for years, but if this is normal-ish, it basically cements the decision. An implementation of a ListBox in VGA 0xA0000 framebuffer could be only a little bigger (if even bigger). GtkTreeView, which draws a complete tree/table with columns, resizing, dynamic rows and all the interactions, was 10kloc, afair (now 14). GtkCombobox.c is 5kloc, almost half of that is comments or doxygen.

The listbox does a lot like searching, multiselect, is completely accessible and includes a lot of types. It's a really unfair comparison.

Do you mean my comparison to gtk, or on-site comparison to nue?

Even with all those features, 2500 lines sounds like way too much.

He's also included pieces of Headless UI's embedded framework, which they use to minimize the differences between the different implementations. It's definitely not representative of regular code in the frameworks being compared to.

Very promising!

Would it be possible to use your framework with any server of my choice (Python or Node or even PHP), and use Nue only for the frontend?

In this case, since it's just JS + HTML + CSS, can we have an "Option #3" in https://nuejs.org/docs/nuejs/getting-started.html with no command-line, no `npm install`, no `npm run start`, no use of `npm` at all?

It would be nice to have a Hello world example with just a HTM file + import of Nue from your CDN (or from local). Is that possible?

I'd like to totally avoid npm, etc, just write JS + HTML + CSS, and use my own server.

Not possible without buildstep. Use something like alpinejs

+1 for a zero-build-step bundle. As an alternative you can use Petite Vue, which is even smaller.

alpinejs is even better as petite was not actively developed, petite is there after it says alpinejs

Petite Vue is considered "done" in terms of features: https://discord.com/channels/325477692906536972/105043928434...

Node or Bun is required. Not planning to support client-side compilation and running exec() on the browser. I have super vague plans to make a Zig-based compilation to work natively in Bun and runnable from other languages too. But later...

I get why you want to replace vue/react/next/nuxt, but why vite?

Are you really planning to create a new build tool?

Not a build tool, but rather a web application builder with support for multi-page applications (aka. websites) and single-page applications. Vite is (mostly) a SPA application builder so that's why it is mentioned.

Vite can be used for MPA for eg: Astro uses it.

While you may not need it, everyone else may have different needs

Exactly. Nue is an _alternative_

Would you mind sharing some details about how you made this? https://nuejs.org/compare/component.html

It’s very cool. I’m on my phone, but I’d like to investigate more later.

Thanks! It's a custom made script to generate a HTML page with `pre` blocks to render the source code on a file. Then a Nue-based zooming app on top of it. The images on the site are screenshots from this app.

This is done using css columns. The slider controls the font sizes, and the column width is set to 30em, which increases when the font size increases.

Congrats looks great. Can't wait to see the whole vision with Nuekit.

Not a fan of the Vue template syntax but it's not a deal breaker.

I really love that you don't need a bundler.

Thank you! I'm glad this initial launch got some traction so I'm absolutely going to cross the finishing line. The ecosystem code is actually done and the website is made with Nuekit. Need to polish the code, rewrite some pieces, and document everything — which is the time consuming part.

+1 on not requiring a bundler. It makes it so much easier to try out on just 1 or 2 pages when you don’t have to also add a compiler.

Exactly. And bundlers are quite big monsters. Vite, for example is 32MB on disk.

The comparison on the homepage is not even close to fair. They compare a React component from a headless UI library that has a lot of (accessibility) features and full TypeScript typing to a basic version without any typing.

> The amount of code required to build a basic listbox UI component

That is not what is being compared.

The speed graph shows the amount of HTML/CSS/JS on the project home page. Again not even close to a fair comparison, they have completely different content. I can create a sluggish library, with a homepage that is just a plain text link to a GitHub repo and that would rank way higher.

Isn't basic version without any typing being shorter and clearer a fair comparison of JS against TS?

For a fair comparison they should have compared the React JS implementation with Nue.

Not if it does a fraction of the work. The current comparison basically says "look what you can do if you don't have to worry about accessibility or supporting multiple use cases!"

Lots of good looking stuff here generally. The value proposition over Vue/React is obvious, but seems to be about the same as Svelte/SolidJS. Which leads us down to:

> No TypeScript: Nue embraces the dynamic typing in JavaScript

This is an instant nope for me for any serious projects. I'd expect any serious modern competitor to the status quo to be Typescript-first.

I assume you have chosen Vue as your go-to framework due to this reasoning? (React and Svelte are JavaScript)

I do Vue at work, Svelte and Solid JS at home.

Kudos for the emphasis on code size – this is something I always liked about Riot. But the comparison faq currently returns a 404

https://nuejs.org/compare/faq/

Thanks! I fixed the links. Here is the correct one: https://nuejs.org/compare/faq.html

Do you have a RealWorld implementation?

https://codebase.show/projects/realworld

https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

I don't want to poop all over someone else's project (hell, it's hard as hell to do anything like this), but I have to say that this feels like exactly what you said, a React/Vue/etc. alternative. But that is absolutely not what I want and not what I think will do people the most good in the long run.

Another project that largely ignores that custom elements and Shadow DOM are readily available on every modern browser (including the ones on your phone) and instead chooses to "simulate" components instead is... short sighted.

I crave something that attempts to fill in the missing pieces between something like say Angular and Lit. Give me something that treats a Web Component as its underlying tech for components but offers good support for animation. Something that comes with simple support for migrations (Ala Ruby on Rails) but doesn't include a ton of tooling for CSS that is not really needed anymore (I'm looking at you React) or was created before JS Modules and is still not making good use of them (ahem... Angular).

So, if someone is still stuck in React land, maybe this will be what they are looking for, but for someone keen to use what is built into modern browsers for speed and smaller apps, this seems like something we should pass on.

Have you tried Stencil (https://stenciljs.com)?

Not yet, but I may give it a try. The JSX this is as off-putting as a case of leprosy though. The idea that React needed to invent something new that wasn't JavaScript was absolutely terrible.

You don't need to use JSX. Stencil integrates with other frameworks such as Vue or Ember: https://stenciljs.com/docs/overview

Does your SSR support component level network and caching optimization (i.e. streaming in an island architecture configuration)? That is the current state of the art for JavaScript single page app server side rendering.

Congrats on the launch! Looks really interesting. I'm looking through the documentation and am having trouble understanding the slots example:

https://nuejs.org/docs/nuejs/component-basics.html#slots

I'm unable to see the relationship between the <slot /> tag and the looped content in the 2nd code snippet. Can you clarify that in the documentation?

Edit: I think it would have made more sense if you included the @name="media-object" attribute in the first snippet.

It appears to be similar to Vue. The first snippet is the <media-object> component, and the second snippet is using the component. Everything inside the component tag goes into the slot.

I'm from a non-vue audience, so the context would be lost on someone like me.

Can you clarify? Not sure I understand what you mean.

My background is React, and I have no Vue experience at all.

I only figured it out by looking at the previous section's code before slots to see that attribute and noticed that the slots example first snippet was missing the attribute I mentioned that would connect the pieces together

Thank you! The slot syntax is borrowed from Vue. The difference is that there can be only one slot, and not multiple named slots.

I can see that the slots example needs improvement and more detail. I'll make it shine because slot is such an important feature and helps you build reusable code.

I'll work on the docs as a whole, now that I'm getting this valuable feedback from here.

Every slot system I've ever seen eventually implemented multiple named slots. Often after first only supporting one slot, then multiple unnamed slot and then finally the whole shebang.

Why go through that whole progress again with Nue? Or do you foresee some other way of doing highly customizable components?

This looks like it could be interesting, but the code size comparisons seem really disingenuous. The level of engineering and features are not the same - one could easily write a react listbox component with far less code than the example. You also seem to be claiming all jsx is spaghetti, which is a super questionable claim. I'll chalk this up as a 'not for me', but my feedback would be to maybe improve the comparisons to be a bit more fair and to better substantiate the claim that nue's dx is superior.

Thanks. Will fix all that in the upcoming weeks.

I'm claiming that mixing logic, content, layout, and styling is spaghetti.

I'd say it's more like a delicious lasagna, if anything. Good luck! Always nice to see different ways to do things, especially ones that take on very real front-end bloat. I used to check bundlephobia for every package. I'm playing around with LLM's in the browser now so that ship has sailed.

Have you looked at https://mobx-keystone.js.org/ by any chance?

I've been quite enjoying keystone + lit (or react if required) of late and at the very least it feels like solid prior art towards MVC stuff.

Also https://mojojs.org/ for server side.

(I'm not saying "use these" even if I quite enjoy using them myself, but they're my reference points for comparison here)

I'm looking at it right now:

> mobx-keystone is a state container that combines the simplicity and ease of mutable data with the traceability of immutable data and the reactiveness and performance of observable data, all with a fully compatible TypeScript syntax.

I'm too old to understand all this.

While this looks nice, their example listbox in nue vs react/vue seems misleading.

https://nuejs.org/compare/component.html

Even just skimming through, the huge React version includes much more functionality, more accessible (aria attributes are only set on the React version, not on nue).

But its always interesting to see these new projects and approaches pop up.

Feels off to be putting a lot of presentation logic into new .nue files. Maybe I've just grown used to .tsx and Angular's LSP consuming html templates and giving me full intellisense, but I wouldn't trade that for a smaller bundle size. If I really wanted to optimize for bundle size, I'd probably just server side render tsx templates, or whatever built-in templating language my backend language has, eg. Razor for .NET.

Nevertheless, I have to agree with the a lot of the other commenters, I would have loved a concrete example front and center, I have to chip into the chior of people dismissing the initial importance of bundle size. I'm also sure a big application written with this library will be able to balloon once you begin using dependencies not optimized for this library.

Generally speaking it's my experience that a lot of frontend libraries unfortunately tend to crumple once the long tail has been reached.

> a lot of frontend libraries unfortunately tend to crumple once the long tail has been reached

Example please. Which libraries are we talking about?

I'll be honest, my postulate is based on 100% anecdata. But in my experience the least opinionated frameworks, tend to crumble the most. I've heard countless stories about React apps where you'll have to use loads of third party frameworks, where each one has the potential to stop being maintained. In the end I guess this boils down to risk management, some teams might prefer not having a single point of failure with the trade offs that the looser coupling comes with.

In my own experience when encountering old Angular applications, there's been a straight forward migration path to the latest versions, that feature in it self is pure gold in my opinion.

what would be nue-css? i really like unocss currently as its syntax's pretty clean

<div border="1 solid red"> instead of tailwind's <div classname='border-1 border-solid borde-red />

also <div bg-red> too, it supports value-less attributes and one can use a single class name as tag name too, like <bg-red> something </bg-red>

Nue CSS is like SASS, but more minimal and more in line with the current standards. Think CSS variables instead of template variables. It's pretty vocal about semantic CSS and separation of concerns once it's public. The main thing is to give a strong alternative to the current css-in-js movement. Haven't checked Uno CSS in detail, but looks like it's a close companion to Tailwind. Nue is a big step away from tight coupling.

Cool ideas, took a brief look but I’ll need to dig in when I’m at my computer.

On a sidenote, I was startled by the tailwind mention. Am I out of the loop? Is it not just some css classes? Why is it being compared to React? I’ve used tailwind casually a few times and dont remember it increasing my build size very much at all.

Please check the original post. This is a launch of the first item (Nue JS) in a new, uccoming frontend development ecosystem. One part of the ecosystem is a project called "Nue CSS", which aims to bring developers back to more standards based CSS development and it emphasizes that separation of concerns is a good thing (and not a bad thing as TW states).

Looks really interesting, especially the 3-way separation of concerns that include content writers as target users.

I read some of the comments here, then read the linked “Why” page, and realized many comments are missing the point, fixating on less important points. I recommend you make the Why page the front page instead (merging the current front page graphics and video with it).

Move your “Hello World” blurb to the blog instead. It doesn’t really say anything that Why and front pages don’t, and isn’t crucial front page content.

Maybe also include some info on how it works under-the-hood. For example, given the small size I doubt it’s a virtual-dom based. Is it a compiler model like Svelte and Solidjs? Or something else?

This reminds me a little of htmx, in addition to all of the other frameworks mentioned above.

I'm still trying to figure out which JavaScript framework to settle in with for day to day development and I'll give this a spin -- perhaps it'll feel right.

Awesome project, feels very refreshing even for me being a great fan of Vite and Astro.

Just curious, how do you handle the client side reactivity? Does it use something like virtual dom with diffing or do you compile everything like Svelte (or even some other strategy)?

I've been using Astro over the last couple weeks. After reading most of the docs, I don't really see how Nue is really better on any metric aside from a smaller base local development library. For actual client builds, most of my interactive Astro pages have no JavaScript at all (instead using seamless page transitions).

> Tailwind or any other CSS-in-JS system is not the recommended way to implement styling

I see, I'm not the target audience here, I can't see myself going back to the old ways. But I am happy that people who can't get into the wonder world of utility classes also have frameworks with their philosophy in mind from the core, which could provide more modern solutions for their preferred way of styling.

Let's see how this projects evolves overtime, best of luck!

This looks great! Reminds me of crank.js in that it leverages native language features (generators) to greatly simplify interactive html.

Please add a mailing list to the homepage so I can keep up to date with your progress. A blog with smaller updates would be nice also.

Thank you! Good idea. I'll add blog + mailing list. I have a lot on my mind! (lol) Before that you can follow Nue on Github and notifications from there: https://github.com/nuejs

It's really awesome to see this recent counter-revolution of developer tools emphasizing simplicity. Nue gives me the same optimistic, feel-good vibe that htmx and Alpine.js gave me when I first read about them.

Best of luck, wishing the author all the best!

Thank you!! This means a lot actually and gives me motivation to implement everything on the roadmap.

I'm missing the classic example where you click a button to increment a value. In fact, I fail to find any example handling state at all. Any pointers?

The closest I could find was a carousel[1], since clicking on a button will increment/decrement an index. I agree that the classic examples are missing. I would have like a simple counter and a TodoMVC.

[1] https://nuejs.org/docs/nuejs/reactive-components.html

Moi Tero!

At a first glance I like it a lot. With regard to the "Why" section and the FAQ - kudos for the bold claims, that was needed. Typical frontend ecosystem went insane long time ago. Thanks for your effort to bring back the sanity.

This was my favourite complaint of the day. Thank you Kunley!

How does it compare to Svelte?

The syntax is HTML- based, strong preference to separate styling/logic from the UI code, and keep it familiar with UX developers [1] (not JS developers), there is no need for Bundlers like Webpack or Vite, and it's written in more minimalistic fashion. Your app is probably smaller too if it's anything more complex than a TODO- app, because Nue is only 2.3gzipped and the compiled files are very small too.

[1]: https://css-tricks.com/the-great-divide/

When do I reach for this instead of AlpineJS or HTMX? When the team is bigger?

HTMX is for AJAX-driven web apps, rather _hyperscript is closer to Nue. There is also Petite Vue which is similar to Nue and does not require a build step.

I was honestly curious until I hit the listbox comparison. The implementations for competitors look purposefully verbose to make Nue look better. The Svelte one in particular could look substantially similar to Nue, but after adding multiple seemingly useless layers and type definitions on top to get the same effect.

Once I saw that in the Svelte example, I couldn't help but wonder if the same applied to the others as well. It all seemed to me beyond simple marketing puffery and into uncharitable and misleading territory.

And honestly:

    <select name="Cars" size="6" multiple="multiple">  
      <option>Mercedes
      <option>BMW
      <option>Jaguar
      <option>Lamborghini
      <option>Ferrari
      <option>Ford
    </select>

Sometimes you need a custom skin all decked out to the nines, but real talk, most folks just need to use the plain old HTML, apply minimal CSS, and move on to the next task.

I'm realizing that someone is going to hop in and say, "But that's limited to just a line of text per option with no images or real formatting."

And that's true. It's also true that's what most folks actually need in most cases. That said, another fast implementation using more markup is to have either a hidden radio button group (single selection) or bunch of hidden checkboxes (multiple selection) that are referenced by visible label tags for the rendered listbox. Doesn't break accessibility for screen readers and can even work without JS.

Browsers can do so much out of the box without us constantly reinventing the listbox wheel.

The "React ListBox" is actually the code for Tailwind's headlessui. I honestly think the bloat in the React ListBox impl is an example to not use Tailwind's headlessui component and less an argument for why to use Nue.

How does cross-component state work? I'm thinking something like Pinia in the Vue ecosystem. You might've mentioned it on the site but I couldn't find anything about it.

State manager / Router is on the roadmap. Check "Nue MVC" from https://nuejs.org/ecosystem/

Hello Tero! Do you have project example using Nue (however small)?

Hey! You can clone and play with this: https://github.com/nuejs/create-nue — it showcases Nue JS, which is currently the only thing completed from the Nue Ecosystem. The only real Nue project atm is the nuejs.org website.

Noob here, but also a former web dev from the Web 1.0 days, looking to get back into the game.

Like you, I dislike much of the modern web frameworks and all the bloat and unnecessary complexities that come with it. I roughly tuned out of this stuff when JQuery became mainstream and everyone and everything started using it, and I couldn't be bothered to keep up any more, nor did I feel inclined to invest my time in such a bloated framework. I did come back to webdev every now and then for casual projects, but every time I did, the world moved from one fad framework to the other, which made me dislike this messy ecosystem even more.

In particular, one environment/toolset that I really disliked was Node.js. Every time I did anything with Node, it always turned into pulling down a gazillion dependencies, and eventually down the line, that led to stuff breaking because some random dependency of a dependency was no longer compatible a with newer version of node or something. It basically put me off modern webdev for good, to the extent that I web back to using plain ol' php for the backend, and since then I've been exploring using pure HTML5+CSS3 without any Javascript for the frontend, but I've been seeing limitations like not being able to do stuff like real-time form validation etc.

Which brings me to your example:

   # install dependencies   
   npm install

May I enquire why you're using npm here? Exactly what dependences are you pulling down? I thought the whole point of Nue was to avoid bloat like Node.js and dependency hell? Isn't Nue supposed to be a self-contained library/ecosystem?

Can I use Nue without touching any Node stuff at all?

I hear you! I went all-in to jQuery- scene. Even wrote a semi-famous library called "jQuery Tools" (oldies know). Then came React and I wrote Riot to simplify the syntax. Then I sidetracked to a startup world for (too) many years and watched aside how the frontend ecosystem grew to it's current dimensions.

Node uses a single dependency, htmlparser2 [1], in the package.json [2]. The HTML parser is used to traverse the HTML that is written on the Nue files. I quickly _thought_ of writing my own parser, but right now I'm having my eyes staring at Bun's native HTML parsing capabilities. Instead of Node, I'm using Bun to develop everything. I need less dependencies with it, because things like JS minification or .env file parsing are biult in.

Avoiding NPM dependencies is a high priority!

[1]: https://github.com/fb55/htmlparser2

[2]: https://github.com/nuejs/nuejs/blob/master/package.json#L12

[3]: https://github.com/oven-sh/bun/discussions/1522

Sounds like you might be interested in htmx. Lots of client dynamism, easy integration with backends and you don't need to write any JavaScript.

I've been looking at HTMX. It's good for HTML/CSS/UX developers to add dynamic pieces to a multi-page application. However, It's quite different from what Nue attempts to be. Nue is meant for building both dynamic islands and full blown web applications. It's just targeted for UX developers and the JS developers can shift their focus more to the "back of the frontend" [1]. Ultimately Nue is going to be a complete frontend ecosystem and alternative to tools like Vite and Next.

[1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-b...

Yes Nue is different, I'm just saying the poster above coming from the backend world would probably find htmx useful if he still wants to avoid wading into the frontend world again. I don't mean to hijack your thread on Nue which sounds interesting, just trying to provide a helpful suggestion.

There don't seem to be many silver bullets. This is good. I don't think it can be a good alternative in its current form, but it is a good start.

I like more single file component, where markup, logic and style is a single file like Svelte. So a component look as defined and styles can not collide.

With svelte, it is possible to use "anonymous" classes. So in fact you do not use any classes, but svelte add auto-generate names. like...

<div>{content}</div> <style>div { background: red;}</style>

People always misunderstand what is make ReactJS special, if your framework not build UI with just JS/TS, you are not React alternative

It's kind of funny at this point, I hear about Astro and I'm just about to try it out and then this comes along claiming huge speed increases. Web frameworks move so fast it's really worth just sitting out a few rounds of frameworks until you really need to make a move, or else you'll just be in refactor hell.

For what it's worth, Astro is excellent.

I really like the idea of a framework designed from first principles around the idea of islands and progressive enhancement. That said, this feels like a lot of potential misleading marketing.

Firstly, I don't think the comparisons with React/Vue are hugely helpful for Nue. React and Vue do a lot. You're right that most people probably don't need all of that stuff, but it is in the frameworks for a reason - those who need it really do need the complexity.

Some better points of comparison in terms of compile-to-JS frameworks might be Svelte and SolidJS, both of which have some similar goals to this, and specifically focus on producing small, fast code. Alternatively, if you want the "it's just Javascript" approach, Mithril is another great framework oriented around minimising complexity, albeit with a reactivity model more like React's.

I also think the specific code comparisons scattered around the site are similarly unhelpful. For example, you typically use Typescript-based examples for other frameworks, and JS-based examples for your own. This is obviously going to make Nue look smaller, but typically people use Typescript for good reason, and understand the trade-off around code size. More egregiously, many of the comparisons seem very much apples-to-oranges comparisons. For example, the React listbox on the homepage is a part of Headless UI - it meant to be as unopinionated as possible and allow the user of the component to bring their own components, styles, etc. This makes it more complex but more powerful - a trade-off that isn't always worth making, but can be very useful for these sorts of components where 90% of the complexity is getting the UI interactions right. Your example is not headless, I don't think it's even styleable, and while it includes keyboard navigation, the lack of aria tags makes me doubt its accessibility. That doesn't mean it's bad - it looks like the sort of component I'd write as a custom component for a particular project - but it makes the comparison somewhat meaningless. I would imagine any component I wrote in most frameworks I use would be a similar order of magnitude in size.

(In fairness, I've just seen you call both of these points out in your compare FAQ. I disagree with your answers though - a framework's choice to use Typescript internally does not affect the choices of users to write components in Typescript, so "embracing dynamic typing" feels meaningless in this context. Moreover, it's not apples-to-apples if the components themselves are designed with different purposes - a quick React listbox could look a lot simpler if it needed to.)

More practically, I think it would be really helpful if you talked about rendering model more clearly. As a frontend developer, this is one of the first questions I have when looking at a new framework. Is reactivity sound, or am I going to have to spend a week trying to figure out why some variable isn't updating when I think it should be? It looks like the Svelte-style compile-to-DOM-mutations approach, is that right?

I have some other more philosophical quibbles with some of the claims in the documentation and FAQ, but I don't think those are so important. But I do think they you could improve the sales pitch a lot by making the underlying technologies clearer, and by having more useful points of comparison.

As an aside, do you have an entry on the Krausest framework benchmark yet? It may be worth submitting a PR there. Obviously pure framework speed isn't everything, but it's a useful point of comparison to see how one might approach the same problem in different frameworks, particularly a fairly intensive problem.

As someone who wants to use the minimal amount of JavaScript, are there graceful fallbacks for when JavaScript is disabled?

I think you have a typo in your documentation here: https://nuejs.org/docs/nuejs/#html

> <p :if="desc">{ desc }</h3>

should be <p :if="desc">{ desc }</p>

> Copywriters, marketers, and other non-technical people can use a human-friendly Nuemark syntax for content management.

> *and* multi-page

This isn't human-friendly, that would be no markup with some Bold button that converts a word to bold where a simple search for "and multi-page" isn't broken

are there any plans for making the state management exportable? in react state's bound to the component, but in solid-js we can define it outside the component and export it, and components from other files can easily use it :D

export const [counter, setCounter] = createSignal(0)

you can probably look at js proxies

This looks really nice! I think Vue 2 is/was such an underrated framework. The reactivity stuff has a little too much magic (hard to debug) but the way of laying out single file components as just HTML, CSS, and a script is pretty magical.

I loved the original Riot.js for the simplicity and readability of the code it let you write. Excited to see this focus on keeping things simple, small, and performant!

Amazing! How can I deploy to Vercel, any instructions here? I want to use it for the home page of a new programming language ACPUL.

I was an avid user of Riot back in the days and loved the small library. I will take a look at this when I have the time :)

Couldn't you have come up with a better name? It's way too close to vue.js and will cause massive confusion.

I think we can go deeper. Free ideas for grabs:

    cue.js: WebAudioAPI framework based on a React render tree
    hue.js: Colour authoring and manipulation
    sue.js: Framework for terms & conditions with JSX legalese components

We may rue.js the day when another framework follows this pattern.

Do you plan to support this for 5 years or more? Because that's the kind of LTS I need to take this seriously.

Read the source, it's a few hundred lines of code. It's very much possible to treat is as your own app code and "maintain" it.

Kudos to the author, the best thing about this is that the source is concise!!

I disagree that vendoring / forking a 3rd party library is a good idea.

You do not understand how software is written. We do not support third party tools. We expect third party tools to be supported. Otherwise they are of no interest. We have other priority items to focus on.

I plan to develop this as long as there are people using it. If the world changes and a new jQuery comes around, then I have to see how to adapt. But the goal is to stabilize the code and make it production ready. Same for all project on the Ecosystem. By looking at todays traction, I'm highly motivated to continue with this project. I'm working full-time actually because I don't have a day job atm. I like it.

I wonder if this can get any traction, since it lacks the jsx/tsx syntax people love.

Not everybody loves JSX, I avoid it.

I thought the same before, but I realized JSX/TSX makes it much easier to build and refactor apps (especially when working with medium/large teams) since you can use usual JS constructs to build your dom elements and you don't have to learn a frameworks template semantics (loops, conditions, etc.).

You also benefit from all the available js tooling (editor support for refactoring, linting, syntax highlighting, type checking, etc.).

Lastly JSX eliminates the burden of switching between the framework's template syntax and regular JS/TS when refactoring code and moving logic around.

Another day another js framework.

Feels like a welcome relief from a new LLM adjacent thing.

no, the LLM is breaking new grounds everyday. FE frameworks are... doing templating in another syntax? Cool!!!

Trying to run it with bun, couldn't get hot reloading to work.

Mostly what I take away from this is that marketing works on everyone.

Great name - can't tell if this a joke or not but I love it

hey @tipiirai - I'd love to chat with about the project

How does it perform compare to Qwikjs and Vue?

would be great to use bun with this!

Bun is really awesome! I'm using it to develop Nue. It runs the minimalistic code in instant. Everything is sooo fast and pleasant. Test suites finish as soon as I release the Enter key.

Looks neat! Will keep an eye on it.

This looks great! Nice work

Another FE framework (sigh)

https://xkcd.com/927/

Nue does not try to be a new starndard. It tries to bring web developers closer to web standards: HTML, CSS, DOM, and plain JavaScript. New developers today start with React, learn hooks, adopt Tailwind, and writes TypeScript and distance themselves from the basics.

> distance themselves from the basics

It’s almost as if there’s a reason for this.

Classic HTML is pretty good for building static websites, but it sucks for building interactive applications.

I will be using this for my next project. Thank you.

Curious if you are targeting at an extreme performance, your site still need to inline CSS on every page?

If you strive for extreme performance you must inline CSS to get the first viewport fully rendered after the first request has been made. The rest can come progressively.

> Prerequisites

> Install Bun or Node

Goodbye

Obligatory xkcd link about there being 15 solutions to a problem and someone creating a 16th

Your comparison of the various ListBox implementations[0] feels disingenuous. I know Vue best, so I looked at that implementation in detail, and it's got a lot going on that you don't attempt to replicate in your version. A few key features that are missing:

* Search—in the Headless UI version there are several hundred lines dedicated to making typing work for jumping to specific list items.

* Multiselect—Headless UI supports multiple selections, yours does not appear to. Again, this accounts for a large number of extra lines in the Vue implementation.

* Focus management—Headless UI has a lot of code dedicated to smoothing out the focus management. In my testing, your implementation has pretty buggy support for using tab to navigate.

* The Headless UI version dedicates a lot of lines to types, where your Nue implementation is dynamically typed. This may be a feature for you, but in my mind those type declarations are doing important work.

* In general, the Headless UI implementation tries to be flexible for many use cases [1], while yours only needs to support the one demo list.

These kinds of comparisons are most persuasive if you can write all the implementations from the ground up, using idiomatic patterns for each framework and identical feature sets for each implementation. When you do that, it's easy to compare and contrast the frameworks. As it is, it's like comparing a house to a garden shed: yes, you've used fewer lines of code, but it's not obvious to me that that's a feature of Nue and not just a byproduct of a less ambitious component.

[0] https://nuejs.org/compare/component.html

[1] https://headlessui.com/vue/listbox#component-api

It also seems a little disingenuous to suggest tailwindcss requires 800kb to build a webpage

Is there such suggestion? I merely counted the amount of HTML/CSS/JS tailwindcss.com has on their frontpage and put it in a comparison chart. They key take there is that inlining styles to markup and loadinng the utility CSS makes it hard to keep the initial TCP packet below 14kb, which is a limit for extremely fast loading performance.

The nuance you provide here is missing from the site. Your chart says only this (maybe I'm missing your explanation somewhere?):

> Amount of code needed for a rich, interactive web page.

And lists "Tailwind CSS" as 804k.

As a reminder, Tailwind CSS doesn't require or use JS in the browser at all and the majority of tailwind gets removed during build so the vast majority of the code you're attributing to Tailwind CSS is unrelated to the task of using Tailwind to build a rich interactive webpage.

To your point about inlining styles, using Tailwind out of the box I struggle to see how you're forced above 14kb, and if you really had kilobytes of classes in your markup you can switch to composing your own rules with @apply.

I recognize you are making a tool and not trying to do ecosystem wide benchmarks, but still suggesting you need 804kb to use Tailwind still seems disingenuous, or at least misinformed, to me.

I changed the wording to "Amount of HTML/CSS/JS on the project home page" on the front page. Thanks for the heads up.

That makes it a lot more clear, thank you!

It seems to me---and maybe my intuition is wrong---you WILL have more bandwidth usage loading

    <div class="carousel-container xyz-row xyz-row-xs--top xyz-row-xs--nowrap" data-v-72ffe0f0="">
      <div class="doorway-item xyz-col-xs-15 xyz-col-md-5" data-v-72ffe0f0="">
        <div class="doorway-carousel-media-container" ...><a class="link-wrapper link-routable cms-media doorway-carousel-media" data-v-9f4decfa="" data-v-129da109="" data-v-72ffe0f0="" ...>...</a></div>
        <a class="link-wrapper link-routable" ...>...</a>
      </div>
      <div class="doorway-item xyz-col-xs-15 xyz-col-md-5" data-v-72ffe0f0="">
        <div class="doorway-carousel-media-container" ...><a class="link-wrapper link-routable cms-media doorway-carousel-media" data-v-9f4decfa="" data-v-129da109="" data-v-72ffe0f0="" ...>...</a></div>
        <a class="link-wrapper link-routable" ...>...</a>
      </div>
      <div class="doorway-item xyz-col-xs-15 xyz-col-md-5" data-v-72ffe0f0="">
        <div class="doorway-carousel-media-container" ...><a class="link-wrapper link-routable cms-media doorway-carousel-media" data-v-9f4decfa="" data-v-129da109="" data-v-72ffe0f0="" ...>...</a></div>
        <a class="link-wrapper link-routable" ...>...</a>
      </div>
    
      ...
    
      <div class="doorway-item xyz-col-xs-15 xyz-col-md-5" data-v-72ffe0f0="">
        <div class="doorway-carousel-media-container" ...><a class="link-wrapper link-routable cms-media doorway-carousel-media" data-v-9f4decfa="" data-v-129da109="" data-v-72ffe0f0="" ...>...</a></div>
        <a class="link-wrapper link-routable" ...>...</a>
      </div>
    </div>

... vs:

    <div class="carousel">
      <div class="caro-card">
        <a href="product-url">
          <picture>...</picture>
        </a>
      </div>
      <div class="caro-card">
        <a href="product-url">
          <picture>...</picture>
        </a>
      </div>
      <div class="caro-card">
        <a href="product-url">
          <picture>...</picture>
        </a>
      </div>
    
      ...
    
      <div class="caro-card">
        <a href="product-url">
          <picture>...</picture>
        </a>
      </div>
    </div>

Sure, the CSS in the second case will be larger, but that one file gets cached for the remainder of the visit, whereas every asynchronously loaded <div> in the first case is gonna be 3.8 KB. An inventory with 3,176 items will take 12.2 MB to fully load WITHOUT product descriptions e.g. user decides to search empty string and scroll all the way to the bottom. (These numbers are rather exact because I picked a random, well-known, segment-specific shop---not cherry-picked, just the first one I thought of.)

Maybe someone at this large, segment leading company carefully considered that they should have 12 different srcset pictures because "responsive" and "bandwidth", but I doubt it because the URLs violate DRY and have escaped characters in the query part and the URL indicates this brand doesn't host static content on their own server (as in, they've hired someone else and have non-technical employees log in to a CMS and upload/update everything).

More realistically, the company that creates these websites imports a framework that has already considered that 2.3% of users are using Edge, 3.8% are using Safari, 0.4% are using Opera on Mobile, 0.2% are using Kiwi on Mobile, 0.8% have disabled Javascript, etc. and then decide they absolutely MUST have everything display as-desired on all platforms rather than excluding the most unusual or ancient user agents that represent far less than one percent of sales. I mean, who's going to leave if your site loads a little slow (but like all the others)? Who leaves if it loads "not at all"?

I see everyone from blogs to clothing stores slapping in a dozen minimized JS frameworks, fonts, reams of generated CSS, ElasticSearch, jQuery, images scaled or loaded improperly, cookie cutter UI elements and giant rounded corners and then some having the nerve to link to a "How awesome is our site?" survey (aka another nugget of JS) where I feel obliged to reply "Your front page takes 8.5 seconds to load on current stable Firefox, has 30 warnings and an error... How do YOU think you did?"

While I'm no web specialist, it seems you could even have a lightweight front page that has a small or even inline stylesheet while the sitewide CSS is loaded asynchronously (cached) after the front page is presented, so the first thing visitor sees is a quick loading page, the 2 to 4 second load happens in the background, they click a link, BOOM next page loads in its full-featured, one-or-two-human-readable-class-per-element glory with the Sneaky Load Giant CSS as an already-cached dependency.

I've also seen much worse violations than my example: divs within divs 20 deep, 15+ clvrly-abrvd-cls per div, because someone decided it's easier as a dev to have "flex flex-col-reverse lg:flex-row items-center justify-center mt-20 mb-32 md:mb-40" outside of every paragraph (instead of a single, well-defined paragraph class that could even inherit common custom properties) or better yet, <footer class="ou ov ow ox oy oz pa pb pc ab q pd pe c">

(I'm sorry if you see that I called out a snippet of your blog here, but that last example belongs to a Next.JS/TailwindCSS advocate, and it's like he took the ideas of the coinventors of CSS and then went full Second City improv, "yes, AND!")

> whereas every asynchronously loaded <div> in the first case is gonna be 3.8 KB. An inventory with 3,176 items will take 12.2 MB to fully load WITHOUT product descriptions e.g. user decides to search empty string and scroll all the way to the bottom.

If you're asynchronously loading something, why are you loading divs, and not JSON which you then display on the page?

> fter the front page is presented, so the first thing visitor sees is a quick loading page, the 2 to 4 second load happens in the background, they click a link, BOOM next page loads in its full-featured, one-or-two-human-readable-class-per-element glory with the Sneaky Load Giant CSS as an already-cached dependency.

This has nothing to do with Tailwind, css classes, or even JS frameworks.

> outside of every paragraph (instead of a single, well-defined paragraph class that could even inherit common custom properties)

Again, this has nothing to do with Tailwind, and everything to do with:

- CSS sucks at components

- CSS sucks at scoping

- CSS sucks at nesting

- CSS sucks at namespacing

Literally nothing is stopping you from applying a global style even if you use Tailwind. Moreover, the authors of CUBE methodology [1] suggest Tailwind for utility classes [2]

[1] https://cube.fyi

[2] https://buildexcellentwebsit.es

I agree it's unfair at the moment. I'll change the example to be more apples-in-apples. I'm going to write a more detailed comparison articles for each framework. Point taken! Thanks.

Ultimately Nue will come out with a UI library with a high feature parity with Headless UI. I can imagine the current listbox (demo) doubling it's size with all the above features. Definitely not 10x!

> Ultimately Nue will come out with a UI library with a high feature parity with Headless UI.

This will actually be a killer addition. I was actually complaining about this the other day: https://news.ycombinator.com/item?id=37448914#37449926

Nice. Thanks for the encouragement!

In my opinion it’s far worse than this: it’s not just a considerably less ambitious component, it’s a component currently completely unfit for any purpose. Most significantly, it’s inaccessible due to semantic abuse and missing ARIA support (role=listbox, aria-controls, aria-expanded, aria-selected, &c. &c.). Even as a sighted user that doesn’t need to use accessibility tech (AT; screen readers are the best known example), I would hate to encounter a page using this, because it misses valuable functionality like type-ahead. Users that depend on AT will be left high and dry, presented with just a read-only text box and no idea what to do with it.

All up, it’s just like so many others, a bad reimplementation of half of what the browser already provides with <select>. About the only thing it adds to that is support for an image per option, and perhaps some more exotic styling aspects (which you hopefully don’t want anyway).

Mind you, I do find Headless UI generally bloated, mostly just suffering from being overly flexible, and it does end up with a moderate amount of code bloat attributable to the particular frameworks’ designs (though not as much as some I’ve seen), but the comparison is just unreasonable. If they think it’s fair to say “With React: 2.5k lines; with Nue: 200 lines”, then I respond: “With HTML: 0 lines”, and insist that <select> is better than the result of those 200 lines.

There are more problems with it, too, whereas I suppose Headless UI will be a pretty high-quality implementation. Examples of problems I found immediately, without having tried to actually run it, but which I presume Headless UI will be free of: it uses <menu> for the options and wraps each option’s label with <strong>, which are both semantic sins; some of the code sharing with combo boxes leads to obvious minor inefficiency (filtering, which can’t actually happen); Escape detection happens on keyup instead of keydown; clicking outside the listbox popup won’t close it if the target or an ancestor matches .open, which is very plausible, e.g. when within a modal dialog (and because it’s ad hoc, it’s certain to interact badly with things like clicking outside modals—any concept of potentially-nestable modality needs to be managed more than that, in one of a few ways but I’ve already rambled enough); after pressing Escape to close the popup, pressing Tab will reopen it as well as moving to the next focusable.

Hopefully the problems with this will be sorted out, but at present I think it’d be best to just remove the comparison, because it portrays a false picture, and suggests that the listbox is ready for use, whereas I hope that the author would agree it’s not.

Totally agree with "HTML: 0 lines" is the best pick in most, if not all situations. For example the Headless UI radio group component [1], can be implemented with just HTML and CSS — and they made it a huge JS component.

[1]: https://headlessui.com/react/radio-group

I wouldn't just call this disingenuous, I would call it lying. He's claiming that his barely usable, non aria-compliant listbox with a fraction of the functionality, is equivalent to the work of the headless-ui team.

If the reader wonders where these lines were saved, they will only find broad, general statements about (IMO questionable) values. Compare this to some other frameworks, where the changes from the status quo are clear on the landing page:

- Svelte -> compile step, templating, common features included

- Solid -> signals, constructor functions

- Lit -> web-components, fewer features

It is unfortunately common for new frontend solutions to not be as up-front about their trade-offs as I would like. But this takes the cake for most requirements swept under the rug.

> * The Headless UI version dedicates a lot of lines to types, where your Nue implementation is dynamically typed. This may be a feature for you, but in my mind those type declarations are doing important work.

Yeah this is actually a little scary:

https://nuejs.org/compare/faq.html

> No TypeScript: Nue embraces the dynamic typing in JavaScript

I for one have no desire to fight dynamic Javascript spaghetti any more. I personally think Typescript types aren't strong enough! (Too much `as Foo` around.)

Yep, nice landing page but the component comparisons are beyond disingenuous, as should be obvious to anyone who has implemented such a thing before. If you toss out the additional features, types, accessibility, customizability and composability afforded by the use of a UI library, of course you can implement it in < 200 lines -- in any framework.

It's a little bit of a stretch to call this "reactive":

> The component re-renders itself automatically after calling an event handler, but you need to call this manually if there is no clear interaction to be detected.

It is a creative approach to shed reactivity and just re-render after calling an event handler, and in some applications it can even be preferable to manage your own updates. But generally this seems like it will be rough and not enough in practice.

For very simple apps it might just work, but in rich interactive settings, it happens all the time that the whole point of interacting with one component is to affect the content in other components on the page. In those cases it can be a slog with this approach for the developer to have to manually keep track of which components need to be updated and traverse through and call update() in all the right places.

A truly reactive Preact [1] is merely 3 kb of JS.

OTOH the need for really simple bits of interactivity does occur in real life. If the htmx [2] approach does not cu it, a micro-library like this could.

[1]: https://preactjs.com/

[2]: https://htmx.org/

After trying out and reviewing the code of https://shoelace.style/ I began asking the question: Do we still need libraries like Vue? Haven't native web components reached the point where we can let go of the component "polyfills" we've been using?

This crossover is bound to happen, like it happened with jQuery. The question is when.

If history repeats itself, it will never be as nice, like it happened with jQuery.

Or how browsers were supposed to replace Flash with built-in standards.. that never really materialized the dream in practice for web media creators.

The runtime was mostly replaced. The authoring tool is what's missing, IMO.

I don't know how well a truly responsive design can be accomplished with visual tools only, to be fair.

If you don't have to support IE (I'm sure some poor souls on here still have to), my opinions are:

> Do we still need libraries like Vue?

> Haven't native web components reached the point where we can let go of the component "polyfills" we've been using?

Yes

I don’t think the crossover is bound to happen. With Web Components the browsers went all-in on ideas about components that made sense in the early 2010s, but then couldn’t evolve them because they had already standardized. In practice most component libraries don’t use Web Components under the hood (yes, I know Angular does if you tell it to, in practice I’ve never seen anyone use this) and aren’t polyfills. The main framework that worked that way (Polymer) has been out of use for years.

> In practice most component libraries don’t use Web Components under the hood (...)

Look at Shoelace's code. It's just Web Components, coded in Typescript on top of lit.dev. It's about as easy to write as Vue.

> and aren’t polyfills

I know, hence the quotes on my text.

Web Components are still relevant, see e.g. Lit Element, Stencil.

I’ve heard pf Lit Element, I have never seen it used in production. I work for an agency, so I see several new frontends every year, and almost all of them are Angular, React or Vue. I know that these other frameworks exist and what their deals are because I listen to ShopTalkShow and so on, but I don’t think they’re that big in terms of what people are using in the field.

It's an interesting project but the website is full of statements that range from strange to downright false. 1. The comparison to React's ListBox is unfair until you reach feature parity. 2. The "nue levels of speed" makes it look like Nue the tool beats the hell out of the competition but then in small text it says it's a comparison of the project home pages. Why would anyone care about the size of the project home page? 3. The whole section on Tailwind in the FAQ is just false.

>It's like React/Vue core, but there are no hooks, effects, props, or other unusual abstractions on your way

I have almost a decade of React experience and to my ear this sounds very weird (starting from React/Vue put together casually). For me – React is really 7 hooks that provide usual abstractions and nothing more.

EDIT: I just looked through their listbox "code volume" comparison and it seems like a bad joke. Obviously meticulously type-scripting anything and exaggerating the code to the absolute will make it look BIGGER when compared to plain js file crafted to make it as thin as possible. I don't think it can stand a fair comparison though.

For the author @tipiirai here. A fair and functional challenge: what will be Nue solution for making this beautiful triangle?

https://codesandbox.io/s/pedantic-mclaren-nqpjl5?file=/src/A...

As you can see it is 20 lines of code and zero hooks for React. It also takes a finite time to compute a limit > 2^10 without code sandbox complaining.

I wonder how much time Nue needs to render for limit=2^10? 2^100? Then we can compare.

Challenge accepted! Likely 5x less code and 2x faster. I'll keep you posted.

Ha, took me two minutes to make that code sandbox.

Can you tell me at least if it is possible in Nue to create something functional like this and how? Or is it just a bunch of macro with some weird imperatives inside usual XML syntax?

I really want to see 4 lines of code doing the same thing 2x faster :D

I wonder what the rise in AI assistants like Github Copilot will mean for new projects like this?

Will people avoid adopting them because code won't be auto-generated efficiently?

It wouldn't be a barrier for me or many people that read hacker news, but I suspect there is a growing subset of the developer community for who this would be an issue.

Depends on whether Nue becomes relevant. New projects are obviously unknown to AI, but they learn as the world starts adopting them.

That's what I'm a bit afraid of. Will software engineering get "stuck" with just the tools we have right now, because LLMs won't be able to help with anything newer?

If you're thinking, all we have to do is wait for OpenAI to re-scrape the web and re-train GPT on the new material, well... LLMs don't "learn" so much by looking at documentation, as by looking at examples. And a new tool is not going to have a lot of examples out there, simply by virtue of being new.

Also, people are already misusing LLMs to generate blog spam, which regurgitates existing knowledge. Future LLMs will have to train on that as well.

The "Selfish Gene" strikes again.

LLMs don't just regurgitate examples, but the have some internal model of the world and can learn new things. See this example: https://szopa.medium.com/teaching-chatgpt-to-speak-my-sons-i.... A sophisticated enough LLM should be able to read a documentation and learn a language faster than a human programmer, but we're nowhere near that stage yet.

Aside, this is not going to stop people learning and using a language if it provides benefits. Not everyone is on the AI hype train. I personally couldn't care less - I don't trust any current AIs to write correct, bug-free code and so I just avoid them. Then again, I also don't trust most humans to write bug-free code and I tend to avoid them too. Formal verification should be the way forward, and this is why new languages, which can embed proofs, should continue being developed and improved, ignoring the AI hype.

When the AI can write code in formal verification languages, I might consider it.

You are assuming the level of LLMs is static. An alternative future is one where LLMs get so good that they can generalize over new patterns and learn Nue themselves to then help you code in it.

When it becomes easier to have an LLM read website content on the fly, this will hopefully become less of an issue.

I can't believe I have to say this, but there are still developers who don't use AI assistants to program. They write code "manually" by reading documentation and reference material, as our ancestors (mostly) did. They might be a dying breed, but they're out there.

Personally, I'm waiting for the space to settle, and for an offline, self-hosted and OSS version to reach feature parity with the proprietary SaaS offerings. Those might exist already, I'm not evaluating the options frequently, but I'm in no hurry.

On-topic: NueJS looks interesting. I'm very worn out and weary of shiny new JS frameworks, but I like the simplicity here. Will keep an eye on the project and consider it again once it matures, but for now Svelte is my best friend.

I haven’t even considered using AI to “help” me code! Is this really that widespread in dev land? Surely not.

For a long time, you've had dropdowns while typing that list possible matches.

If you introduce a feature where someone writes

    int i=0;

and the IDE goes, "Hey dude, probably writing a loop, should I manage that for you?" and it's C++ 17/20/23 or Rust or Go best practice and looks back a little bit in your code and in its compendium of great project examples to see what the loop logic should/could be...

I would probably let the IDE write the loop header for me. And the string formatting. And modify the function I'm writing to support multithreading. And tell me it looks like I was trying to change each instance of pxX to pxY and graphX to graphY but also forgot to change one rotX to rotY.

Hell, if the IDE could read a PDF datasheet and automatically import addresses and bitfields and assign them to variable names, much of my current career workflow would be automated and I could focus mental effort on more creative work.

No thanks to all of that. Following that train of thought, most programming could be considered a chore. And to me, it's not. I like my tools to get out of my way, and not guess what I'm _trying_ to do, but let me do what I _want_ to do.

Autocomplete is far less intrusive, and doesn't fall into this category. I can quickly refine the results since the scope is greatly reduced, and I don't have to read a large chunk of code to understand whether it does what I want it to do, or whether it introduces subtle bugs I'll have to hunt down later. Besides, we've had code snippets, macros and refactoring tools for decades to help with writing code quickly, so AI tools are not groundbreaking in that sense.

Even once AI tools are absolutely correct in guessing my intention, and write entirely bug-free code, I think I'll still prefer typing code out manually. By that point, AI will be capable of writing complex programs from prose prompts, so that creative work you mention will also be automated away. Yet human programmers will still exist in some form, if nothing for the joy of it. We'll probably value programs written by humans in the same way we value handcrafted tools that are not mass produced today.

There are also developers who are better programmers than AI itself, so for them writing code straight away is much easier than thinking about the natural language prompt needed to generate the same code from a non-deterministic statistic machinery.

After reading the homepage and the docs homepage, I still don't know what it is. What's the key API difference that lets you write only 10% compared to React? What's the "hello world"?

Honest question from a back end developer.

I have been using Java for a good decade now, and it solves all the business problems. Yes, we had an occasional Go/React threat (along JVM-based languages), but I have not seen it coming to a fruition. Java is mature, well supported and understood language that gets regular updates now. Some people don't like it, and that's okay.

What makes JS frameworks so quick to change? Angular, AngularJS, Next, Vue, React, Nue to name the few... What's the urge to reinvent rather than evolve?

> What's the urge to reinvent rather than evolve?

young age of developers (average 25-34 years old.), who usually (not always of course) reinvent the wheel because they don't know the past and don't understand the tradeoffs.

Also, it's a way to get attention in this economy of virtue signaling, nobody gives a sh*t if you write a new C++ library that sends rockets into space, it's C++, it's insecure, you should have used Rust.

It's mostly change for the sake of change. If you're not changing something, you're stuck. We went full circle a couple times already in the last 30 years, because when you keep turning with no sense of direction, you might end up where you came from.

> What makes JS frameworks so quick to change? … What's the urge to reinvent rather than evolve?

There’s a really low barrier to entry for creating and sharing JS packages. Basically, you can just create a free account on npm and run “npm publish” to make a library available globally for free. Updates are just as easy, and using packages is even easier.

It’s this super low-friction of JS development that drives the ecosystem to constantly iterate. And it even allows solo developers - like ^ this one - to publish and share a new framework.

I haven’t tried to publish packages for Java, Go, Python etc… but I would be very surprised if it’s as easy and unrestricted as npm…

Python is that easy as well, but community tends to focus on libraries rather than frameworks. So there's rarely a splashy site other than docs and less need for evangelism.

I don't like everything about this but the website is really good and clear. From the FAQ (https://nuejs.org/compare/faq.html):

How is Nue 10 – 100× smaller? [...] No TypeScript: Nue embraces the dynamic typing in JavaScript

I see the TypeScript backlash is in full swing!

I personally think TypeScript is (mostly) great and is the only thing that makes JS development bearable. But it's always good to see alternatives.

Also removing Typescript doesn't actually make your final build smaller, in fact you need extra code to check your ducks before you quack them, else you have high risk of error.

Typescript is the only reason I (occasionally) do some front-end work. The backlash against static typing in an age where we can have very sophisticated static type systems with dynamic-like DX due to great type inference is really saddening. If we collectively embrace another generation of dynamic languages we will collectively set ourselves back another 10 years

> The best results are gained when UX developers and JavaScript developers work in parallel without blocking each other.

In my experience the best results are gained when they’re the same people. Splitting them up sounds like a recipe for disaster to me.

Are there enough people good at both? You could replace JS developer with Java or Python (which JS dev is closer to), to see the divide more clearly.

Some comments:

1. The page on server side rendering leads to a 404 https://nuejs.org/docs/nuejs/server-side-components.html

2. I hate JS projects that have a separate compile step-- preferring to just use the libraries directly (as a script import). Julia Evans also wrote about this some time ago. Im not sure if your library will work without a compile step? Can I just download a .js file and try it out without jumping thru npm install/build hoops?

Frameworks are winner takes it all in nature. I think react is kind of won the market at this point [1]. New frameworks have to wait for a disruption in the model of delivery. React, angular were insight because of SPA. When a new paradigm happens then a new framework will make sense I think.

[1] https://medium.com/javascript-scene/top-javascript-framework...

Nice to see that the react approach of mixing html and JavaScript in one file is missing. Hurrah!

Please now provide a way avoid the need for npm and we can really start to move away from the dumpster fire that is react + npm.

>Nue CSS

>Bring back the power of cascaded styling

Welp, I'm out.

Yes. Nue is probably not a good pick for people who really like things like React and Tailwind. It's more like going backwards in time when standard HTML, CSS, and vanilla JavaScript was a thing.

Tailwind is maybe good for people that do not want to learn CSS but creates bloat for user to download.

You can use DaisyUI to clean things up

How exactly do you use Tailwind without knowing how to use regular CSS first? Pretty much everyone I known uses Tailwind BECAUSE dealing with CSS is a fucking nightmare, even in component-based frameworks.

I know CSS and have to look always into the Tailwind documentation to find the corresponding settings. As long as you use tailwind 0815 settings everything is ok, but not easier as css (if you know css).

You do know that unused styles get removed and Tailwind gets converted to plain CSS?

Welp, I'm in!

The problem in the past with css was the inconsistent browser implementation, this should be solved since some years.

And now we have native nesting, wich was in old times a reason for use things like sass/scss/... CSS-Variables too, so theming is not a pain in the a.. anymore.

You can use overbloated frameworks, but i did not see a reason anymore for that. Especially when you develop component based. Tailwind on a top level is ok, but not within a component and child items, unnecessary complicated.

There's no VSCode extension. How am I supposed to use this??? :)

>> You can use whatever extension you wish on the component file, but .nue extension is recommended. You can also use .htm to have your editor (and GitHub) automatically color highlight the code and to distinguish them from static .html files

[1] https://nuejs.org/docs/nuejs/component-basics.html

how do you plan to monetize?

New day, new JavaScript framework...what's new? Anyway, I highly recommend Quasar if anyone's looking for something new to use. Been using it for two years now and after 20 years of coding I felt happy using JS. Not that Vue is not good but quasar just has it all and is built on top of Vue.

Thanks for the pointer. Quasar seems more like an UI library. Like Material UI or Chakra. Not directly comparable with Nue JS. It's comparable with the upcoming Nue UI though: https://nuejs.org/ecosystem/

Reply on news.ycombinator.com