Introducing Hyper — Crush React on every metric (Developer Preview)

[tipiirai]

Today I'm releasing Hyper: a simple markup language for building user interfaces. It enables developers (and AI models) to generate complex UIs with amazingly clean syntax. It aims to make frontend development an enjoyable experience.

Read the announcement

[m4rrc0]

Why not use Svelte (or another compact markup)?

-> Genuine interest to understand the limitations of these libraries in your opinion!

[tipiirai]

Main reasons to build this library (vs Svelte):

1. I want the syntax to be as close to HTML as possible and as little custom idioms as possible (like Runes)
2. I want strict separation of markup and styling to delegate design decisions to CSS (no Tailwind, no CSS-in-JS)
3. I want a vanilla compile() method that works on client and server. No complex Bundler stack needed

[m4rrc0]

Thanks! I guess you were expecting this question. 😄

I feel the need to respond and share my experience and impressions but I want to dispel any doubt upfront! I think your approach with nue is a breath of fresh air. I am deeply interested in your work and I am eager to see everything you are cooking. So I don't want this discussion to carry any form of discouragement for anyone. I really just want this tech to be the best it can be!

I am really on board with the 3 points you mention but Svelte is largely avoiding these traps I think.

2. I want strict separation of markup and styling to delegate design decisions to CSS (no Tailwind, no CSS-in-JS)

AFAIK, Svelte does not advocate for Tailwind or CSS-in-JS. You can pretty much work the same way you work with simple HTML. You have the option to work with scoped styles and you can decide what do do with them when you compile. Maybe you want to forbid scoped styles...? Does it justify rewriting a whole new markup and library? Maybe yes... Or maybe there is more to it...

3. I want a vanilla compile() method that works on client and server. No complex Bundler stack needed

If I remember correctly (I played with it a while back), Svelte requires no bundler and ships with a compiler. I don't remember if it works on the client... I remember I managed to have both the MPA with "island architecture" and SPA mode working in parallel on a page per page basis (which I was pumped about 😄).

1. I want the syntax to be as close to HTML as possible and as little custom idioms as possible (like Runes)

I kept the most controversial topic for the end... Runes are controversial... I am not following Svelte closely enough to have the full picture but I have read enough about them to know the Svelte team thought real hard before deciding to introduce them.
My General feeling is that many projects start with the intention of simplifying something but as time passes, maintainers realize that they need to address this problem and add that feature... Which leads to... Runes... 😜

As a conclusion... I mentioned Svelte because (1) the markup reminded me of it a little and (2) the original motivation to create Svelte was really similar to your own with Hyper I think. So maybe there are bridges to build or inspiration to take on both sides.

[tipiirai]

Thanks! Happy to read thoughtful and positive feedback. For me point the second point is the most crucial. Decoupled design system is not just an idiom or best practice in the Nue ecosystem. It's a strict rule and Hyper takes this further than Nue JS. On the next version I'm going to implement a strict flag (for production) that limits the amount of class names and throws an error with special characters in the class name. Currently it just gives a warning.

[m4rrc0]

Hahaha. I love it!

If Hyper becomes popular, you'll need to make this the headline in the docs or be prepared with an automatic response to everyone asking about why they can't use the classes they want! 🤣

[tipiirai]

haha. I can imagine this.The plan is to build great starter templates to answer that concern

[JensRoland]

Hi Tero! Great article as always!

I mentioned Nue/Hyper to a far more SPA-savvy frontend buddy of mine, and he was intrigued, but also concerned that this could face a similar challenge to what the original React did, namely (I am paraphrasing) that the simplicity of the original React was betrayed by the complexity of state management.

My eyes glazed over a bit at that point, but he mentioned 'god objects', prop drilling, coupling of components and different ways of sharing state between components. He even mentioned that the original React paired well with Backbone for this?

I am not sure how Nue solves/plans to solve the state management puzzle (as a single shared/nested object in the Router? https://nuejs.org/docs/app-router.html), but I get the impression that this may be the most challenging (and contentious) part of winning React devs over. Both because it's hard, but also because there are many different camps and a ton of scar tissue there. Whatever state management solution Nue offers, maybe be a bit gentle in marketing it, since the React community has seen lofty promises of a Better Way(tm) again and again, only to find themselves in a different world of pain.