←back to thread

174 points tipiirai | 3 comments | | HN request time: 0.689s | source
Show context
bitpush ◴[] No.42732454[source]
Lots of big claims, including bashing React and this seems to be a framework to build static sites, like blog posts with little to no reactivity?

Also, kinda silly to "appeal to authority" by invoking Dieter Rams. I understand that the author was inspired by Rams work, but this is akin to saying "My new framework is Iron Maiden" because I happen to really like maiden.

replies(5): >>42732498 #>>42732757 #>>42733228 #>>42735021 #>>42735619 #
bitpush ◴[] No.42732498[source]
(replying to self)

I just checked out the demo site, and now I'm question their design choices as well.

https://simple-blog.nuejs.org/

Nue claims to be minimalist and an outright rejection of everything that is bloated. And yet, this simple page has an obnoxious blur. I get that it kinda looks nice on first load, but click around - the blur happens on each navigation.

This screams form over function if anything.

replies(6): >>42732576 #>>42733010 #>>42733294 #>>42734717 #>>42736180 #>>42736398 #
bitpush ◴[] No.42732576[source]
(replying to self)

I looked at the code, and I'm finding it very hard to take them seriously.

https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...

This almost feels like someone taking on a challenge to create a toy framework themselves.

--

While we're at it, since the author wanted to poo-poo tailwind. Com'on https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...

replies(3): >>42732693 #>>42734828 #>>42745733 #
mind-blight ◴[] No.42732693[source]
Yeah, I was expecting something bigger and more explicit when he went after tailwind. Instead, the author just re-hashed older design patterns (MVC and semantic html decorations from css) without providing context add to when and why you would prefer the older patterns over newer ones. I've been building since the jQuery days, and I totally agree that there are a lot of challenges that people tend to forget from that time. Decoupling html from css just didn't provide much value, but it did create a lot of bike shedding.

I really like how htmx has handled explaining their architectural trade offs. They're very clear about the kind of problem they're solving, how they're solving it, and when/why their solution is better.

This post just has "get off my lawn" vibes without a ton of substance

replies(1): >>42734508 #
tipiirai ◴[] No.42734508[source]
The _why_ is extensively documented. See:

https://nuejs.org/docs/

Also FAQ:

https://nuejs.org/docs/faq.html

replies(1): >>42734744 #
mind-blight ◴[] No.42734744[source]
I appreciate the links. I think this quote from the FAQ captures the disconnect for me:

``` This isn't about rejecting modern development - it's about recognizing that browsers now offer sophisticated capabilities that eliminate the need for most framework abstractions. ```

The problem I have is that I agree with the initial premise, but I disagree with the conclusion. Framework architectures mostly solve different problems than modern web standards.

If you want to go after specifics like 1) just use browser forms and stop re implementing the wheel, 2) you probably don't need a massive state validation library, or 3) stop building CSS features in JS, then I'm 100% on board. But that's not a problem with CSS-in-JS, JSX + render library, components, or many of the other targets you go after.

Things like tailwind (for example) solve fundamentally different problems, and those have more to do with team standardization, avoiding bike shedding, and rapid prototyping. For styling in particular, I don't want to return to the days of crawling through thousands of lines of CSS - edited over years by multiple teams - to find all of the places where different styles impact the specific html component I'm looking at. That's tightly coupled code with loosely defined locations. JSX components just decay less quickly due to encapsulation.

I've also just never seen the separation of CSS and HTML actually provide practical value. It's always been "check out what's possible!" projects like CSS zen garden. Super cool, but that decoupling just doesn't do much in practice.

Like I said, I think there are some interesting ideas here, but I just don't think it's clear why this is a better approach for general web application development (which is the argument you appear to be making).

I'm super curious to see if you prove me wrong, so I'll definitely keep an eye out :). I just don't yet see how the proposed solution solves the identified problems without pulling in a bunch of pain points that were already solved a while ago.

replies(2): >>42734953 #>>42735522 #
1. rglullis ◴[] No.42735522[source]
> I've also just never seen the separation of CSS and HTML actually provide practical value.

I would pay really good money to have a library of web components that implemented only the document structure using semantic HTML and the Javascript interactivity, and kept all the styling on a separate CSS file. Something like headless-ui, but without any of the utility classes.

Then we could move on from these template marketplaces (where each dev has to reimplement their own widgets for each different javascript framework), and we would have a simpler marketplace of "Web Component Themes".

replies(1): >>42740991 #
2. mind-blight ◴[] No.42740991[source]
You should check out Radix UI (https://www.radix-ui.com/). Same idea as headless ui, but it doesn't assume that you will use Tailwind. I _think_ they add css classes to all of their components to allow you to choose any styling method you want, but I'm usually working with ShadCN (which is one level up and uses tailwind).

Though, I'll say that I agree with OP that a lot of functionality already exists within HTML and browsers.

replies(1): >>42747562 #
3. rglullis ◴[] No.42747562[source]
But Radix UI is still based on React. Maybe someone could take a shot at porting them to "pure" Web Components.