A standards-first web framework
218 comments
·January 16, 2025Kaotique
lelanthran
> Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css.
I've seen my fair share of React code, and the code he is displaying is definitely idiomatic React.
> It could use less grand claims and focus more on what it really does.
Agreed. While I appreciate that a rationale is needed for something like this, I think his presentation of the rationale was far too verbose compared to diving into some code.
Maybe I'm not the target - I would have preferred more code and less pontificating, because I 'noped right out of React and others. What I have as a replacement in standard JS, HTML and CSS is unsatisfying to me.
robertoandred
> the code he is displaying is definitely idiomatic React
It's really not. There's nothing, for example, stopping you from using <dialog> in React. It works perfectly fine and can integrate with any state or event manager if you want it to.
What he's doing is comparing brand-new web features that don't have good support yet with long-standing solutions that were needed years before those web features were a glimmer in anyone's eye.
lelanthran
>> the code he is displaying is definitely idiomatic React
> It's really not.
Of the React projects I've seen (including a ton on github), none of them used the browsers dialog without a React wrapper.
A quick search on google for a React project using `<dialog>` found none. Similar for github.
If you have an example, I'd like to see a link, because I'm skeptical that React projects are using `<dialog>` without wrapping it in React.
turnsout
I think all of their criticism of the current web ecosystem is valid... And I'd rather have someone take a big swing than marginally improve the React ecosystem.
tipiirai
> "JavaScript mixed together" and "Strict separation of concerns" is just comparing apples with oranges
I feel this this comparison reveals how deeply framework thinking has shaped our understanding of web development and how thoroughly we've accepted JavaScript monoliths as normal.
Why have we normalized a world where marketing pages need a JavaScript monolith with mixed content? Why do we consider utility classes more "maintainable" than systematic design? Why must every solution flow through JavaScript when browsers provide these capabilities natively?
I have tremendous troubles explaining these things to engineers, who constantly turn the discussion into technical, low-level details instead of looking at the bigger picture. Any suggestions how I should approach this? Thanks in advance!
ozim
Yeah there is a lot of idealism in the project - problem is reality doesn’t care about your idea of separation of concerns and most likely your web applications will not benefit from it.
What I mean React and other frameworks went with mixing concerns because of reasons that were practical - for example realization that usually one dev implements HTML and JS code in one task, not like article comes up with designers and devs. In reality lots of designers don’t live in agile sprints and the same repositories as devs there is huge impedance mismatch.
spankalee
The "separation of concerns" point is very overblown, IMO. It seems to have become a slogan repeated without considering what the goal is, and just completely dismissing components as another valid way of organizing code.
Components have won for a reason - for any given web-based UI component to work it needs to render HTML, to style that HTML, and logic for rendering and behavior. So HTML, CSS, and JS.
It only makes sense to colocate those things so that they're easier to build, understand, distribute, and use as a unit. Often times they're not even separable as the HTML depends on state and logic, etc.
And the weird thing is that any other UI platform has components that combine rendering, styles, and logic together and no-one bats an eye because it would be very odd and cumbersome to do it any other way, but on the web some people think components are bad. And they tend to provide no realistic mechanism for reuse except to use an external system.
ozim
Separation of concerns is valid if you look at website as a document.
If you look at website as an application components are valid approach.
I don’t need a framework to make documents - I need framework to make web applications that is why components won so I agree.
zeroq
I partially agree.
The "separation of concerns" is often misunderstood, and historically people were treating html, css and js like they were completely separate beings, which is of course a recipe for disaster [0].
However, what I'd like to see is separation between logic and presentation. In React world people used to call them dumb and smart components. Then you can use stuff like storybook to gauge your layout before applying "business logic" to the application. On top of that you have an easy way to test your "smart" components.
[0] like that time when I saw an org that decided to be "cloud agnostic" and people started pushing their own databases and http servers to AWS. :)
ozim
To add on top.
Usually one does not design a page like website but reusable components that will have its own context and content.
Designer might focus on broad scope how stuff fits in a web app.
That pop-up to edit “task” has to behave the same on 20 different views.
Widget showing task details will probably be integrated also in some far removed place.
That is whole different game that this “standards focused framework” is not addressing and that game was addressed by whole bunch of frameworks that this article nags about.
tipiirai
> it could really use a lot more explanation on how it works
How Nue works is _extensively_ documented:
Most of these questions are also addressed in the FAQ:
https://nuejs.org/docs/faq.html
THe Markdown claim is also explained multiple times on this discussion
lolinder
You may have already added this in other locations, but it's worth flagging in each comment that you are the creator. I had a suspicion from your tone, but I had to check your bio to be sure.
And, while on the subject of tone: this is not a very effective way to receive constructive criticism. I had exactly the same reaction as OP, as did apparently a lot of upvoters. Communication is a two-way street, but when a significant number of people misunderstand you or can't find the information that you think you put out there, it would be worth listening to them to figure out what you could do to better communicate.
In the end, most people wouldn't even notice or care if they didn't fully appreciate your project— you are the one who is invested in people appreciating it, so it's up to you to take responsibility for the way in which it's communicated. It's not useful to blame other people for failing to understand your docs.
internetter
You could deploy HTMX on top of any static site generator and get literally the exact same experience? Your portrayal of any of this as 'novel' just comes across as naive. The technology already exists, I agree its underutilized, but this could have been an advocacy post instead of reinventing wheels that are already quite well made.
tipiirai
HTMX is more like "jQuery on steroids", but Nue is a frontend development framework with universal HMR support. Think Next.js but slimmer. Different tools for different needs.
spankalee
I help maintain Lit[1], which I consider a very standards-first non-framework.
With Lit you can build full apps with standard and plain JS, CSS, and HTML; standard web components; and no build tools.
I don't immediately see how this is any more standards-first, especially when it mentions Markdown, tooling, and a CLI. I don't actually really see what exactly this even is from this landing page. It would help to show something up front.
[1]: https://lit.dev
jeswin
Lit is amazing. But I don't like template strings for HTML. The IDE doesn't understand it automatically, and lit jsx had a bunch of issues last time I tried to use it.
In my view, JSX will be the true legacy of React. Applications are code. Many frameworks (such as htmx) extend HTML to bring a bit of programmability into it; but I felt they were just framework-specific, non-standard rules to learn. JSX is more standardized, and isn't as framework dependent.
Shameless plug: Magic Loop [1], a Lit alternative (that nobody knows about) which uses WebJSX [2] underneath.
spankalee
We're in a thread talking about "standards first" things, and JSX just isn't a standard part of the web platform, nor is it in anyway standard within the ecosystem of JSX.
JSX has no semantics, only syntax. What a JSX expression means changes depending on the transform you use and the framework you use with it. Some JSX transforms produce values, some produce side-effects. Values produced with JSX under different transforms have different types and are not compatible with each other.
Maybe one day some form of JSX will be standardized, but until then tagged template literals work great with no tools and their behavior is fully determined by the template tag that you use, not an external transform. They're also more expressive than JSX (In Lit we support explicit attribute, property and event bindings rather than overload a single namespace for all 3).
Support for syntax highlighting, type-checking, and intellisense are available to IDEs via plugins and LSPs.
8n4vidtmkvmk
I don't really know what any given tagged template literal is going to do with its content either. It can also produce a value or run side-effects. The only difference is that the parser now has to be inside the browser, and that has a runtime cost instead.
> In Lit we support explicit attribute, property and event bindings rather than overload a single namespace for all 3
I'd like to know more about this. I don't know what that even means.
tipiirai
I think the true legacy of React will be normalizing tight coupling, especially when combined with Tailwind. An entire generation of developers learned to bundle everything into JavaScript - content, styling, behavior, and state all living in the same files. Nue aims to reverse this mindset by showing how proper separation enables more sophisticated systems, particularly once our design systems arrive and you can see the difference. Now it's just words.
jeswin
> React will be normalizing tight coupling, especially when combined with Tailwind.
You're skipping the history of why it came to be.
When I started writing HTML, you needed excellently structured CSS because there were no components. So you needed .sidebar, .topbar, .button.ok etc. This was extremely hard to get right. We cannot see the future, and we cannot know what an application will become - figuring out a globally scoped css hierarchy was difficult even for very experienced developers.
Post 2010 (with frameworks like Backbone.js and Angular), people started splitting apps into components. This meant that the smallest unit of reusable design could be a component, instead of CSS classes and JS functions. Adoption of self-contained styling in components increased gradually after Bootstrap brought in utility classes, CSS-in-JS picked up, and Tailwind made it easier.
It made total sense of course, because the component is what you want to re-use. To address your point directly, tight coupling within a component is ok - maybe even a good thing. We did not get there without trying other ideas, we tried them for twenty years.
potsandpans
This comment is representative of something like a mass psychogenic illness prevalent in the hacker news community.
Which could be roughly summarized as: an absurd and distorted perception of application development for the web, the goals people in that domain are trying to achieve and the history of how we got here.
The real true legacy of react will be bringing functional reactive programming to the masses. Packaging it in a way that a common junior dev could build an intuition around.
skrebbel
Fwiw there's a great VS Code extension for lit-html which (for me) fully solves the IDE support issue. https://marketplace.visualstudio.com/items?itemName=runem.li...
Obviously that doesn't solve it for other IDEs, but back when TS and JSX and ES6 were new they had bad IDE support too.
WA
Cool, webjsx might be exactly what I was looking for. A simple thing that lets me map state to the DOM to make reactivity easier.
chris_pie
Magic Loop looks very similar to Crank (that nobody knows about either). Was it an inspiration?
jeswin
I had this 2017 project called Sailboat [1], which was almost the same thing but for React. I am aware of Crank though, and it's quite nice.
[1]: https://medium.com/@jeswin/sailboat-a-modern-router-for-reac...
skrebbel
I just want to do a drive by comment to compliment you and the rest of the Lit team on Lit. I love how using a TS compiler is optional, I'm impressed by how fast and pragmatic lit-html is, and how easy it is to understand how it can be fast (vs, say, React's virtual DOM). Lit has a Redis-like quality of simplicity to it, like good Italian food and very much unlike eg React or Vue. I could study the architecture for an hour and feel like I completely grokked how it worked and why.
I can't say I completely love the OO aspect of it (notably the amount of boilerplate it requires to define props), and personally I think Lit would've been more powerful if it were optional for LitElements to be Web Components (having a million nested shadow DOMs by default is, well.. let's say it makes some common pragmatisms like global CSS overrides needlessly hard. also a single global namespace for tag names gets messy fast, and so on). But given the goals you set yourself, Lit is absolutely amazing. Small, fast, easy. Hats off!
spankalee
Thanks so much for the kind words! It means a lot :)
tipiirai
Lit has indeed done important work in standards-first development through web components.
But the issue is that Lit still approaches web development through the lens of components. While these components may be "standard" web components that encourages developers to keep bundling markup, styles, and behavior together rather than maintaining proper separation of concerns.
Nue takes a different approach by removing all the unnecessary layers between the developer and web standards. Where Next.js forces content into JavaScript components and requires complex build pipelines, Nue provides a more direct development experience built directly on HTML (layout), Markdown (content), vanilla CSS, and vanilla JavaScript.
With Nue HMR completes in milliseconds rather than seconds. The HMR spans css, content, data, and HTML-based server and client-compnents. CSS updates instantly through the native cascade instead of rebuilding components. The entire development feedback loop stays under 100ms, maintaining perfect flow while preserving document state.
Most importantly, this sort of standards-first architecture enables true systematic design trough vanilla CSS. Instead of coupling design decisions to components through utility classes or CSS-in-JS, with Nue you can build design systems directly with CSS variables, calc() and other modern goodies.
spankalee
> But the issue is that Lit still approaches web development through the lens of components
Why is this a problem? Reuse is incredibly important for building almost anything on the web, and it's been with us since long before the web platform supported it natively, e.g. with CGI scripts that used Perl functions, to output repeated HTML "components", or PHP, web frameworks, etc.
If you don't have some method of reuse in the platform or framework, developers either have to copy-and-paste (and deal with so many difficulties of updating and maintaining consistency that it's not a realistic option), or push reuse to a non-standard layer of the system like server templating.
Server templating is fine, but it doesn't actually get rid of the implicit concept of components that'll be in the page or app, it just disaggregates it among to non-colocated parts of the system.
tipiirai
The issue is the coupling of HTML and CSS into your JavaScript code, which is a step away from the standards first development model.
imtringued
I was thinking of stencil, but lit is also an option, when I read the title. Meanwhile the creator of nue is apparently working on a static site generator based on markdown?
bitpush
Lots of big claims, including bashing React and this seems to be a framework to build static sites, like blog posts with little to no reactivity?
Also, kinda silly to "appeal to authority" by invoking Dieter Rams. I understand that the author was inspired by Rams work, but this is akin to saying "My new framework is Iron Maiden" because I happen to really like maiden.
davedx
Bashing react today is like bashing Java in ~2010.
There are some valid criticisms of react but a lot of them want to throw the baby out with the bathwater, much like with many other mature technologies.
I celebrate people who can produce something innovative in the web development world, but at least produce something before making these grand claims while bashing what came before. Those abstractions are there for good reasons!
robertoandred
And a lot of that bashing comes from people who don't understand React or the ecosystem it's part of.
recursive
Personally, I only started bashing it in earnest after reading most of its source code.
actionfromafar
More like bashing Enterprise Java Beans?
mind-blight
That feels more like bashing Redux or one of the state management libraries. That's where I've seen a lot of complexity sneak in.
palmfacehn
Maybe the Spring ecosystem.
palmfacehn
The only similarity is that it is/was popular to bash both. The reasons for bashing and utility of each are vastly different.
bitpush
(replying to self)
I just checked out the demo site, and now I'm question their design choices as well.
https://simple-blog.nuejs.org/
Nue claims to be minimalist and an outright rejection of everything that is bloated. And yet, this simple page has an obnoxious blur. I get that it kinda looks nice on first load, but click around - the blur happens on each navigation.
This screams form over function if anything.
bitpush
(replying to self)
I looked at the code, and I'm finding it very hard to take them seriously.
https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...
This almost feels like someone taking on a challenge to create a toy framework themselves.
--
While we're at it, since the author wanted to poo-poo tailwind. Com'on https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...
tipiirai
Check out the Development Philosophy section on our contribution guidelines to understand the difference on Nue's coding style:
https://github.com/nuejs/nue/blob/master/CONTRIBUTING.md#dev...
NOTE: the document was just updated to match this concern
mind-blight
Yeah, I was expecting something bigger and more explicit when he went after tailwind. Instead, the author just re-hashed older design patterns (MVC and semantic html decorations from css) without providing context add to when and why you would prefer the older patterns over newer ones. I've been building since the jQuery days, and I totally agree that there are a lot of challenges that people tend to forget from that time. Decoupling html from css just didn't provide much value, but it did create a lot of bike shedding.
I really like how htmx has handled explaining their architectural trade offs. They're very clear about the kind of problem they're solving, how they're solving it, and when/why their solution is better.
This post just has "get off my lawn" vibes without a ton of substance
mixmastamyk
Please dial back the attacks. This is not an interrogation scene in a crime drama.
devalexwells
I believe the "obnoxious blur" is a common view transition API animation [1]. Astro uses similar as a default [2].
1. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
2. https://docs.astro.build/en/guides/view-transitions/#built-i...
__jonas
Astro uses a crossfade as the default view transition, as is described in the docs you linked, it doesn't use any blur.
I haven't seen `filter: blur` used for view transitions before, wouldn't personally call it obnoxious, but to each their own.
I think as long as prefers-reduced-motion is respected, its' fair game.
shiomiru
And it hijacks my back button. It took two clicks to get back to HN. (Fennec/Android)
tipiirai
This blog is for introducing people to Nue's development model rather than a guide to minimalistic design. See
Gualdrapo
I like the blur, actually. Well, not that much - it's too much blur.
But I definitely don't like that on top of the blur effect there are scaling animations for each element. I shouldn't be saying this as I'm guilty myself of doing silly things for page transitions in my portfolio, but am working on that.
layoric
It's a nice change to see extremely clean html when viewing source though I must admit
fenomas
Agreed - I read the whole thing and I'm not sure what this even is. I guess an SSG and with a design system? If so, all the React bashing comes off like "airplanes are too complicated these days, check out this bicycle".
Edit: after checking the code samples, this looks a lot like svelte (pre-runes). So, single file components with templating with reactivity. I didn't get that at all from TFA..
tipiirai
Nue is currently mostly just for static sites, but as the article states the development is building towards single-page applications too, keeping the idea of separation of concerns at core.
For reactivity, Nue's client-side library provides the same capabilities as React (components, loops, state updates) in just 2.5kb through HTML-based syntax. But crucially, this interactivity is added to semantic content rather than replacing it.
The critique of React is best explained in this document:
Coupling content, styling and behavior into JavaScript components can easily turn into hard-to-read code that compounds over time. Nue proves you can build more sophisticated interfaces through web standards while keeping codebases lean and maintainable.
tipiirai
I think this Iron Maiden argument is best explained on the article, specifically on the section about the design engineering problem.
bilekas
Am I just getting more grumpy in my old age or is every new framework just complete bloat ?
I wanted to give it a try, but I need to install bun, a new js runtime, okay fine, why not. Javascript needs more runtimes after all.
Then I need to install `nuekit`.. globally.. Okay...
Now I need to run an obscure command 'nue; which I didn't know I installed. `nue create simple-blog`
Then it tells me to follow the tutorial docs, great. But I need to start writing YAML.. Losing patience now.
My relief comes when I see :
> Nue is not currently tested or developed under Windows, so use it at your own risk.
Well I guess as a Windows user I can't have a 'Standards First Web Framework'.
Think I'll stick to what actually works instead.
ezfe
I had you until the last line.
Windows causes so many problems for me in a full stack development role because people come in and have trouble installing things, etc. and nothing works properly.
I'm not surprised this app doesn't support Windows, I certainly wouldn't bother putting that time in myself. You can have a cross-env but everything else should just work or it's not my problem.
WorldMaker
Node, Deno, and Bun are all great on Windows and all work the same way on Windows they do anywhere else.
Python is tiny bit more challenging to install. .NET is lot less challenging for the most part but has a few Windows install "quirks" now due to the frozen version bundled with Windows. Both are generally great on Windows once properly installed.
Plenty of developers do full stack development on Windows. It's often extra work to break Windows development than to support it.
(Also yes, Ruby is terrible on Windows, Swift is getting better, try to use task runners that aren't (Ba)sh scripts.)
andrewmcwatters
It's fundamentally extra work to support Windows when the rest of us are writing software for POSIX environments. Whatever extra work you think it takes to break Windows development is because others before already ported first POSIX-supported work to Windows.
Node, Deno, and Bun, and all their contemporaries in other programming language ecosystems are targeting POSIX first, and then often times forcing those same APIs to behave the same way on Windows.
That's why. Most full stack web developers are not doing things in a Windows environment.
ezfe
Yeah, hopefully it works fine. But my point is that Windows is the outlier and if it's not working I'm not gonna put in the time to fix it.
andrewmcwatters
My big fat stink test is if I need tooling at all.
Do I need npm or another utility? It probably stinks. Do I need to build something? It definitely stinks.
# Create a website
nue create simple-blog
adamrezich
Everyone wants to recapture that mid-00s Rails energy.
mossTechnician
I think this is completely valid. From the title ("standards-first") I'd assume it would stuck to minimal third-party addons and use standards-compliant JavaScript as much as possible. Why not JavaScript for configuration, for example?
As a side note, and not to excuse lack of Windows support, but: I've switched to WSL (Linux) for development on Windows. Coupled with Visual Studio Code, the results are much faster than when I used the Windows terminal directly.
smt88
> Well I guess as a Windows user I can't have a 'Standards First Web Framework'.
Windows has had a Linux subsystem for years. This should not be an obstacle for you anymore.
tipiirai
I think this is more of a cultural issue. We've accepted that Next.js 330MB solution with 250+ dependencies is solid, but anything new (despite being smaller, simpler, faster etc..) is "framework bloat". The old, "boring" technology is better even if the alternative is web standard.
null
tipiirai
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.
mind-blight
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.
tipiirai
Gotcha. My next argument is going to be visual trough the design systems explained on the article. Hope that's clearer.
bitpush
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?
tipiirai
HTML for layout, Markdown for content. How else could it be?
bitpush
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.
buster
Regarding "What began as elegant HTML, CSS, and JavaScript...": I don't know. Did you write websites 15-20 years ago?
robertoandred
You seem to have a fundamental misunderstanding of React, Next, etc. They don't stop you from using native CSS or HTML functionality.
recursive
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.
robertoandred
Using HTML features doesn't have to mean manipulating another component's nodes.
assimpleaspossi
Repeating this here for emphasis:
>>the web platform itself has evolved to eliminate the need for most framework abstractions.
mickael-kerjean
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...
bitpush
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.
andrewmcwatters
> 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.
zeroq
A little tangent:
I've been doing "web dev" since 1999.
Say what you want about Flash, but most of us cared a lot about usability - small details like keyboard navigation (escape key closing modals, arrow keys for navigating galleries, automatic focus on input fields on login pages, manually crafting tab order to ensure you cycle through relevant parts, etc.). All these things seem to have been lost to time.
On top of that, I'm really frustrated by the fact that the community, in general, constantly tries to teach me how to code in ECMAScript—something I've been doing for 25 years now. Just a tiny example: throughout 15 years of programming in ActionScript, I can count on one hand the number of times I intentionally had to use "===". Today using a simple comparison ("==") is treated as cardinal sin.
Not to mention that we've done full circle with stuff like React reinventing MXML, TS reinventing AS3, asmjs. Anyone remembers redtamarin? NodeJS but with AS? :)
It's easy to be grumpy about all these things.
flashgordon
I think this sounds exciting. As a backend eng (who prefers Htmx) and someone who totally struggles with css, reading your intro made me walk away feeling dumber than before. Again not expecting an ego boost or anything. Something that felt counter intuitive:
1. Lack of drawings hurt - I had no idea what zaha or rams meant. You had bold text which I thought were links but alas they were just bold text.
2. I actually appreciate math and still wasnt sure how I could use math in the new proposed framework (id kill for a constraint system that was similar to what iOS had).
3. +1 on the crazy level of complexity in today's frameworks (which is why I hate using nextjs etc) but perhaps some code samples (even if proof of concept would have helped) would have been helpful.
bitpush
It is 100% true that modern frontend javascript development is hard. You take your eye off the ball for 6 months, and you lose what's going on. I can understand why casual folks find it difficult to get started.
For instance, a year back everybody was using pnpm. But now you use pnpm thru corepack.
----
I can understand why people yearn for simpler days, but the reality is frontend developement is super-duper nice, even with all the warts. Anyone who is romanticizing the "good old days of jQuery" is being non-serious or has not lived through the pains of that.
---
You cant write a spotify.com or a amazon.com with jQuery and have 100s of engineers collaborate and maintain.
And neither can you with nuejs.
cardanome
> You cant write a spotify.com or a amazon.com with jQuery and have 100s of engineers collaborate and maintain.
True but you can write a Spotify or Amazon that ten developers maintain.
We have a huge problems with cargo culting what big tech monopolists use when small teams have fundamentally different needs and would be more productive with smaller tools with less overhead. Though of course the fancy stuff looks better on a resume so can't really blame the devs.
flashgordon
True - As a FE noob I am definitely not asking for the olden days. I do lament often CSS just does not feel intuitive for me and it could be just being used to iOS layouts or more old school layouts (think Swing, Android etc). What made it worse for me was the 18 generations of css philosophies (use classes, use css files, inline, dont inline, and repeat). I wasnt sure if Nue was promising this - but if I can go to one way of doing CSS that lasts more than 2-3 years Id be happy :). Same with frameworks. I can pickup iOS development after not having done it for almost 10 years. I just dont have this confidence with webdev. Heck I moved out of Nextjs to htmx (though I liked the ergonomics in the former and this is not an endorsement of htmx) was because an app I had left in maintenance mode for 6 months started breaking builds out of no where when I had to add a small feature.
bilekas
> You cant write a spotify.com or a amazon.com with jQuery and have 100s of engineers collaborate and maintain.
Honestly how many people are writing massive front-ends like these ?
I would argue the number of people using overkill framework for their needs is actually greatly increasing tech debt and slowing things down.
smrtinsert
It's my understanding you can't do it with any one fe framework really as they work with mfes so it sort means yes you can with jquery
Vampiero
I guess it doesn't take much to entertain frontend devs, but I'd lose my shit if I had to relearn a new shape for the wheel every 6 months. A Sisyphean existence: one must imagine the webshit happy.
And consider that amazon.com was launched in '95, so yeah, you don't need the latest JS framework to build an empire.
The truth is that 90% of tech is about chasing trends that the people who succeeded have set. It's not because the core ideas have merit or are successful. It's because Facebook did it, so we have to do it too (even though we operate at 1/10000th of the scale). No further reasoning needed, everything else is driven by the hype.
Don't believe me? Just look at the state of LLMs. They're solutions looking for problems and the entire world is eager to waste billions in the process of figuring out that LLMs are not good at factual reasoning.
tipiirai
I can answer these questions very clearly once the design systems are released. Now they are just listed with plain text to give you an idea what's coming.
flashgordon
Hey sorry for the noob question. I wasnt actually sure what you meant by design systems - Is there actually a level of "understanding/expertise" one needs to have to just "get" it? For context even though I am not an FE eng, I have built apps and sites (using nextjs, tailwind, bootstrap, vanilla html, css, jquery, htmx - not all of them together). Again I am not an expert in CSS (i really suck at it) but il put together something that works.
So back to design systems, googling it I found - https://designsystemsrepo.com/design-systems-recent.
At a high level this looks like a set of templates and themes (but I think you were alluding to something more than just this?)
naasking
From: https://nuejs.org/docs/
> Utility frameworks like Tailwind are not design systems - they're just inline styles with better ergonomics. True design systems express visual harmony through mathematical relationships.
Yes, Tailwind is inline styling with much better ergonomics. Why is that not enough?
Yes, you may not end up with a coherent, harmonious design governed by mathematical relationships, but that's not an argument that the resulting product is not perfectly fine, nor is it an argument that your productivity is higher if you spend a bunch of time to learn how to define "visual harmony through mathematical relationships" as expressed in CSS, then go through the process of designing such a system that's suitable for your app before you even start building your components. The fact that you are typically developing your UI in concert with other features of your program is exactly why front-loading this design system effort probably results in wasted work as you rapidly iterate and evolve both. I think this is why Tailwind has become so popular, because it requires almost no front-loaded effort, and so iteration is rapid.
If you're not already persuaded by puritanical aesthetics around this stuff, then justifying this sort of front-loaded effort will probably be difficult. If it does turn out to be difficult, that probably means this approach will have a smaller niche than perhaps you're hoping for. Best of luck!
diggan
You seem to mostly be arguing for a "~fine, but at least it was fast to develop" outcome, which is certainly one choice. But doing this sort of upfront work is for when you're not just looking for ~fine but something more. That's why sometimes you have to "waste work" to find better ways, even if it takes longer time. R&D basically, but for design.
But there is a time and place for it for sure, not every project is about coming up/producing something "perfect no matter the time/energy". Similarly, not every project is about "getting something OK out there as long as you get there fast".
naasking
R&D is supposed to produce something of value. If you agree that iterating rapidly using something like Tailwind can get you ~80% of the way towards some ideal design, do you think that last 20% is worth the upfront cost? I think there are very, very few cases where this will be true, and even for those cases, you can get first to market using the rapid iterated design and then refine it more towards the "ideal" before the upfront design approach even gets out the door.
Nue's approach to styling sounds nice in theory, but it seems like it's only a good fit for a domain you already know well, where the structure of the solution is already well understood and so the upfront design cost is actually minimal. For instance, the example project is a blog, a thing that's been around for like 20 years and whose structure, components and features are already well understood. I just don't think that's very common, but if I'm wrong I would certainly like to someone tackle a project that they don't understand using this approach.
grey-area
Yes, Tailwind is inline styling with much better ergonomics. Why is that not enough?
Ideally something better would replace React, sounds like that is their ambition from their home page, not replacing Tailwind.
I think the question they want to ask is: Is React too much?
naasking
I think their goals are to replace both because they clearly don't like atomic CSS either. I have no comment on the React part as I don't use it, but atomic CSS is very useful.
colonelspace
> Dieter Rams is the man behind Apple's design philosophy.
Rams and his work at Braun may have inspired Apple's products via Jony Ives, but Rams never worked on an Apple product (as far as I'm aware).
It's a bit like claiming "Thomas Edison is the man behind Tesla's motor technology".
tipiirai
Jony Ive specifically has said he looks up to Dieter Rams and his philosophy
colonelspace
Yep, as I mention above
tipiirai
Cool. So the original claim is firm:
> Dieter Rams is the man behind Apple's design philosophy.
(no need for him to work there to impact Ive's stance on design)
jkrems
> The gap between design and engineering has never been wider.
This seems like such a weird claim to make. This used to be "here's a JPEG, you may beg for the PSD". Not saying that there's no gap today but... never been wider..? Am I missing something about the typical Figma setup that makes it worse than a random JPEG export of one state of the UI?
tipiirai
This is about the gap between Figma and React/Tailwind/CSS-in-JS, which is wider than Figma -> CSS
Etheryte
I think the docs [0] are a good way of evaluating the article's high horse claims, and as far as I looked around, I'm not seeing anything new nor interesting. The author seems to be more or less just reimplementing Vue from scratch. This makes the whole condescending tone funny, if not sad.
k__
I only know Vue as "like Svelte, but without compiler goodies".
So to me a "Vue but built 100% on web standards" at least has a unique selling point.
Etheryte
Vue is built on web standards just as much as Nue is. That is, web standards are there underneath, but both libraries add custom sugar on top. A good example is iterating over list items in Nue [0] and in Vue [1]. Neither is "pure web standards with nothing else", in fact it's exactly the same custom stuff, save for what keyword they chose to use.
In this light, I would say Nue's claims about standards first and only are pretty misleading, it does the same exact thing as existing libraries do.
tipiirai
There seems to be two ways to interpret Nue:
1) This is amazing, thank you for the important contribution to the web!! 2) This is high horse / funny / sad...
I find this interesting. People can make up their mind from the link you posted.
veidelis
Here we to with the "minimalistic stringy language" again.
<a :for="src, i in images" class="{ current: i == index }" @click="index = i"></a>
ediatedia
React has it's problems, but for me one of the most appealing things is doing away with this magic attribute sprinkling that is a maintenance nightmare and just going all in on JSX.
lelanthran
> <a :for="src, i in images" class="{ current: i == index }" @click="index = i"></a>
Seconded.
I gotta be honest: while I actually am sold on the principles in the rationale, I'm not so crazy about what the implementation looks like.
robertoandred
Look at that standards-based code! Wow!
smrtinsert
To be fair that's perfectly clear to me. Reminds me a bit of xslt but not in a bad way
sureglymop
Reminds me of the old angular template syntax.
createaccount99
Sayonara editor integration.
It is interesting, but I really dislike the way it tries to bash every other tech in the blog post, on the homepage and in the docs itself. The tone is very confident, but it will put you open to a lot of scrutiny.
Instead it could really use a lot more explanation on how it works. If you make comparisons make sure they are fair. The image "JavaScript mixed together" and "Strict separation of concerns" is just comparing apples with oranges. Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css. I don't believe that it does the same thing.
Some of the claims are strange. It praises standard HTML but apparently you have to use some custom Markdown syntax to write it. How does that add up? And on top of that it also introduces new syntax for loops and variables.
This could all work perfectly fine. But my suggestion would be to talk more about how it works and what are the advantages and less trying to bring down competitors. It could use less grand claims and focus more on what it really does.