by tipiirai on 5/9/25, 1:59 PM with 85 comments
1. Standards first: User interfaces should be assembled with HTML, styled with CSS, and enhanced with JavaScript.
2. Less abstractions: UI composition should be easy and require as few idioms and abstractions as possible, both on client and server.
3. Design Systems: Design should be a separate subsystem, easily accessible for developers who care about and understand design.
4. Scalability: Complex UIs should retain simplicity as the application grows.
Eager to hear your thoughts!
by rustc on 5/9/25, 2:59 PM
by __jonas on 5/9/25, 3:31 PM
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
by vessenes on 5/9/25, 2:29 PM
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.
by faefox on 5/9/25, 4:04 PM
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.
by mg on 5/9/25, 3:27 PM
<tr :for="user of users">
<td>${ user.name }</td>
<td>${ user.email }</td>
<td>${ user.age }</td>
</tr>
<% for (user of users) { %>
<tr>
<td><%= user.name %></td>
<td><%= user.email %></td>
<td><%= user.age %></td>
</tr>
<% } %>
The EJS website: https://ejs.co
by andrewmcwatters on 5/9/25, 3:03 PM
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.
by jitl on 5/9/25, 2:17 PM
by apricot13 on 5/9/25, 11:53 PM
I do realise your using the term standards to refer to web standards but inclusive design should be a core part of any standard so I feel it should be highlighted more somewhere!
by librasteve on 5/9/25, 7:05 PM
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
}
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.
by nicce on 5/9/25, 2:33 PM
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.
by curtisblaine on 5/10/25, 6:05 AM
The reality is, if you rendered a simple html table in modern (functional components) React, the loc count would have been the same as hyper. You know that, so you decided to use a ShadCN component just to inflate the code.
by slenk on 5/9/25, 8:48 PM
Especially since there are packages in NPM already about hyper.
https://hyper.is/ has been around for a while and is kind of big
by superchris on 5/9/25, 2:39 PM
by lern_too_spel on 5/9/25, 3:36 PM
by mock-possum on 5/9/25, 3:33 PM
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.
by drcongo on 5/9/25, 2:19 PM
by streptomycin on 5/9/25, 5:00 PM
by internetter on 5/9/25, 3:10 PM
by dleeftink on 5/9/25, 3:27 PM
by ohcmon on 5/9/25, 3:17 PM
`‹tr : for="user of users">`
by bandoti on 5/9/25, 3:41 PM
by rafram on 5/9/25, 11:32 PM