Show HN: Hyper – Standards-first React alternative

What's up with the code comparisons under "Complex components"? Why does the React version include so much more stuff than the Nue version? Does Nue automatically inject all those features in your app with just a "card" class on the top level element? The React version has full styling, icons, sortable columns, etc.

> This is an oldschool example using external CSS, which is no longer the "idiomatic" way to build React compomnents:

Where does this claim come from?

classNames and an external CSS file is literally the first suggested way to do styling according to the docs:

https://react.dev/learn#adding-styles

I don't doubt that tailwind and shadcn and such are popular, but they are not even mentioned in the react docs, so I don't think you can call it the 'idiomatic' way

The Angular/Vue approach of sprinkling application logic in HTML attributes demos really well - wow, it's like magic! - but it can only end one of two ways: either it's too simple to keep up with real-world requirements so you end up implementing everything in JS anyway, or it tries to be everything to everyone and you end up with hideously convoluted and slow DSLs like the abomination that is ngFor.

Personally I think attacking the problem from the other direction and making JS more fluent at generating markup is the much more practical approach and that's why JSX won.

Hyper syntax:

    <tr :for="user of users">
        <td>${ user.name  }</td>
        <td>${ user.email }</td>
        <td>${ user.age   }</td>
    </tr>

EJS syntax:

    <% for (user of users) { %>
        <tr>
            <td><%= user.name  %></td>
            <td><%= user.email %></td>
            <td><%= user.age   %></td>
        </tr>
    <% } %>

I prefer EJS, because all you need to know is "<% begins JS" and "%> ends JS". Everything else is just plain HTML and JS.

The EJS website: https://ejs.co

I love utopian projects like this. And I’ll say there’s lots that is appealing about the sample code, not least its terseness, a factor that is going to really matter in the next era of agentic coding.

Unfortunately, we don’t live in paradise - we need to consider say a ratio score, of how much complexity is required, in the platonic sense, to deliver React’s core feature promises, vs how much complexity modern react actually demands.

Whenever I code react I’m certain that number is at least 3:1, and I long for a simpler system.

But I think I am probably wrong - I think for the feature surface area react covers, it’s close-ish to the same complexity level as utopiareact(tm). React does a lot. If that’s true then a framework could be much simpler, but it would then necessarily be delivering fewer features.

Upshot: the safest path to keeping this thing simple seems to me to be extremely wise about what it promises to do; picking and choosing from a “full” feature stack to optimize value-for-complexity.

I guess as I write this is a long winded way of saying that react is at a point in the feature-complexity Pareto curve. Arguably pretty high on the feature axis. It’s worth deciding if you want to live somewhere else on the curve (big simplicity gains in exchange for features) or try and shift the curve in.

How do you virtualize rendering of a table with 100,000 items with Hyper?

I wish open-source projects checked to see if other projects share the same name.

Especially since there are packages in NPM already about hyper.

https://hyper.is/ has been around for a while and is kind of big

I admire the goal of concise and expressive code.

Here is the basic table example presented in the post recast in https://harcstack.org functional HTML (well this is the entire website)...

  sub SITE is export {
    site
      index
        main
          table :thead[<Name Email Age>,],
            do {[.name, .email, .age]} for @users
  }

Note to self - never, ever do "like-for-like" comparisons with code.

To be fair HARC Stack doesn't have a table component with sortable, filterable cols yet - but it is HTMX centric so should be pretty fun to spin one up.

And never mention that this is raku code.

How would you say that this solves the similar problems as React Server Components?

E.g. yesterday's discussion - https://news.ycombinator.com/item?id=43929054

Basically, how do you remove the gap (network implementation) between back-end and front-end, so that you don't need to think about the difference. You define the components in same place, and can add dynamic features for client-side when you need them, but the rest of the code can be even compiled to static in a seamingless way.

Without solving this, I wouldn't really use a new framework that doesn't challenge the similar problem.

Really like what I'm seeing so far. It looks a lot like Sprae: https://github.com/dy/sprae one of my favorite things that no one seems to be paying attention to :) I use it on live-templates, which uses Sprae to connect a template to stateful backend in Elixir over Phoenix Channels: https://github.com/launchscout/live-templates

So many front end frameworks that they can't even all have unique names https://hyperdom.org/

See https://news.ycombinator.com/item?id=43543241 — Announcement post for Nue

Is this the next step for Riot.js? Or a new direction? I've always been interested in riot's approach and wonder about its influences here.

Please, not another `strings` programming language

`‹tr : for="user of users">`

If I'm already writing against web standards, why would I want to use Hyper? I'd just be hitching my work against something that had nearly no risk, but just enough dependency risk to not be worth it.

At my business, we've moved from using React for client work to completely eschewing it in favor of web components. In fact, we basically don't use any major frameworks anymore. There's Express on the backend, and that's about it. I'd like to swap it out for more Go, but that's digressing.

I suspect that now that the front-end is a bit more stable than it has been in previous years, the remaining friction will increasingly become the remaining distraction for many developers.

I don't want React changing minutiae on my team for pointless or ideologically pure reasons. I just don't care. The changes bring no tangible improvements. And we also use basically no tooling.

Really mature software projects want as few dependencies as possible to minimize unnecessary friction. Your audience for this is a group of developers who are already pointed in this direction.

I’m starting to feel like Tommy Lee Jones in No Country for Old Men.

There are dozens of "better React" web frameworks, so it is impossible to get any traction with that value proposition because any attempt at building a new ecosystem will be diluted. That ship has sailed. New frameworks should solve problems that are very difficult in existing frameworks. https://qwik.dev/ is a good example.

I’m really not a fan of the comparisons between the react code and the nue code - it comes off as disingenuous.

Just as an example that catches my eye - the complex table react example includes sorting icons, but the nue example doesn’t. If you remove features then of course there’s going to be less lines of code.

Feels like it’s strawmanning rather than ironmanning.

This got posted (and flagged) the other day - https://news.ycombinator.com/item?id=43902525 - which was somehow before the published at date on the article.