12 ms·

A standards-first web framework

• tipiirai 2y ago
  Author here: this is Nue's new, more natural direction. Our previous focus on design engineers and CSS design systems was accurate, but missed the most important point: the web platform itself has evolved to eliminate the need for most framework abstractions. What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page. This is a long term, ambitious project to strip away these artificial layers and return web development to its core strengths. Instead of fighting web standards, we're taking them to their absolute peak. Happy to hear your feedback.
  • assimpleaspossi 2y ago
    Repeating this here for emphasis: >>the web platform itself has evolved to eliminate the need for most framework abstractions.
    • mickael-kerjean 2y ago
      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 https://github.com/mickael-kerjean/filestash [2] https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3UQ867SPQQA43P2F&secret_access_key=zuf%2BtfteSlswRu7BJ86wekitnifILbZam1KYY3TG&region=us-east-2&encryption_key=&endpoint=https%3A%2F%2Fplay.minio.io%3A9000%2F https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3...
      • bitpush 2y ago
        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/contributors 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 2y ago
          > 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 2y ago
    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 2y ago
      Gotcha. My next argument is going to be visual trough the design systems explained on the article. Hope that's clearer.
  • bitpush 2y ago
    What's your reasoning behind the choice of markdown? To quote yourself - > What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page If HTML is so elegant, why isnt nuejs not using it? --- On the similar line, if you're so much for web standards, why are you recommending the use of Bun which breaks so much of standards in the name of speed?
    • tipiirai 2y ago
      HTML for layout, Markdown for content. How else could it be?
      • bitpush 2y ago
        The entire nuejs route is built using markdown. https://github.com/nuejs/nue/tree/master/packages/examples/simple-blog/welcome 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.
        • tipiirai 2y ago
          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 2y ago
            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.
            • tipiirai 2y ago
  • buster 2y ago
    Regarding "What began as elegant HTML, CSS, and JavaScript...": I don't know. Did you write websites 15-20 years ago?
  • robertoandred 2y ago
    You seem to have a fundamental misunderstanding of React, Next, etc. They don't stop you from using native CSS or HTML functionality.
    • recursive 2y ago
      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 https://react.dev/learn/manipulating-the-dom-with-refs
      • robertoandred 2y ago
        Using HTML features doesn't have to mean manipulating another component's nodes.
        • recursive 2y ago
          But sometimes it does.
          • robertoandred 2y ago
            And that’s different from the primary use case of refs
            • recursive 2y ago
              Indeed, and it's also the most practical way to use standard DOM operations from inside of react.
  • andrewmcwatters 2y ago
    > 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/ 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 2y ago
  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 2y ago
    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 2y ago
      Obviously not a web standard, but Markdown is the closest one we have for content. Right?
      • bitpush 2y ago
        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 2y ago
      Damn, bitpush, mind easing off this crusade you're on? Your apparent anger adds little to the discussion.
    • robertoandred 2y ago
      Also I love how instead of standard JavaScript, Nue wants everyone to learn its own custom templating language.
• bitpush 2y ago
  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 2y ago
    (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/ 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 2y ago
      (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/4ed9b628f9f307f19bd6dd4d091ce8f199cc86a7/packages/nuekit/src/browser/view-transitions.js 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/4ed9b628f9f307f19bd6dd4d091ce8f199cc86a7/packages/examples/simple-blog/%40library/motion.css https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...
      • mind-blight 2y ago
        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
• mocamoca 2y ago
  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 2y ago
    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 2y ago
    Any React framework allows you to separate the graphical work from the logic.
• flashgordon 2y ago
  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 2y ago
    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.
    • smrtinsert 2y ago
      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 2y ago
      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.
• jkrems 2y ago
  > 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 2y ago
    This is about the gap between Figma and React/Tailwind/CSS-in-JS, which is wider than Figma -> CSS
• KTibow 2y ago
  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.
• Tade0 2y ago
  > 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 2y ago
    "standards-first" "bun" Choose one.
    • tipiirai 2y ago
      works with Node too
      • sgammon 2y ago
        Then why do you have "Install Bun" in the steps to get started?
    • devalexwells 2y ago
      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 https://bun.sh/docs/runtime/web-apis
      • sgammon 2y ago
        Bun.x is not a standard API
• __jonas 2y ago
  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 2y ago
    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 2y ago
  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 https://lit.dev
  • tipiirai 2y ago
    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 2y ago
      > 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.
• colonelspace 2y ago
  > 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 2y ago
    Jony Ive specifically has said he looks up to Dieter Rams and his philosophy
    • colonelspace 2y ago
      Yep, as I mention above
      • tipiirai 2y ago
        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 2y ago
          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 2y ago
          The man behind Apple's modern design philosophy is Jony Ive.
        • lelanthran 2y ago
          I'd go with "Dieter Rams is the inspiration behind Apple's design philosophy".
        • colonelspace 2y ago
• ripped_britches 2y ago
  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 2y ago
    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 2y ago
      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.
• tipiirai 2y ago
  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 2y ago
    > 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 2y ago
      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 https://nuejs.org/docs/compare.html
      • bitpush 2y ago
        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/ https://next-blog-starter.vercel.app/ and https://simple-blog.nuejs.org/ https://simple-blog.nuejs.org/
      • lelanthran 2y ago
• rramon 2y ago
  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 2y ago
    A lot is missing! Check out the vision and project status here: https://nuejs.org/vision/ https://nuejs.org/vision/
• localghost3000 2y ago
  > 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.
• pingpong777 2y ago
  [dead]
• KronisLV 2y ago
  > 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/unstyled/ https://primevue.org/theming/styled/ 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 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 2y ago
    > Depends on how you build things. Exactly! The more you put styling decisions into your components, the more you hardcode your visual design.
• veidelis 2y ago
  Here we to with the "minimalistic stringy language" again. <a :for="src, i in images" class="{ current: i == index }" @click="index = i"></a>
  • ediatedia 2y ago
    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 2y ago
    > <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 2y ago
    Look at that standards-based code! Wow!
  • smrtinsert 2y ago
    To be fair that's perfectly clear to me. Reminds me a bit of xslt but not in a bad way
  • createaccount99 2y ago
    Sayonara editor integration.
  • sureglymop 2y ago
    Reminds me of the old angular template syntax.
• prokopton 2y ago
  > 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 2y ago
  @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 2y ago
  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 2y ago
  big claims small evidence
• starlite-5008 2y ago
  [dead]
• weego 2y ago
  From its fundamentals, conflating product design philosophy and engineering simplicity is not a good start
• Kaotique 2y ago
  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.
  • tipiirai 2y ago
    > it could really use a lot more explanation on how it works How Nue works is _extensively_ documented: https://nuejs.org/docs/ https://nuejs.org/docs/ Most of these questions are also addressed in the FAQ: https://nuejs.org/docs/faq.html https://nuejs.org/docs/faq.html THe Markdown claim is also explained multiple times on this discussion
    • internetter 2y ago
      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 2y ago
        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.
• devalexwells 2y ago
  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/ https://infrequently.org/2024/11/if-not-react-then-what/
• devalexwells 2y ago
  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-performance-mistakes-final-pdf/273431101 https://www.slideshare.net/slideshow/performance-now-24-perf... * related video to above slides: https://www.youtube.com/watch?v=j5E_U_hu7g0 https://www.youtube.com/watch?v=j5E_U_hu7g0
• mattlondon 2y ago
  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 2y ago
    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 2y ago
  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 https://nuejs.org/docs/faq.html [2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
• Etheryte 2y ago
  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/ https://nuejs.org/docs/
  • tipiirai 2y ago
    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__ 2y ago
    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 2y ago
      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 https://nuejs.org/docs/#dynamic-html [1] https://vuejs.org/guide/essentials/list#v-for https://vuejs.org/guide/essentials/list#v-for
• bilekas 2y ago
  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 2y ago
    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 2y ago
    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 2y ago
      Everyone wants to recapture that mid-00s Rails energy.
  • deleted 2y ago
    [deleted]
  • ezfe 2y ago
    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.
• mrcwinn 2y ago
  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 2y ago
  From: https://nuejs.org/docs/ 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 2y ago
    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 2y ago
      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.
• zeroq 2y ago
  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 2y ago
  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 2y ago
  This guy doesn't know the difference between React and Tailwind.
• sgammon 2y ago
  Why are you building CSR when every other mature web framework is shooting for streaming SSR support? Why even build that at all?
  • sgammon 2y ago
    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 2y ago
  Why are you comparing yourself to Next.js, which is well-known to be slow?
• siquick 2y ago
  > 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.
• ChocolateGod 2y ago
  If it's a standards-first framework, why does it use YAML for Config and not JSON?
• nbittich 2y ago
  No thanks. I'd prefer to build my next project without any framework rather than install yet another cli on my machine.
• vivzkestrel 2y ago
  how does this compare to nuxt 3 and sveltekit 2?
• bartonhammond 2y ago
  Some ramblings about NueJS from a 70 year old dude with some time on his hands. ;) My thoughts after using nuejs building this: https://bartonhammond.github.io/nue-todo/ https://bartonhammond.github.io/nue-todo/. My source is available by clicking the icon in the bottom right. There's a better ToDo example done by the team but I don't have the source: https://nuejs.org/todomvc/ https://nuejs.org/todomvc/ Yes - I had to install somethings globally. No big deal for me. It was quick and painless. So I followed the https://nuejs.org/docs/tutorial.html https://nuejs.org/docs/tutorial.html and ran `nue create simple-blog`. The browser opened so fast I was stunned. I really couldn't believe what happened - less then 2 seconds and the app was generated, compiled/built and loaded in the browser. For me, having 'md' files containing content is so much better than html - having to write a boilerplate html file with all the required junk is tedious. For example, my main content page, the entry point, which is very readable, is https://github.com/bartonhammond/nue-todo/blob/main/index.md?plain=1 https://github.com/bartonhammond/nue-todo/blob/main/index.md... --- include: [form] title: Nue Todo --- # Nue Todo Example [app] It is a little magic but every framework has magic. Every framework requires learning how all the artifacts are related. The application component logic is included with the [app] So how did I like the development experience? Good and bad. It's early so there's a lack of things, or should I say, not fully fleshed out, such as examples, tutorials, editor support, testing, documentation, and run time errors detection and debugging. Examples | Tutorials The only example I could find was the "simple-dialog" which is also the only tutorial. The tutorial was helpful but a little light to get started. I wish there were more examples that were more targeted to specific concepts. Trying to start a new project was challenging. The "nue create" command has no other options but to generate the "simple-dialog" and there's no GitHub repo with something like "starter template". Testing I looked through the nuejs packages that include unit tests. That helped a little when looking at how the templating works. It was nice to see plain JS code - I too dislike TypeScript. There is no documentation on how to test a Nue application from the command line even though it looks like they know how. Maybe they just haven't gotten to it yet. Editor Support There are two extensions for VS Code that I installed. They helped w/ colorization and such but not so much for the "dhtml" files which contain both html and <script> tags. Trying to format the js code w/in the script tags didn't work for me. That being said, I found that editing in VS code was workable for now. I would like to have more editor support for editing the yaml and md files so I know what is valid and what options. Documentation There's a lot of documentation with a lot of examples but they are somewhat disjointed and not clear sometimes how they actually work. For example, there is a distinction between htm, html, and dhtml files but the examples don't provide what the file name is. With the lack of examples I could run, I found myself frustrated trying to piece the concepts together. Run time errors Sometimes the errors reported were helpful - clear and precise. But sometimes the messages provided were not specific nor associated with the actual code. The generated code in the browser showed the error but relating that back to the code was difficult. The Hot Reload worked sometimes but I had to continually reload the page to pick up the changes. I think there were "silent" errors somewhere that prevented it. It was intermittent. For example I tried building a "component" that contained a "table" and could never get it work - no indication of problem. Eventually I removed the table and got it working. Seems that if tables aren't support that an error while "linting" or some process would detect that. Another time I had a "click" action with the same name as my "todo" object property. The generated ui inserted the "function" into the UI rather than the property. Once I renamed the function, it worked. But trying to figure out the issue that was painful and took me a long time. Debugging With the components that have <script> tags, I would place a "debugger" statement and that was fine. But when things don't stitch up properly, for example, trying to figure out the issue was lacking. Overall I liked it a lot! It was nice to not have to wrangle with a lot of complexities. For me, the conceptual model I needed wasn't a huge lift as compared to learning new languages (functional) like Elixir & Phoenix, Gleam or Roc-Lang or picking up some other JS frameworks that I've tried (e.g. Svelte, Angular, Vue, Meteor, Hapi, etc) These are very mature frameworks and handle a lot of complexities, such as State Management, that NueJS doesn't have at this time due to it's newness. I didn't have to learn a new language - I already am familiar with html, js, css, yaml and md. That's a good thing! I was able to put the Todo app together in about 2 days. Learning a new framework / architecture is always challenging for me. This felt approachable without a big hurdle for entry - I was able to start playing around fairly quick. I don't plan on doing much more at this point. But I will circle back as additional functionality is released e.g Templates and SPA.