Comment by tipiirai
2 days ago
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.
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.
Gotcha. My next argument is going to be visual trough the design systems explained on the article. Hope that's clearer.
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?
HTML for layout, Markdown for content. How else could it be?
The entire nuejs route is built using markdown. https://github.com/nuejs/nue/tree/master/packages/examples/s...
which is totally non-standard. Super common, but non-standard. You compiled the markdown to html using a tool (another non-standard item)
You dont get to claim "standards-first" framework and then use non-standard technology and workflow.
3 replies →
Regarding "What began as elegant HTML, CSS, and JavaScript...": I don't know. Did you write websites 15-20 years ago?
You seem to have a fundamental misunderstanding of React, Next, etc. They don't stop you from using native CSS or HTML functionality.
Not technically, but they sure don't have to make it easy. Getting an element reference is clearly not the optimized-for use case. The docs even warn against it.
> Refs are an escape hatch. Manually manipulating another component’s DOM nodes can make your code fragile.
https://react.dev/learn/manipulating-the-dom-with-refs
Using HTML features doesn't have to mean manipulating another component's nodes.
3 replies →
Repeating this here for emphasis:
>>the web platform itself has evolved to eliminate the need for most framework abstractions.
Yep, I rewrote my OSS Dropbox like frontend for every file transfer protocol in vanilla JS [1], so far it's not only faster with smaller memory footprint, the app is faster to boot, lighter in size despite the optional build system, there is no framework code I don't know about running at the worst possible time and I can effectively run to the maximum of what a browser can do.
It's refreshing to be able to open the network tab and see the original files coming out [2] and the developer console showing the full structure of it untouched in the same way it's visible from github.
This has opened new doors that was previously closed with any kind of framework, the option to dynamically patch those js file at runtime to customise the interface for unique needs that make sense for someone but wouldn't make sense for 99% of everyone else. Now it's just a matter of submitting a small plugin patch that do it and tada, a happy customer while maintaining only a single codebase
[1] https://github.com/mickael-kerjean/filestash
[2] https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3...
Do you think the code can be extended and maintained by someone other than you? How about a large team?
When I look at the contributors, I see abysmal contribution from other people.
https://github.com/mickael-kerjean/filestash/graphs/contribu...
----
What works for one disciplined (and talented) developer such as you might not work at scale.
1 reply →
> 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.
> https://nuejs.org/vision/
> 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.