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!
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.
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.
It sounds like you're arguing that "React devs don't know how to manage complexity" which is a completely separate issue than React itself.
- The post makes some outlandish, to-good-to-be-true claims.
- It traction because A: it mentions React and B: who doesn’t sometimes wish development could be simpler.
- Readers call out the claims for being misleading or outright lies.
- The author deflects with “I could easily add that”, “you don’t need that”, or “keyed lists are unnecessary”[^1].
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.
`‹tr : for="user of users">`
- Original HTML attribute names, `class` instead of `className`, `for` instead of `htmlFor`
- Let expressions and components return multiple elements without the need for `Fragment`.
Could make a JSX 2.0 which would be much closer to actual HTML.
<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
I know it from Elixir [0] and strongly dislike it there, I was under the assumption in comes from Ruby [1] since so much of Elixir is Ruby-inspired, is this JS version the original one?
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 point is that React doesn't impose any of that and even suggests the "classic" CSS approach in the official docs, so I don't think you can use it as point of criticism of React, the framework, which you seem to be doing since you are drawing a comparison between React and your own framework.
The "ecosystem", which certainly does it's own thing, doesn't have anything to do with that, especially since I'm guessing Nue does not have an "ecosystem" at this point (that's not an insult!) so the comparison seems a bit pointless?
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.
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.
But there is much more to like. In fact, while a scripting escape hatch is there, this microlibrary asks you to touch JS as little as possible.
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.
Especially since there are packages in NPM already about hyper.
https://hyper.is/ has been around for a while and is kind of big
jitl•7h ago
tipiirai•7h ago
madeofpalk•6h ago
Where does the 'must' come from? A react component will trivially handle 200k records with list virtualisation with just javascript
tipiirai•6h ago
madeofpalk•6h ago
This seems like a pretty deep flaw. It would be okay to have poor performance, but flat out crashing seems bad.
jitl•6h ago
I just tried making an array w/ 1 million items in it in my browser console `Array.from({ length: 1_000_000 }, () => ({ id: ++nextId, data: Math.random() }))` without issue. Virtualization is just simple arithmetic to select the firstRender and lastRender indexes in the array. I don't think you need WASM for this.
__jonas•5h ago
https://bvaughn.github.io/react-virtualized/#/components/Lis...
This example seems to be able to do 200k+ rows without any problems at all. For me it's smooth up to 10,000,000 even with dynamic row heights. Is there something I'm missing?
brylie•7h ago
tipiirai•7h ago
[1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-b...
CafeRacer•6h ago
On our app we render large datasets (e.g. 40-50k records) and provide filtering/searching with rxjs.
Search even uses a levenshtein distance and the entire collection is sorted based on the similarity score.
Works like a charm.