A standards-first web framework

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.

Repeating this here for emphasis:

>>the web platform itself has evolved to eliminate the need for most framework abstractions.

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.

Yep, I rewrote my OSS Dropbox like frontend for every file transfer protocol in vanilla JS [1], so far it's not only faster with smaller memory footprint, the app is faster to boot, lighter in size despite the optional build system, there is no framework code I don't know about running at the worst possible time and I can effectively run to the maximum of what a browser can do.

It's refreshing to be able to open the network tab and see the original files coming out [2] and the developer console showing the full structure of it untouched in the same way it's visible from github.

This has opened new doors that was previously closed with any kind of framework, the option to dynamically patch those js file at runtime to customise the interface for unique needs that make sense for someone but wouldn't make sense for 99% of everyone else. Now it's just a matter of submitting a small plugin patch that do it and tada, a happy customer while maintaining only a single codebase

[1] https://github.com/mickael-kerjean/filestash

[2] https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3...

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?

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.

> 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 ....

HTML for layout, Markdown for content. How else could it be?

The entire nuejs route is built using markdown. https://github.com/nuejs/nue/tree/master/packages/examples/s...

which is totally non-standard. Super common, but non-standard. You compiled the markdown to html using a tool (another non-standard item)

You dont get to claim "standards-first" framework and then use non-standard technology and workflow.

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.

Gotcha. My next argument is going to be visual trough the design systems explained on the article. Hope that's clearer.

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.

Regarding "What began as elegant HTML, CSS, and JavaScript...": I don't know. Did you write websites 15-20 years ago?

You seem to have a fundamental misunderstanding of React, Next, etc. They don't stop you from using native CSS or HTML functionality.

Not technically, but they sure don't have to make it easy. Getting an element reference is clearly not the optimized-for use case. The docs even warn against it.

> Refs are an escape hatch. Manually manipulating another component’s DOM nodes can make your code fragile.

https://react.dev/learn/manipulating-the-dom-with-refs

Using HTML features doesn't have to mean manipulating another component's nodes.

But sometimes it does.

> 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.

And that’s different from the primary use case of refs

Indeed, and it's also the most practical way to use standard DOM operations from inside of react.

You nailed it. Content separated from the structure. As it should be.

The issue here is that the GP probably doesn't consider writing content to be related to developing the website.

Which is fair. It's one way of looking at it. Once, a really long time ago, I made a website (e-shop) where the content was written in an XML file, sliced and diced by XSLT via a little PHP script. My job was to write the (X)HTML for the layout and XSLT for data extraction - the content was something my client provided. If they provided the content in Markdown, I'd use markdown-to-html converter instead. Crucially, if I were provided with content in HTML, I'd also handle it (most likely not by directly pasting it into the page, though). I'm sure you can change the format in Nue trivially and write your posts in HTML if you want (right, @tipiirai?)