[HN Gopher] A standards-first web framework
___________________________________________________________________
A standards-first web framework
Author : tipiirai
Score : 156 points
Date : 2025-01-16 08:30 UTC (1 days ago)
(HTM) web link (nuejs.org)
(TXT) w3m dump (nuejs.org)
| tipiirai wrote:
| 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.
| assimpleaspossi wrote:
| Repeating this here for emphasis:
|
| >>the web platform itself has evolved to eliminate the need for
| most framework abstractions.
| mickael-kerjean wrote:
| 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=Q3
| AM3...
| bitpush wrote:
| 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.
| mickael-kerjean wrote:
| > Do you think the code can be extended and maintained by
| someone other than you? How about a large team?
|
| There's no track record of it but I believe it would be
| ok in the right team. The core idea was stolen from every
| other frameworks: "build your app as a tree of
| components". In the approach I went with, components are
| modular and expressed like this: ```
| export default function (render, props = {}) {
| render($domNode) } ```
|
| in practice, a working code loading another component
| would be: ``` import FooCompoment
| from "./component_foo.js"; export default
| function (render, props = {}) { const $node =
| createElement(` <div>
| <div data-bind="component_foo"></div>
| Name: ${props.name} </div> `);
| // render the component with an animation
| render(transition($node)); // render
| a child component FooComponent(
| createRender($node.querySelector(`[data-
| bind="component_foo"]`)), { ...props },
| ); } ```
|
| The syntax is arguably less nice than JSX but the upside
| is 0 running cost and the idea around decoupling
| components remain. A lot of people have argue that I just
| end up maintaining my own framework but the reality is
| what would be considered "framework code" fit under 200
| lines of code ....
| mind-blight wrote:
| 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 wrote:
| Gotcha. My next argument is going to be visual trough the
| design systems explained on the article. Hope that's clearer.
| bitpush wrote:
| 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 wrote:
| HTML for layout, Markdown for content. How else could it be?
| bitpush wrote:
| The entire nuejs route is built using markdown. https://git
| hub.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.
| tipiirai wrote:
| In Nue you're literally writing standard HTML, CSS and
| JavaScript when developing websites. Your Markdown- based
| content generates semantic HTML. Your styling is pure CSS
| with modern features like nesting and container queries.
| JavaScript remains vanilla JavaScript.
| igravious wrote:
| I'm not literally _writing " standard HTML, I'm literally
| writing Markdown and the tool you've yet to fully realise
| is _generating* HTML from the Markdown I'm _literally_
| writing.
| buster wrote:
| Regarding "What began as elegant HTML, CSS, and JavaScript...":
| I don't know. Did you write websites 15-20 years ago?
| robertoandred wrote:
| You seem to have a fundamental misunderstanding of React, Next,
| etc. They don't stop you from using native CSS or HTML
| functionality.
| recursive wrote:
| 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
| robertoandred wrote:
| Using HTML features doesn't have to mean manipulating
| another component's nodes.
| recursive wrote:
| But sometimes it does.
| robertoandred wrote:
| And that's different from the primary use case of refs
| andrewmcwatters wrote:
| > 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.
| gherkinnn wrote:
| Nice work. I've been following Nue for a while now. Stripping
| away (obsolete) abstractions in favour of what the web now can do
| natively is liberating.
| bitpush wrote:
| Nuejs uses markdown, which is _not_ web. You cant claim to be
| standards-first, yet use something that is 100% non web-
| standard.
|
| That is before we talk about their use of 'bun', which is
| famously my-way-or-highway engine.
| ellinoora wrote:
| Obviously not a web standard, but Markdown is the closest one
| we have for content. Right?
| bitpush wrote:
| Yes, and I like markdown.
|
| But Nuejs claims to be standards-first. The entire premise
| of the framework is "All these other frameworks bring their
| own stuff, and have lost the plot on how beautiful HTML,
| CSS and JS can be", and then they turn around and use
| Markdown (not-standard), cli (not standard), bun (not
| standard).
| gherkinnn wrote:
| Damn, bitpush, mind easing off this crusade you're on? Your
| apparent anger adds little to the discussion.
| robertoandred wrote:
| Also I love how instead of standard JavaScript, Nue wants
| everyone to learn its own custom templating language.
| bitpush wrote:
| 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.
| bitpush wrote:
| (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 wrote:
| (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/4ed9b628f9
| f307f19bd6dd4d09...
| mind-blight wrote:
| 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
| tipiirai wrote:
| The _why_ is extensively documented. See:
|
| https://nuejs.org/docs/
|
| Also FAQ:
|
| https://nuejs.org/docs/faq.html
| mind-blight wrote:
| I appreciate the links. I think this quote from the FAQ
| captures the disconnect for me:
|
| ``` This isn't about rejecting modern development - it's
| about recognizing that browsers now offer sophisticated
| capabilities that eliminate the need for most framework
| abstractions. ```
|
| The problem I have is that I agree with the initial
| premise, but I disagree with the conclusion. Framework
| architectures mostly solve different problems than modern
| web standards.
|
| If you want to go after specifics like 1) just use
| browser forms and stop re implementing the wheel, 2) you
| probably don't need a massive state validation library,
| or 3) stop building CSS features in JS, then I'm 100% on
| board. But that's not a problem with CSS-in-JS, JSX +
| render library, components, or many of the other targets
| you go after.
|
| Things like tailwind (for example) solve fundamentally
| different problems, and those have more to do with team
| standardization, avoiding bike shedding, and rapid
| prototyping. For styling in particular, I don't want to
| return to the days of crawling through thousands of lines
| of CSS - edited over years by multiple teams - to find
| all of the places where different styles impact the
| specific html component I'm looking at. That's tightly
| coupled code with loosely defined locations. JSX
| components just decay less quickly due to encapsulation.
|
| I've also just never seen the separation of CSS and HTML
| actually provide practical value. It's always been "check
| out what's possible!" projects like CSS zen garden. Super
| cool, but that decoupling just doesn't do much in
| practice.
|
| Like I said, I think there are some interesting ideas
| here, but I just don't think it's clear why this is a
| better approach for general web application development
| (which is the argument you appear to be making).
|
| I'm super curious to see if you prove me wrong, so I'll
| definitely keep an eye out :). I just don't yet see how
| the proposed solution solves the identified problems
| without pulling in a bunch of pain points that were
| already solved a while ago.
| tipiirai wrote:
| I understand this concern deeply. For developers who've
| spent years mastering JavaScript patterns and component
| architectures, the idea of "returning to CSS" can feel
| like a step backward. They remember the pain points of
| global styles, specificity wars, and maintaining large
| CSS codebases.
|
| But this perspective misses how fundamentally different
| modern CSS development has become. When you embrace CSS
| as your primary architecture, you're not just writing
| styles - you're building a design system. You can make
| typography following certain "musical" scales, colors
| maintaining precise OKLCH relationships, and spacing
| flowing from consistent ratios.
|
| It's also about the simplicity in semantic HTML. Consider
| a real example: a typical React component library might
| need four different versions of text styling: Text,
| Description, DialogDescription, and AlertDescription.
| Each requires its own component definition, TypeScript
| interfaces, and style declarations. But in a CSS-driven
| system, this complexity vanishes. A single typographic
| scale handles all text needs through mathematical
| relationships.
|
| This systematic approach leads to dramatically less code
| overall. Where JavaScript monoliths often grow to
| thousands of lines, a CSS-based system keeps in hundreds.
|
| Nue is of course not for everyone. It's specifically
| designed for developers who see CSS as a creative medium
| - who get excited about the possibilities of container
| queries, custom properties, and calc() functions. For
| these developers, CSS isn't just a styling language -
| it's a powerful system for expressing design.
| meiraleal wrote:
| Tipiirai, thank you very much for patiently replying all
| these comments. Tailwind is a terrible abstraction,
| nobody should be shamed for saying that and the people
| not used to modern CSS or the ones that can't organize
| code, well, they should be the ones explaining
| themselves.
| mind-blight wrote:
| > When you embrace CSS as your primary architecture,
| you're not just writing styles - you're building a design
| system.
|
| And
|
| > Nue is of course not for everyone. It's specifically
| designed for developers who see CSS as a creative medium
| - who get excited about the possibilities of container
| queries, custom properties, and calc() functions. For
| these developers, CSS isn't just a styling language -
| it's a powerful system for expressing design.
|
| Are both super interesting and make sense with a number
| of changes I've seen in the ecosystem. I respect CSS-
| focused developers (I'm not one, but I like to dabble)
| and appreciate a ton of innovation that's coming out of
| the designer-developers who try to push the boundaries of
| both the roles and the technology.
|
| The disconnect that remains for me is that client/server
| state management and scope creep are the two main drivers
| of sprawling code bases in my experience. Having a bunch
| of 1-off styles in a component definitely made design
| updates a nightmare, but tailwind and/or just using CSS
| variables helped improve that. Using service-oriented
| architecture (including on the frontend to keep complex
| business logic out of components), GraphQL + fragments +
| urql/apollo, and/or Remix (or a similar framework) were
| all really big steps forward in trying to solve the
| thorny state management problem. They all come with their
| own tradeoffs, but that's where most of the complexity
| and sprawl comes from in my experience.
|
| There's definite bloat from people re-inventing the wheel
| (forms are the most common one I encounter), but the
| explanation pages feel like Nue is a panacea. I only see
| how it improves specific areas rather than the whole
| architecture. I'll say, I really like how HTMX approached
| their education around this. Similarly, they're a "use
| the standards!" kind of library, but they have clear
| examples of what is solved, and what isn't solved. And
| their "isn't" includes cases where the current approach
| is better suited. That makes the scope a lot clearer,
| which I still feel like I'm missing from the Nue project
|
| ETA:
|
| It's also possible that I'm just not the target audience.
| Most of the projects I've built or lead have been either
| extremely event heavy (E.g. using Bluetooth sensors
| attached to limbs + timers to guide people step-by-step
| through exercises) or extremely data heavy (e.g.
| analytics and information collection based on dynamic
| ontologies). The data model and state management were
| always multiple orders of magnitude more complex than
| almost anything else.
| tipiirai wrote:
| Thank you, @meiraleal! The reception here is pretty
| brutal but expected, especially around CSS. Engineers
| consistently dismiss its power, no matter how it's
| presented. However, for those of us who work with design
| systems, the value is self-evident.
| rglullis wrote:
| > I've also just never seen the separation of CSS and
| HTML actually provide practical value.
|
| I would pay really good money to have a library of web
| components that implemented _only_ the document structure
| using semantic HTML and the Javascript interactivity, and
| kept all the styling on a separate CSS file. Something
| like headless-ui, but without any of the utility classes.
|
| Then we could move on from these template marketplaces
| (where each dev has to reimplement their own widgets for
| each different javascript framework), and we would have a
| simpler marketplace of "Web Component Themes".
| mind-blight wrote:
| You should check out Radix UI (https://www.radix-
| ui.com/). Same idea as headless ui, but it doesn't assume
| that you will use Tailwind. I _think_ they add css
| classes to all of their components to allow you to choose
| any styling method you want, but I'm usually working with
| ShadCN (which is one level up and uses tailwind).
|
| Though, I'll say that I agree with OP that a lot of
| functionality already exists within HTML and browsers.
| tipiirai wrote:
| 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#de
| v...
|
| NOTE: the document was just updated to match this concern
| bitpush wrote:
| You should clarify that you just updated that doc, based
| on the discussion here.
|
| It is kinda disingenuous to say "Check out the doc .."
| which gives the impression that all of the gaps people
| have identified in this thread was by design all along.
| tipiirai wrote:
| You're right - I should have been upfront about the
| documentation update. However, the point about "Less is
| More" being a fundamental coding philosophy was an
| important addition that better articulates how this
| principle shapes the entire framework. Next time, I'll be
| explicit. Thanks.
| Gualdrapo wrote:
| 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.
| tipiirai wrote:
| This blog is for introducing people to Nue's development
| model rather than a guide to minimalistic design. See
|
| https://nuejs.org/docs/tutorial.html
| layoric wrote:
| It's a nice change to see extremely clean html when viewing
| source though I must admit
| shiomiru wrote:
| And it hijacks my back button. It took two clicks to get back
| to HN. (Fennec/Android)
| devalexwells wrote:
| 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 wrote:
| 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.
| devalexwells wrote:
| I stand corrected--didn't notice at first. I do prefer
| the crossfade, admittedly.
| fenomas wrote:
| 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 wrote:
| 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:
|
| https://nuejs.org/docs/
|
| 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 wrote:
| I think this Iron Maiden argument is best explained on the
| article, specifically on the section about the design
| engineering problem.
| davedx wrote:
| 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!
| actionfromafar wrote:
| More like bashing Enterprise Java Beans?
| palmfacehn wrote:
| Maybe the Spring ecosystem.
| mind-blight wrote:
| 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 wrote:
| The only similarity is that it is/was popular to bash both.
| The reasons for bashing and utility of each are vastly
| different.
| robertoandred wrote:
| And a lot of that bashing comes from people who don't
| understand React or the ecosystem it's part of.
| recursive wrote:
| Personally, I only started bashing it in earnest after
| reading most of its source code.
| mocamoca wrote:
| This article is extremely well written and energizes me... Having
| a framework that allows separating the graphical work from the
| logic would be great. But I have trouble imagining this idea
| passing the brutal test of production -- except for showcase
| websites and blogs. I'm specifically thinking about apps
| (linear?) But I'm looking forward to seeing what comes next and
| hope to get more information when the templates arrive :)
| tipiirai wrote:
| You're not alone! The feedback form shows overwhelming relief
| from developers tired of complexity. Single-page applications
| will be the true test of the standards-first approach, as
| that's where the contrast with current practices becomes most
| stark.
| robertoandred wrote:
| Any React framework allows you to separate the graphical work
| from the logic.
| flashgordon wrote:
| 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 wrote:
| 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.
| Vampiero wrote:
| 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.
| cardanome wrote:
| > 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.
| bilekas wrote:
| > 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.
| flashgordon wrote:
| 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.
| tipiirai wrote:
| 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 wrote:
| 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?)
| jkrems wrote:
| > 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 wrote:
| This is about the gap between Figma and React/Tailwind/CSS-in-
| JS, which is wider than Figma -> CSS
| KTibow wrote:
| I probably won't ever use this but the docs look really nice.
| Specifically: the header combines a blurry backdrop filter with
| something like `background: radial-gradient(transparent 1px,
| white 1px) center / 4px 4px` to make a background of transparent
| dots.
| __jonas wrote:
| I like the attitude in general although it does come across a bit
| arrogant, the goal seems to be a noble one.
|
| I can't really tell what it currently offers over Astro, it does
| seem to be a static site generator with a couple of nice tricks,
| I feel like Astro has perfected this.
|
| I don't think it's any more "standards first" than Astro, or am I
| missing something?
| bitpush wrote:
| I'm glad that you brought up Astro. This is Astro but crappier.
| It even has "islands", something that Astro has made super-
| duper popular.
|
| To their credit, Astro authors are humble to tell you that
| Astro is not a good fit for all usecases, and focuses sharply
| on blogs, static content with little interactivity.
| spankalee wrote:
| 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
| tipiirai wrote:
| 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 wrote:
| > 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 wrote:
| The issue is the coupling of HTML and CSS into your
| JavaScript code, which is a step away from the standards
| first development model.
| spankalee wrote:
| Can you explain how it's not standards first?
|
| Web components can be written in standard JS modules,
| loaded by or inlined into standard HTML, instantiated by
| standard custom element tags, rendered with the help of
| standard <template> elements, and styled with standard
| CSS.
|
| If you don't use the web platform's native facilities for
| re-use, then you do have to use some non-web-standard
| system, like a server framework. Is there some way you
| see that that's more standard than the web?
| tipiirai wrote:
| In Nue you're literally writing standard HTML, CSS and
| JavaScript.
|
| Your Markdown- based content generates semantic HTML.
| Your styling is pure CSS with modern features like
| nesting and container queries. JavaScript remains vanilla
| JavaScript.
|
| React and similar frameworks introduce non-standard
| abstractions like JSX and proprietary component models
| that deviate from web standards. They couple structure,
| styling and behavior into JavaScript components.
|
| With Nue your codebase becomes primarily CSS-based, with
| clean separation between content, styling and behavior.
| You're working directly with CSS rather than through
| framework abstractions. Hopefully this FAQ answers most
| of your questions:
|
| https://nuejs.org/docs/faq.html
| boredtofears wrote:
| Perhaps this is pedantic but for someone who seems
| principled about strictly using standards, markdown
| itself has no real standard - you'll find wildly
| different implementations all over the place.
| tipiirai wrote:
| Not pedantic at all. Markdown is not a web standard, but
| it enables standards first development by keeping things
| separate. Nue's Markdown implementation is also very
| different, much closer to MDX.
| kevin_thibedeau wrote:
| > Nue's Markdown implementation > MDX
|
| The problem with Markdown is there is no standard.
| polydevil wrote:
| > Your Markdown- based content generates semantic HTML
| HTML is far more expressive in semantics, so using
| markdown to get html means you will never be able to get
| most semantic things you actually wanted.
|
| React couples the structure, styling into js components
| only if you make it so. You can just write style.css,
| import it and refer to it is classname as
| `className="my_custom_class"`.
|
| And there is no clean separation of concern when it comes
| to html, css and js. You can force to separate them, but
| that would be a separation of technologies, not concerns
| - they are too intertwined to be separated. And the
| example of island on the tutorials proves that: ``` <form
| @name="contact-me" @submit.prevent="submit"
| autocomplete="on"> ```
|
| There is no way to create a standard-first framework
| without introducing some form of DSL. This doesnt look
| like html, this doesnt look like js, and it is def not
| primarily css based anything.
|
| ___ The project is nice, using new features like starting
| style, view transition - instead of js based solutions is
| cool. There are a lot of experimental features, like
| popover api. The browser support is low and those things
| are not production-ready for everyone (maybe for some).
|
| The approach is good, the site is good, the docs are
| good, but I dont like the distinction from competitors.
| Like I can use all those features in
| react/vue/astro/qwik. What makes you unique? Being able
| to apply web standard solutions? How about something
| along the lines - we create better primitives so you can
| create you website faster/easier?
| tipiirai wrote:
| I think this actually reveals the key misunderstanding.
| In a properly designed system, most of your codebase
| becomes CSS - often 90% or more when it comes to content-
| heavy websites written in Nue. The JavaScript handling
| pure functionality, HTML expressing semantic structure,
| and CSS doing the heavy lifting of systematic design and
| relationships.
|
| This isn't separating technologies - it's letting each
| part focus on its core concern. HTML focuses on content
| structure and meaning. JavaScript handles true
| interactivity. And CSS becomes the primary engine for
| both design and sophisticated functionality through
| modern features like container queries, custom
| properties, and view transitions.
|
| This natural separation produces systems that are both
| more powerful and dramatically smaller than JavaScript
| monoliths. The sophistication comes from systematic
| relationships, not artificial coupling.
| bitpush wrote:
| > most of your codebase becomes CSS
|
| I dont understand how you're making this claim with a
| straight face. You're either willfully ignorant, or
| pretending to be too abstract.
|
| If your understanding on web-development is someone
| tweaking css values, I think you have a hug gap in your
| understanding.
|
| You've drank the Apple/Linear/Dieter Ram kool-aid a bit
| too much, and you think throwing "less is more", "strip
| it down to the bare minimum" is all emblematic of that.
|
| Good design is about making the complex simple. Not
| making the simple simple.
| tipiirai wrote:
| The straight face is rooted to numbers:
|
| https://nuejs.org/docs/compare.html
| afavour wrote:
| And the example is a blog. I think a lot of us would
| agree that React is a bad choice for a blog. But React is
| also used in a million other applications that need a lot
| more dynamism than a blog does. The idea that 90% of an
| app like that would be CSS makes no sense.
| meiraleal wrote:
| Lit and React are quite different, there is no JSX and
| lit-html is greatly integrated with web standards. I like
| your approach but if much, your platform makes less use
| of web standards than Lit, not more.
| jeswin wrote:
| 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.
|
| [1]: https://github.com/webjsx/magic-loop
|
| [2]: https://www.webjsx.org
| tipiirai wrote:
| 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 wrote:
| > 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.
| threetonesun wrote:
| BEM naming conventions in CSS and splitting HTML into
| components at the back end template level existed long
| before JS frameworks and single page applications.
|
| I'd say the big mind-shifts with React were the virtual
| DOM replacing things like progressive enhancement, and
| later with Next and server side components, the
| commingling of back-end and front-end, which is mostly a
| complicated solution to the problem already created by
| moving away from progressive enhancement.
| WA wrote:
| 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.
| spankalee wrote:
| 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.
| skrebbel wrote:
| Fwiw there's a great VS Code extension for lit-html which
| (for me) fully solves the IDE support issue. https://marketpl
| ace.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.
| chris_pie wrote:
| Magic Loop looks very similar to Crank (that nobody knows
| about either). Was it an inspiration?
| jeswin wrote:
| 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 wrote:
| 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!
| colonelspace wrote:
| > 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 wrote:
| Jony Ive specifically has said he looks up to Dieter Rams and
| his philosophy
| colonelspace wrote:
| Yep, as I mention above
| tipiirai wrote:
| 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)
| devalexwells wrote:
| I think the point is that "the man behind" connotes
| direct responsibility, not indirect inspiration. It's
| misleading wording.
|
| You might try "Dieter Rams inspired Apple's design
| philosophy."
| jug wrote:
| The man behind Apple's modern design philosophy is Jony
| Ive.
| lelanthran wrote:
| I'd go with "Dieter Rams is the inspiration behind
| Apple's design philosophy".
| colonelspace wrote:
| Well, you can be as firm as you like about the claim,
| it's still reads as if Dieter Rams worked for Apple.
|
| Dieter Rams no doubt had significant influences and
| admiration for those who shaped his work and design
| philosophy, should we credit those people as being behind
| Apple also? How far should we go? Perhaps we need to
| point out da Vinci is also one of the men behind Apple's
| design philosophy.
|
| Seems reasonable to suggest "the man behind" is generally
| understood to mean "the person directly responsible for".
| Tade0 wrote:
| > Get Started with Nue
|
| > 1. Install Bun
|
| Odd requirement to have. I guess they're trying to be consistent
| in breaking with the old paradigms.
| bitpush wrote:
| "standards-first"
|
| "bun"
|
| Choose one.
| tipiirai wrote:
| works with Node too
| sgammon wrote:
| Then why do you have "Install Bun" in the steps to get
| started?
| devalexwells wrote:
| Bun is built on web standard APIs [1]. Is your point that
| it's not _industry_ standard?
|
| [1] https://bun.sh/docs/runtime/web-apis
| sgammon wrote:
| Bun.x is not a standard API
| ripped_britches wrote:
| Everybody who is so upset about the proliferation of so many
| heavily abstracted, complicated JS frameworks should probably
| recognize for a moment that we have a horrible backwards
| compatibility problem with HTML, CSS, and JS. None were ever
| designed with the idea that they could support apps like freaking
| Netflix for Smart TVs or React Native apps for virtual reality.
|
| If you want a truly standards first UI development stack, try
| Flutter. It critically changed how I view UI development: 1
| canvas for any screen. Truly a beautiful thing.
| tipiirai wrote:
| Flutter fundamentally misunderstands web standards and
| separation of concerns. It imposes a custom rendering engine
| and widget system on top of the web platform, creating another
| layer of abstraction rather than leveraging native browser
| capabilities.
|
| The web already has a powerful "canvas for any screen" - it's
| called HTML and CSS. Modern features like container queries,
| CSS grid, and view transitions provide sophisticated responsive
| capabilities without fighting against web standards.
|
| Flutter's approach is precisely what we need to move away from
| - trying to solve web development challenges by building on top
| of the platform rather than understanding its inherent
| strengths. True standards-first development means embracing
| HTML's semantic structure, CSS's systematic design
| capabilities, and JavaScript's proper role in progressive
| enhancement.
|
| Creating better interfaces doesn't require new abstractions. It
| requires deeper understanding of web standards and systematic
| design principles.
| ripped_britches wrote:
| So how do you write a mobile app with HTML and CSS? Or a TV
| app? Or a car app? Or a watch app? Or a VR app?
|
| The "one simple standard" falls apart when you need multiple
| platforms.
|
| And honestly the document and document styling model wouldn't
| work very well for these platforms.
|
| Everything from "center a div" to "pinterest style masonry
| grid" is 100x easier in flutter.
|
| Also, flutter is not "another abstraction" on top of web. The
| widgets don't map to DOM elements at all. It is a completely
| orthogonal approach. All of the other web frameworks are
| indeed abstractions, but flutter is not.
|
| Just curious, have you used flutter before? My impression is
| that you would like it because there is actually less
| abstraction. A widget just represents a paintable object on a
| canvas without any more indirection than you give it.
| pieix wrote:
| Do you have any favorite Flutter projects I could click around?
| It's an intriguing concept but I've been offput thus far by
| Google's lack of adoption of its own framework.
| ripped_britches wrote:
| Yea this is the same as GCP - Google doesn't use their own
| public cloud offering. But that's an organizational decision
| I don't know anything about. Sonos app is a popular flutter
| app that made some news recently. Google earth as well. I
| think they have a showcase.
| tipiirai wrote:
| I want to address Markdown and it's role in standards first
| development.
|
| While MD itself isn't a web standard, it's a strategic choice
| that reinforces standards-first development by generating pure,
| semantic HTML. This creates a natural separation between content
| structure and visual presentation.
|
| Consider the impact on CSS development.
|
| In React codebases, engineers spend 90% of their time writing
| JavaScript - managing state, coordinating effects, optimizing
| builds. Style sheets become an afterthought, buried under
| framework patterns and utility classes.
|
| Nue flips this ratio: codebases become 90% CSS, focusing
| engineering effort on systematic design through web standards. By
| keeping content in Markdown and presentation in stylesheets, we
| maximize the power of native CSS features - from custom
| properties and container queries to mathematical relationships
| for typography and spacing.
| bitpush wrote:
| > Nue flips this ratio: codebases become 90% CSS
|
| This shows a lack of understanding of what a modern webapp is
| meant to be. Again, your framework is a attempt for static
| blogposts & other non-interactive/minimally intercative sites.
| Modern javascript developers build complex webapps, whether you
| like it or not.
|
| You think stripe.com (webapp) engineers are spending 90% of the
| time tweaking css?
| tipiirai wrote:
| In content-heavy websites, yes. Single-page apps are a
| different game obviously. this is a real number when
| comparing Next.js blog starter to Nue's blog starter:
|
| https://nuejs.org/docs/compare.html
| bitpush wrote:
| If you want to be taken seriously, please do a like-for-
| like comparison.
|
| Your comparison is between 2 drastically different sites.
| https://next-blog-starter.vercel.app/ and https://simple-
| blog.nuejs.org/
| lelanthran wrote:
| > In content-heavy websites, yes. Single-page apps are a
| different game obviously.
|
| Content-heavy websites have (for me anyway) multiple
| acceptable solutions currently.
|
| I want to see what your DSL looks like for SPAs.
|
| To be clear, _I_ am your target - developer who noped out
| of JS frameworks and want something better.
|
| But, like I said, I already have multiple options for
| separation of concerns with content-heavy or mostly-static
| sites. What I _don 't_ have is a decent SPA framework that
| neatly does separation of concerns.
| TRiG_Ireland wrote:
| There are, of course, many different flavours of Markdown.
| Which do you use? The best thing to come out of Markdown is
| probably Djot, which is inspired by Markdown but just different
| enough to not really be considered a flavour of Markdown. The
| designer, John McFarlane, put a lot of thought into it, and
| designed it to be easy to parse.
| rramon wrote:
| No auto dark mode on the website (it's easy with modern vanilla
| CSS) is a bummer. If they miss that, what else are they missing?
| tipiirai wrote:
| A lot is missing! Check out the vision and project status here:
| https://nuejs.org/vision/
| localghost3000 wrote:
| > What began as HTML, CSS, and JavaScript has devolved into a
| complex build orchestration demanding hundreds of dependencies,
| even for a simple page.
|
| I'm no react fan boy, but this is a total straw man. Vite and the
| like make builds dead ass easy. Also, to try to represent the
| days before react as some kind of utopia is total horseshit. I
| have been doing front end for just as long as the author (nearly
| 20 years) so I lived through that stuff. It was total chaos
| before. Just gobs of unmaintainable shit. No tests. No reusable
| code. Nothing. Does react have problems? Yes. Do people use it
| when they shouldn't? Also yes. But the whole "it's too
| complicated to get it to build" argument is tired.
| KronisLV wrote:
| > You cannot take a headless structure and apply different
| designs to it.
|
| Depends on how you build things.
|
| https://primevue.org/theming/unstyled/
|
| https://primevue.org/theming/styled/
|
| In most cases, though, there will inevitably be some blurring
| between the layers, your back end will be coupled to the data
| model somewhat and the front end will then be coupled to that,
| both the design, layout and functionality, unless you attempt to
| build a library or a framework that's detached from a specific
| project/domain.
|
| For example, even Vue lets you extract your layout into a
| separate component and then fill it in with slots
| https://vuejs.org/guide/components/slots.html but nobody ever
| does that because that'd take more time and they end up just
| having BasketComponent instead of BasketLayout and
| BasketComponent, same for not trying to detach the styles from
| specific components, nobody wants to do that.
| tipiirai wrote:
| > Depends on how you build things.
|
| Exactly! The more you put styling decisions into your
| components, the more you hardcode your visual design.
| veidelis wrote:
| Here we to with the "minimalistic stringy language" again.
|
| <a :for="src, i in images" class="{ current: i == index }"
| @click="index = i"></a>
| ediatedia wrote:
| 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 wrote:
| > <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 wrote:
| Look at that standards-based code! Wow!
| prokopton wrote:
| > The core issue, however, is the inability to participate in the
| actual craft. Design decisions are buried in React components
| with cryptic expressions like flex items-center shadow-lg p-6
| hover:bg-gray-50 dark:bg-gray-800
| py-[calc(theme(spacing[2.5])-1px)]. This might make sense for
| JavaScript engineers, but it's an insult to systematic design.
|
| This is Tailwind nonsense--not JavaScript.
| popcorncowboy wrote:
| @tipiirai your measured and patient responses in this thread are
| impressive to witness. It's bloody hard to not come back fists
| swinging when you're dealing with this level of resistance,
| regardless of why. <Chapeau />
| cies wrote:
| JS would not be my weapon of choice. Your FW can be standards-
| first, but I never get to move my code away from the language it
| is written in.
| dvrp wrote:
| big claims small evidence
| weego wrote:
| From its fundamentals, conflating product design philosophy and
| engineering simplicity is not a good start
| Kaotique wrote:
| 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.
| lelanthran wrote:
| > 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 wrote:
| > 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 wrote:
| >> 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.
| robertoandred wrote:
| I'm not sure what you're searching for or what you
| consider "wrapping it in React". You need some sort of JS
| to open and close it.
|
| const Modal = ({ isOpen, onRequestClose, ...rest }:
| ComponentProps<"dialog"> & { isOpen: boolean;
| onRequestClose: () => unknown; }) => {
| const dialogRef = useRef<HTMLDialogElement>(null);
| useLayoutEffect(() => { if (isOpen) {
| dialogRef.current?.showModal(); } else {
| dialogRef.current?.close(); } }, [isOpen]);
| return ( <dialog ref={dialogRef}
| onClose={(e) => { e.preventDefault();
| onRequestClose(); }} {...rest}
| /> );
|
| };
| lolinder wrote:
| You're missing the main point that OP is making: TFA's
| complaint with these patterns isn't that it's React, it's
| that it's not using the modern tooling. That is true, but
| could just as easily be an argument for updating old
| React code bases to take advantage of the new features.
| There's nothing inherently React about avoiding using
| them, it's usually done because of some combination of
| lack of knowledge of the changes and a need for various
| reasons to support old browsers. (Yes, a lot of real
| world use cases still require supporting versions of
| Safari older than 15.4 [0]).
|
| It's not fair to take these legacy patterns, which are
| what made React and friends so much better than the other
| options that were available at the time, and compare them
| to features that were specifically built with the
| intention of making those patterns no longer necessary.
|
| Once those new features are supported on most devices
| (which again, they aren't in many cases) I'm excited to
| see them incorporated into code bases written in any
| framework.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/di...
| ozim wrote:
| 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.
| ozim wrote:
| 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.
| spankalee wrote:
| 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 wrote:
| 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.
| turnsout wrote:
| 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 wrote:
| > it could really use a lot more explanation on how it works
|
| How Nue works is _extensively_ documented:
|
| https://nuejs.org/docs/
|
| 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
| internetter wrote:
| 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 wrote:
| 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.
| internetter wrote:
| hence why I said "on top of" a static site generator. By
| gluing some things together, you can get the same
| product.
|
| You've done this gluing, sure, but surely at a cost to
| flexibility. You also didn't even glue, you just
| reimplemented the whole stack.
| lolinder wrote:
| 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.
| devalexwells wrote:
| I resonate with much of what you've written in here. In
| particular, the cultural costs. I work on a "frontend platform"
| team at a mid-sized company and spend most of my day trying to
| get the React/Next ecosystem to play nice for our engineers. If I
| rearchitected it from scratch, it would not use Next, but I
| digress.
|
| Some critiques:
|
| 1. As others have mentioned, lots of abstract in here, not so
| much data. That's a hard sell to engineers. You're going to get a
| lot of theory responses, which maybe is what you want at this
| stage, but it might help to make that clearer if so.
|
| To avoid this, you might consider refocusing the narrative. I
| have personally found that while appealing to Developer
| Experience (DX) is the fad, debating DX is an uphill battle. IMO
| we should appeal to something more concrete: User Experience. The
| discussion has to start and end with users. DX is part of it, but
| often over-represented. If I can sit down with someone and show
| them X technology is failing our users because Y fundamental
| flaw, the conversation is no longer on frameworkism. It's instead
| on how you solve problems for your users effectively. See Alex
| Russell's discussions on this, as divisive as they might be [1].
|
| 2. The why is clear. The what and how are not. Clarify what
| you're doing that is different. For example, Astro is also
| standards-based. Astro also approaches the problem from
| progressive enhancement and fundamentals over frameworkism. It
| seems like your focus is on separation of concerns and design
| principles? While I disagree on the dogmatic approach re:
| separation (I personally like components and composition), it
| would help to highlight your diff.
|
| * I mention Astro, but this is true of other newer approaches,
| e.g. 11ty, Qwik, Enhance.
|
| 3. In another comment you claim that [in Nue] 90% of your
| codebase becomes CSS. I get that this is coming from the
| reduction of JS to do what HTML and CSS should, but it feels...
| disingenuous? At scale, no frontend or fullstack engineer I work
| with is spending even close to the majority of their time on CSS,
| regardless of stack. The focus IME is on building features,
| parsing/integrating data, and everything tangential to the
| feature (architecture review, testing, docs, etc).
|
| Just some thoughts! I'd be interested in hearing more in the
| future.
|
| [1] https://infrequently.org/2024/11/if-not-react-then-what/
| devalexwells wrote:
| Couple other notes:
|
| You appeal to simplicity a lot, which is great! Contemporary
| frontend is way too complex. But a lot of what you're saying
| comes off as too black and white and rejects some of the
| learnings of the past decade.
|
| Some examples:
|
| - Inlining CSS is _usually_ faster, but there are caveats to
| this. [1]
|
| - You say, "the fastest page load is one that requires just a
| single request". This makes it sound like we should be avoiding
| the platform (the browser). Browsers can efficiently parallelize
| multiple requests. We shouldn't have the 200+ requests that many
| sites make, absolutely. But a rejection of requests entirely is
| not a goal. If you have a few interactive components that rarely
| change, having a few chunks that also rarely change means better
| caching too.
|
| Point being there's no substitute to engineering and
| experimenting with what actually makes your site perform best
| _for your users_.
|
| [1] https://www.slideshare.net/slideshow/performance-
| now-24-perf...
|
| * related video to above slides:
| https://www.youtube.com/watch?v=j5E_U_hu7g0
| mattlondon wrote:
| I think the "frontend engineering problem" they are talking about
| is actually the "React engineering problem". All the examples
| seem to be entirely about react and only react.
|
| I'm pretty happy with modern angular for big apps with big teams
| working on it, and just vanilla JavaScript for smaller simple
| things.
|
| I've tried lit etc al for components but honestly beyond the pure
| atomics (buttons etc) there is very little that ever gets reused
| between projects
| robertoandred wrote:
| Beyond that, his examples are either bad React engineering,
| engineering choices that are totally separate from React, or
| solutions needed because web-native options didn't exist yet.
| rafram wrote:
| The FAQ [1] doesn't mention compatibility. How am I supposed to
| ship a site with this when APIs it depends on, like popover [2],
| are only supported by the very latest browser versions?
|
| [1]: https://nuejs.org/docs/faq.html
|
| [2]: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Global_att...
| Etheryte wrote:
| 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.
|
| [0] https://nuejs.org/docs/
| tipiirai wrote:
| 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.
| k__ wrote:
| 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 wrote:
| 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.
|
| [0] https://nuejs.org/docs/#dynamic-html
|
| [1] https://vuejs.org/guide/essentials/list#v-for
| bilekas wrote:
| 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.
| mossTechnician wrote:
| 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.
| andrewmcwatters wrote:
| 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
|
| Stinks all around.
| adamrezich wrote:
| Everyone wants to recapture that mid-00s Rails energy.
| ezfe wrote:
| 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 wrote:
| 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 wrote:
| 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.
| WorldMaker wrote:
| There's no such thing as POSIX. Every platform needs
| support a little different. macOS isn't nearly as similar
| to a random distribution of Linux as a lot seem to think
| and vice versa, you can't just build on Linux and expect
| macOS support.
|
| There's no such thing as POSIX. There have been a million
| different standards named POSIX. The only one that really
| mattered long-term commercially was "capable of being
| used for US Government projects" and that one both has
| and has not claimed Windows was "POSIX" in different
| decades. "Has a file system and a command line and is
| capable of running programs." Exciting standards stuff
| like that. Everyone who uses the term "POSIX" has a
| different definition in mind, in my experience.
|
| > Most full stack web developers are not doing things in
| a Windows environment.
|
| I think that depends as much on which part of the country
| you live in. There's a lot of "dark matter" developers
| doing boring full stack things on Windows. You might not
| see them, you might not care about them, doesn't mean
| they don't exist. Also the last straw poll I saw was
| something like a 50/50 split. I don't any side can claim
| "most". I do think that yes, the most _visible_ web
| developer is the stereotype of the Bay Area macOS
| programmer with a hipster 'stache a near permanent chair
| in some coffee shop. I don't think that is _most_ web
| developers in the general world.
| andrewmcwatters wrote:
| What in the world are you talking about? This is
| completely incoherent.
|
| There's literally a POSIX specification at
| https://pubs.opengroup.org/onlinepubs/9799919799/
|
| Do you seriously not think the people who author Node, et
| al aren't looking at POSIX, the C Standard Library,
| Linux, macOS, Windows and moving down the list in that
| order?
|
| Where do you think all of `node:fs` comes from? Because I
| sure don't see GetFileAttributesEx there.
|
| Or who could forget good old CreateDirectoryA? I guess
| Bun didn't get the memo.
| smt88 wrote:
| > _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.
| mrcwinn wrote:
| I love these claims -- 30x smaller than Next! Y% faster than
| Next! (And then a roadmap making it clear it's not even close to
| feature-complete.) Something makes me think as the features
| mount, that bundle will get a little bigger, maybe get a little
| slower.
| naasking wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _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?
| zeroq wrote:
| 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.
| ulrischa wrote:
| I read it and was happy. But then I dived deeper and it is the
| same as all the other frameworks. Why is this not using
| Webcomponents mixed with markdown? Why not JS template literals?
| Why do I need bun? And not to mention the strange naming
| convention: htm for Client html for Server- wtf?
|
| What I want is Astro with just web standards like Webcomponents
| robertoandred wrote:
| This guy doesn't know the difference between React and Tailwind.
| sgammon wrote:
| Why are you building CSR when every other mature web framework is
| shooting for streaming SSR support? Why even build that at all?
| sgammon wrote:
| Why is this getting downvoted? Lol. It's a substantive, valid
| question. CSR is inferior to SSR in many ways: SEO,
| performance... so, why build it at all? I am only curious.
| sgammon wrote:
| Why are you comparing yourself to Next.js, which is well-known to
| be slow?
| siquick wrote:
| > The core issue, however, is the inability to participate in the
| actual craft. Design decisions are buried in React components
| with cryptic expressions like flex items-center shadow-lg p-6
| hover:bg-gray-50 dark:bg-gray-800
| py-[calc(theme(spacing[2.5])-1px)]
|
| Give me Tailwind standardised utility classes over having to
| search through the codebase to find what a dev 6 years ago called
| a CSS class.
___________________________________________________________________
(page generated 2025-01-17 23:01 UTC)