Author here: this is Nue's new, more natural direction. Our previous focus on design engineers and CSS design systems was accurate, but missed the most important point: the web platform itself has evolved to eliminate the need for most framework abstractions. What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page.
This is a long term, ambitious project to strip away these artificial layers and return web development to its core strengths. Instead of fighting web standards, we're taking them to their absolute peak.
Happy to hear your feedback.
Regarding "What began as elegant HTML, CSS, and JavaScript...": I don't know. Did you write websites 15-20 years ago?
What's your reasoning behind the choice of markdown?
To quote yourself -
> What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page
If HTML is so elegant, why isnt nuejs not using it?
---
On the similar line, if you're so much for web standards, why are you recommending the use of Bun which breaks so much of standards in the name of speed?
You seem to have a fundamental misunderstanding of React, Next, etc. They don't stop you from using native CSS or HTML functionality.
Repeating this here for emphasis:
>>the web platform itself has evolved to eliminate the need for most framework abstractions.
> What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page.
Huh? `ls -l | grep '^d' | wc -l`
> 18
You need 18 dependencies to generate a page?
`touch index.html`
If you want to go back to elegant HTML, CSS, and JavaScript, it's right there. You don't need bun and whatever this is to use it.
The absolute peak of using web standards is to just open up either the either the W3C or WHATWG specifications. That's it.
> Closer to metal.
Come on man. Be serious for a second. Have you ever even taken a look at the WebKit or Chromium codebase? Whatever it is that you're doing here is so far removed from "the metal" that I doubt you have ever shipped anything that actually needs a compiler if you're writing stuff like this.
I've also been developing web apps since the days of jQuery and Flash. I think there are some interesting kernels here (in particular, emphasizing how much browsers have evolved), but the post brings up older architectures as better (MVC, separating CSS from HTML) without providing arguments for why those were better at addressing current pain points.
Personally, I hated MVC in frontend code. It works ok for backend apps (though I prefer service-oriented architectures more), but it tended to creating arbitrary separations that provided little value on the frontend.
Similarly, I think the separation of CSS and HTML was an illusion 90% of the time. The CSS is always coupled with the html, and having it spread across multiple files just made design updates more error prone. That provided all of the problems with separation of concerns with none of the benefits. You want to be able to update things like fonts, colors, spacing, etc site-wide in either 1) components (which works great with coupling html & css inside of component files) or 2) logical areas (which works great with css themes and variables). Neither of those are due to the separation of HTML and CSS.
I think there are a couple of interesting ideas here, but I'd need to see clearer arguments about why these patterns were actually better on the frontend (and when they fail) to be convinced in this direction.