Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh.

I understand the logic, but there are several issues I can think of.

1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.

2 - as react was always celebrated as an unopinionated framework, RSC creates a deep coupling between 2 layers which were classically very far apart.

Here are a list of things that would rather have react provide:

- advanced form functionality that binds to model, and supports validation

- i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed

- signals, for proper reactive state

- better templating ability for control flows

- native animation library

All of these things are important so I wouldn’t have to learn each new project’s permutation of the libraries de jour.





> React always hailed itself as the “just JS framework”,

I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming.

> but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.

This is wild. Yes you can. You can write regular JS in components. I can go build a component right now that uses JS (either with or without hooks). You're conflating the rules of hooks with the ability to use Javascript. Yes, there are rules. No, that doesn't mean you can no longer can write JS.

> i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed

Tradeoffs. Now each update needs to be rebuilt and redeployed. I don't have that problem in React.

> better templating ability for control flows

Better templating? React uses JSX. Are you saying there exists a better way to control flows than if/else?

> signals, for proper reactive state

This has been debated ad-nauseum in the React community and everything has a trade-off. I wish people would stop saying this as if it's categorically correct. React is UI is a function of state. Singlars would totally break the current mental model of React. Data flows down. This change would come with tradeoffs.


I’ve heard, especially during the first few years when react was introduced, that you don’t need templating, compiler, or anything special to write react, “it’s just JS”.

Of course you CAN write anything you want inside a component, but then it breaks, or has awful performance. To write components the proper way you can’t use any control flows with state management, you need to keep remembering which are the correct dependencies to recreate state, it makes components 20% BL and 80% react logic.

You can’t use if-else in JSX, since only expressions are allowed. So you need to create nested ternaries, which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.

And regarding signals, preact is using it and it doesn’t seem to break anything there.

Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.


> that you don’t need templating, compiler, or anything special to write react, “it’s just JS”

This is still true. I don't currently use any of those things. And the existance of a compiler does imply you can't write Javascript. Totally different concepts. Also, pretty sure they had compiler plans for like years now.

> but then it breaks, or has awful performance.

You're gonna have to be more specific. I could repeat that sentence for every programming language/library on the planet and without specifics it would make sense.

> You can’t use if-else in JSX,

I don't need to use if-else in JSX to control flow. I can write if(condition) return html;

> which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.

See the sentence I just wrote before this. I can use if/else to control flow and return early without templating. How is that not ideal?

> And regarding signals, preact is using it and it doesn’t seem to break anything there.

It's not about literlaly "breaking" something. They could implement htem if they wanted to. It's about breaking the mental model.

In React, data flows down. That's a constraint, but not always a bad one. I know exactly where to look for data (up). With signals, that's throw out the window. And now, it's not just about what the component accepts via props/context (which again, is down) it now needs to turn itself on it's head.

I used Angular for years before React and I do not miss having things talking to each other throw multiple lateral levels.

> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state.

> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.

This is incredibly misleading (and wrong). Templates don't compose. And React is quite literlaly the king of composition.

It's starting to feel like you've never actually used React, but instead are basing your opinions on what you see other people say (who have also not used React).


Do you have a moment to talk about our Lord and Savior VueJS?



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: