Comment by tipiirai

Comment by tipiirai 2 days ago

20 replies

View on Hacker News

Author here: this is Nue's new, more natural direction. Our previous focus on design engineers and CSS design systems was accurate, but missed the most important point: the web platform itself has evolved to eliminate the need for most framework abstractions. What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page.

This is a long term, ambitious project to strip away these artificial layers and return web development to its core strengths. Instead of fighting web standards, we're taking them to their absolute peak.

Happy to hear your feedback.

mind-blight a day 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.

Reply View 1 reply
  • tipiirai a day ago

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

    Reply View 0 replies
bitpush a day 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?

Reply View 5 replies
  • tipiirai a day ago

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

    Reply View 4 replies
    • bitpush a day ago

      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.

      Reply View 3 replies
      • tipiirai a day 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.

        Reply View 2 replies
buster a day ago

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

Reply View 0 replies
robertoandred 15 hours ago

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

Reply View 5 replies
  • recursive 13 hours 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

    Reply View 4 replies
    • robertoandred 11 hours ago

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

      Reply View 3 replies
assimpleaspossi a day ago

Repeating this here for emphasis:

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

Reply View 3 replies
  • mickael-kerjean a day 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

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

    Reply View 2 replies
    • bitpush a day 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/contribu...

      ----

      What works for one disciplined (and talented) developer such as you might not work at scale.

      Reply View 1 reply
      • mickael-kerjean a day 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 ....
        Reply View 0 replies
andrewmcwatters 10 hours 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/

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

Reply View 0 replies