←back to thread

174 points tipiirai | 1 comments | | HN request time: 0s | source
Show context
Kaotique ◴[] No.42736637[source]
It is interesting, but I really dislike the way it tries to bash every other tech in the blog post, on the homepage and in the docs itself. The tone is very confident, but it will put you open to a lot of scrutiny.

Instead it could really use a lot more explanation on how it works. If you make comparisons make sure they are fair. The image "JavaScript mixed together" and "Strict separation of concerns" is just comparing apples with oranges. Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css. I don't believe that it does the same thing.

Some of the claims are strange. It praises standard HTML but apparently you have to use some custom Markdown syntax to write it. How does that add up? And on top of that it also introduces new syntax for loops and variables.

This could all work perfectly fine. But my suggestion would be to talk more about how it works and what are the advantages and less trying to bring down competitors. It could use less grand claims and focus more on what it really does.

replies(5): >>42737254 #>>42737462 #>>42737988 #>>42738672 #>>42754583 #
ozim ◴[] No.42737462[source]
Yeah there is a lot of idealism in the project - problem is reality doesn’t care about your idea of separation of concerns and most likely your web applications will not benefit from it.

What I mean React and other frameworks went with mixing concerns because of reasons that were practical - for example realization that usually one dev implements HTML and JS code in one task, not like article comes up with designers and devs. In reality lots of designers don’t live in agile sprints and the same repositories as devs there is huge impedance mismatch.

replies(2): >>42738548 #>>42738872 #
spankalee ◴[] No.42738872[source]
The "separation of concerns" point is very overblown, IMO. It seems to have become a slogan repeated without considering what the goal is, and just completely dismissing components as another valid way of organizing code.

Components have won for a reason - for any given web-based UI component to work it needs to render HTML, to style that HTML, and logic for rendering and behavior. So HTML, CSS, and JS.

It only makes sense to colocate those things so that they're easier to build, understand, distribute, and use as a unit. Often times they're not even separable as the HTML depends on state and logic, etc.

And the weird thing is that any other UI platform has components that combine rendering, styles, and logic together and no-one bats an eye because it would be very odd and cumbersome to do it any other way, but on the web some people think components are bad. And they tend to provide no realistic mechanism for reuse except to use an external system.

replies(2): >>42739865 #>>42745625 #
ozim ◴[] No.42739865[source]
Separation of concerns is valid if you look at website as a document.

If you look at website as an application components are valid approach.

I don’t need a framework to make documents - I need framework to make web applications that is why components won so I agree.

replies(1): >>42749683 #
1. 8n4vidtmkvmk ◴[] No.42749683[source]
> I don’t need a framework to make documents - I need framework to make web applications that is why components won so I agree.

I just realized how little "content" my app has. So Nue's focus on these psuedo-Markdown documents is extra worthless. If 99% of the content is coming from the database, what would even go in these docs?

It's the same at the big tech company I work at. Yes we have technical writers and UX and all that, but all the bits and bobbles of text are like 1-line long, so they go into some funky template with all the random strings and then some tooling picks them up and the translators use a custom UI to translate them. None of these folks are working directly in the codebase, nor do I think they should.