This is a bizarrely written article - as a frontend dev it left me wondering who the target audience is. Is it so-called "vibe coders"?
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.
This reminds me of the class (and classic) adage of inheritance, where you wanted a banana but you got a gorilla holding a banana standing on an island. If you want to compare frameworks, compare frameworks not your framework vs another framework and the whole ecosystem.
The author of this article and framework either doesn't have the slightest beginning of a clue how React works or is just being extremely dishonest. I'm all for alternative and new ideas, but this is not it and the way it is presented is just plain wrong.
Dishonest comparisons are their MO - if you look at the previous submissions for their software, they always show how much smaller their version is, but leave out 90% of the features of the version they compare it to.
People always notice this and bring it up, yet the author keeps doing it. This is not a single mistake, it's a pattern.
We have two ways, mix logic with html or mix display code in JS. For large projects React way works better hence its popularity. For hello world class of apps, 1st approach is more appealing hence a million replacement frameworks.
Hyper demonstrates that simplicity scales. It's easier to construct large-scale apps with simple units rather than cramming complexity together. It's not about the syntax (JS first vs HTML first), but rather how much you have that syntax and how easy it is to read/maintain.
Author here: This is a developer preview, ultimately replacing the current Nue JS reactive library. There is a FAQ section at the end of the article. Happy to answer any other questions here.
I'm confused about styling. You show that I can't put in inline styling (is it unfair to use inline styling in react, when you put it in in a CSS file if you liked?)
But, you then only give me an example of formatting a 'h2 in a p'. But, what if I want to highlight one row of one particular table?
Unfortunately looking sane and being a good model are different.
One of Reacts greatest features is you’re just using JS for the logic - loops and conditionals are type checked, autocompleted, and already universally understood.
Template based solutions have existed since forever, but if given the choice I’d never use them.
The examples are contrived & the comparison to React in the first place isn't in any way like-for-like (the first example is comparing ShadCN, an entirely different library, not just React).
React is a view state management library. Hyper is a DSL for a framework called Nue. They're not like-for-like tech. A better comparison would be something like Svelte which is a similar DSL (used with a framework called SvelteKit).
Fwiw JSX is also a minimal DSL used by React but if this article compared bare Hyper (without Nue) with bare JSX (without React), JSX would come out much much more minimal in the examples.
That's simple. It's so simple that it uses the word simple 12 times in that simple short text. That must be very simple. Simple as that! I like simple stuff.
This is yet another clickbaity title from the same developer. On the last thread, there were multiple instances of criticism that were dismissed or ignored.
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.
I've just come to the realization that the developer most likely inquired ChatGPT to write examples for "Modern React" implementations and just went with it.
And yet you claim that you have a "deep understanding" of how React works. Why did you ask an idiotic LLM then? Doing it yourself would have allowed you to be even more dishonest with your examples... :>
Vue is indeed similar, but Hyper is more minimal with fewer special characters and syntax patterns. The key difference is that Hyper strictly separates styling: no CSS-in-JS or class manipulation is allowed. This makes components truly reusable across different projects and environments.
You can't say you don't "allow CSS-in-JS" and then not allow class manipulation. These two are quite literally the only ways you can dynamically style DOM elements.
@isqueiros I certainly can. Tailwind evangelist like you should look closer to web standards. Especially CSS. The points you make are simply absurd: feels like you have only worked with React and never understood the DOM. Time to learn!
What is the advantage over Svelte (https://svelte.dev/)? Especially since Svelte is already established and has an ecosystem.
This is a bizarrely written article - as a frontend dev it left me wondering who the target audience is. Is it so-called "vibe coders"?
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.
This reminds me of the class (and classic) adage of inheritance, where you wanted a banana but you got a gorilla holding a banana standing on an island. If you want to compare frameworks, compare frameworks not your framework vs another framework and the whole ecosystem.
The author of this article and framework either doesn't have the slightest beginning of a clue how React works or is just being extremely dishonest. I'm all for alternative and new ideas, but this is not it and the way it is presented is just plain wrong.
Hard pass.
Dishonest comparisons are their MO - if you look at the previous submissions for their software, they always show how much smaller their version is, but leave out 90% of the features of the version they compare it to.
People always notice this and bring it up, yet the author keeps doing it. This is not a single mistake, it's a pattern.
The React example feels dishonest because it could be a lot simpler:
- 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.
> <tr :for="user of users">
I'm at a loss of words. Is this really seen as a good idea?
We have two ways, mix logic with html or mix display code in JS. For large projects React way works better hence its popularity. For hello world class of apps, 1st approach is more appealing hence a million replacement frameworks.
Hyper demonstrates that simplicity scales. It's easier to construct large-scale apps with simple units rather than cramming complexity together. It's not about the syntax (JS first vs HTML first), but rather how much you have that syntax and how easy it is to read/maintain.
Author here: This is a developer preview, ultimately replacing the current Nue JS reactive library. There is a FAQ section at the end of the article. Happy to answer any other questions here.
I'm confused about styling. You show that I can't put in inline styling (is it unfair to use inline styling in react, when you put it in in a CSS file if you liked?)
But, you then only give me an example of formatting a 'h2 in a p'. But, what if I want to highlight one row of one particular table?
You're doing amazing work - let me ask you, how's SSR support? renderToString()?
Thank you. Yes. SSR is supported. Look for the docs:
https://nuejs.org/hyper/
I'm not a frontend dev, but compared to React boilerplate it looks surprisingly... sane?
Unfortunately looking sane and being a good model are different.
One of Reacts greatest features is you’re just using JS for the logic - loops and conditionals are type checked, autocompleted, and already universally understood.
Template based solutions have existed since forever, but if given the choice I’d never use them.
It's both: having both "sane" syntax and simple mental model is the key.
Good thing is TS is sane syntax. Also the examples were written fairly biased.
The examples are contrived & the comparison to React in the first place isn't in any way like-for-like (the first example is comparing ShadCN, an entirely different library, not just React).
React is a view state management library. Hyper is a DSL for a framework called Nue. They're not like-for-like tech. A better comparison would be something like Svelte which is a similar DSL (used with a framework called SvelteKit).
Fwiw JSX is also a minimal DSL used by React but if this article compared bare Hyper (without Nue) with bare JSX (without React), JSX would come out much much more minimal in the examples.
That's simple. It's so simple that it uses the word simple 12 times in that simple short text. That must be very simple. Simple as that! I like simple stuff.
This is yet another clickbaity title from the same developer. On the last thread, there were multiple instances of criticism that were dismissed or ignored.
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.
> You made the choices to include these.
I did not. ShadCN data table requires these. Check their docs
> None of these things are inevitable in React.
Hence the "old shchool" example.
ps: I have a deep understanding how React works, even on how the actual codebase works.
> I did not. ShadCN data table requires these. Check their docs
You made the choice to include Shadcn.
> ps: I have a deep understanding how React works, even on how the actual codebase works.
I'm starting to doubt that.
I can see that simplicity appears as "stupid" for you
I've just come to the realization that the developer most likely inquired ChatGPT to write examples for "Modern React" implementations and just went with it.
Yes. I asked Claude to write the most idiomatic React to implement both the ShadCN and the old school React examples.
And yet you claim that you have a "deep understanding" of how React works. Why did you ask an idiotic LLM then? Doing it yourself would have allowed you to be even more dishonest with your examples... :>
https://nuejs.org/blog/introducing-hyper/simple-table.html
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.
Vue is indeed similar, but Hyper is more minimal with fewer special characters and syntax patterns. The key difference is that Hyper strictly separates styling: no CSS-in-JS or class manipulation is allowed. This makes components truly reusable across different projects and environments.
Well,
I'm waiting for more real world production examples and not just the todo-list hello world.
I like the simpler/cleaner approach of Nue. Now one of the big difference will be the component and theming provided.
I'm a long term vue/vuetify user and i can build powerful and sexy web app in a small amount of time and effort.
I will definetely compare this point.
That's said, you've done an incredible work with your Nue project. i keep a eye on it.
Sounds like no class manipulation will also make it impossible to do... front-end work?
Yes. If you are a keen Tailwind user and think "class names is the reason CSS doesn't scale" (as they say)
You can't say you don't "allow CSS-in-JS" and then not allow class manipulation. These two are quite literally the only ways you can dynamically style DOM elements.
@isqueiros I certainly can. Tailwind evangelist like you should look closer to web standards. Especially CSS. The points you make are simply absurd: feels like you have only worked with React and never understood the DOM. Time to learn!