by ZephyrBlu on 5/6/25, 7:14 AM with 38 comments
by cryptos on 5/6/25, 8:40 AM
by lucideer on 5/6/25, 8:40 AM
The language throughout is "dumbed down" as if written for a recruiter or non-technical founder who's only heard of "react" as a buzzword:
> Hyper is the language (think React, but simpler)
React isn't a language. JSX is a language, but still doesn't compare well to a full DSL like Hyper. Svelte would be a more sensible comparison here (but given your chosen metrics I suspect it wouldn't make Hyper look as good).
The title seems deliberately misleading - I see nothing about performance in the piece. You seem to be using the word "perform" to mean "hits some arbitrary metrics we selected", like cloc of your own app (no mention of cloc of the node_modules folder).
The comparisons are also nonsense. The first React "modern version" is comparing Hyper to ShadCN, not React itself. The only extra "boilerplate" is the import loading in ShadCN as a dependency.
Seriously what is going on here? Who is this for?
Hyper may be a great project but this piece is so devoid of content or analyses that I really can't tell.
by titaphraz on 5/6/25, 8:46 AM
by iamsaitam on 5/6/25, 8:33 AM
by lucsky on 5/6/25, 8:36 AM
Hard pass.
by janaagaard on 5/6/25, 9:55 AM
- All the imports are only needed because a UI library was used. This is not necessary.
- It also looks like 'User' is imported, but not used anywhere.
- The curly braces and the return statement can be left out.
- React.FC<> is unnecessary, you can just specify the type after {users} or, at least, simplify React.FC to FC.
by kookamamie on 5/6/25, 8:31 AM
I'm at a loss of words. Is this really seen as a good idea?
by tipiirai on 5/6/25, 7:40 AM
by agluszak on 5/6/25, 8:21 AM
by isqueiros on 5/6/25, 8:30 AM
Reading through the article, there are many places in which the information is incomplete, wrong and downright dishonest, imo.
> Through Radix UI, Tanstack Table, and TypeScript interfaces. This results in approximately 170 lines of code, versus 40 lines in Hyper.
You made the choices to include these. TypeScript boilerplate is inevitable in good quality code. Tanstack and Radix UI add an immense number of features that your plain table just doesn't have. You're also omitting the fact that you import all components automatically with your IDE.
> ShadCN table requires six different transpilers: ESBuild, JSX Transform, Rollup, TypeScript, Tailwind, and PostCSS.
Exactly two of these are actual "transpilers" (tsc and esbuild), and only one is used in the compilation step. The JSX transform is performed by esbuild, rollup is a bundler, TypeScript is only used during development, tailwind is not a transpiler at all and PostCSS only transforms CSS for greater compatibility.
> Modern React components aren't reusable across projects with varying design requirements because the design is hardcoded in the component.
None of these things are inevitable in React. It's a really bizarre example because this only seems to point to a specific limitation/design flaw on Shadcn specifically.
> By contrast, Hyper colocates your typography concerns into a single CSS file, acting as the single source of truth for your h2 an p element styling: [global styling]
If your argument is that components are not reusable across projects, then it's really funny that you're applying your styles globally. What if I don't want my paragraphs to look like that? Then I have to manually override it, duplicating CSS code. This is also legitimately just possible with "Modern React", you can just add CSS and use it however you'd like.
> cryptic utility classes like dark:bg-lime-400/10 size-[max(100%,2.75rem)]—is systematically eliminated.
You mean you're not using Tailwind. Which is possible in React.
> Nue is the "framework" (think Next.js + Astro, but simpler)
Next.js and Astro are both frameworks which are totally incompatible with one another.
This whole article seems to stem from a fundamental misunderstanding of (or a lack of desire to understand) what React is or does, and how to fix it. It's genuinely impressive that you were able to build a framework from scratch instead of just... googling your issues? Some of these were solved ages ago and don't require a whole new stack to be created.
I also believe there is a real argument to be made against React everywhere, but that is beyond the scope of this comment. What I can say is that this comparison would be a lot better if it were against Astro or SvelteKit, which will solve most of the issues you have (boilerplate and bundle size), while also providing a much better supported experience.
by QuiCasseRien on 5/6/25, 8:29 AM
With vuejs, the template code is very identical to your hyper version.
React is full bullshit mixing (JSX) code.
So what's about comparing to a cleaner code and separation like the vuejs.