Comment by Kaotique

Comment by Kaotique 20 hours ago

17 replies

View on Hacker News

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 18 hours ago

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

Reply View 5 replies
  • robertoandred 14 hours ago

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

    Reply View 4 replies
    • lelanthran 14 hours ago

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

      Reply View 3 replies
      • robertoandred 13 hours ago

        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}
    />
  );
        };
        Reply View 0 replies
      • lolinder 13 hours ago

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

        Reply View 0 replies
ozim 18 hours ago

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.

Reply View 4 replies
  • spankalee 16 hours ago

    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.

    Reply View 2 replies
    • ozim 15 hours ago

      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.

      Reply View 0 replies
    • zeroq 4 hours ago

      I partially agree.

      The "separation of concerns" is often misunderstood, and historically people were treating html, css and js like they were completely separate beings, which is of course a recipe for disaster [0].

      However, what I'd like to see is separation between logic and presentation. In React world people used to call them dumb and smart components. Then you can use stuff like storybook to gauge your layout before applying "business logic" to the application. On top of that you have an easy way to test your "smart" components.

      [0] like that time when I saw an org that decided to be "cloud agnostic" and people started pushing their own databases and http servers to AWS. :)

      Reply View 0 replies
  • ozim 16 hours ago

    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.

    Reply View 0 replies
turnsout 17 hours ago

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.

Reply View 0 replies
tipiirai 16 hours ago

> 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

Reply View 4 replies
  • lolinder 13 hours ago

    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.

    Reply View 0 replies
  • internetter 16 hours 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.

    Reply View 2 replies
    • tipiirai 16 hours 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.

      Reply View 1 reply
      • internetter 15 hours ago

        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.

        Reply View 0 replies