8 ms·

I see people complaining a lot about React, why is it? What are the alternatives? PS: I'm not a frontend engineer but I find this topic interesting. Thanks!

bandrami 2y ago
Using a scripting or templating language on the server to form and send HTML and CSS to the client as $DEITY intended
- Muromec 2y ago
  Django is still there and is still better than Phoenix by the way. I didn't really touch it in about 10 years, but ... nothing changed. It's amazing!
  - doodlesdev 2y ago
    > and is still better than Phoenix by the way. What aspects of Django do you think still stand out compared to Phoenix? It seems like a very solid framework, specially with the recent release of Phoenix LiveView 1.0, which seems like a pretty solid approach to frontend. For context, I’ve worked with Django before but didn’t particularly enjoy the experience—not because of the framework itself (its documentation, ORM, and admin tooling are excellent) but because I’m not a fan of Python, particularly its packaging ecosystem and approach to async, which I find lacking. I haven’t used Phoenix or Elixir before, so I’m curious to hear from someone who has experience with both.
    - Muromec 2y ago
      Django is really thought out and polished in terms of devx. Take ORM for example. You write a model and you get out of the box: - migrations to create the model and to apply schema changes; - form validation for crud; - admin with permissions to edit it; - helpers to get model by id or throw 404. Phoenix kinda is in the same market, but you write your migrations yourself, admin panel is a package somebody slapped on top, etc. It’s not that Phoenix isn’t usable, but getting on that level takes time and effort
- vundercind 2y ago
  Unironically this. The fastest “web apps” I’ve seen that weren’t absolutely required to be javascript-heavy to operate by virtue of what they do, have been mostly or entirely rendered server-side and have just sent entire pages for most interactions. Still performed better than 99% of webapps.
nailer 2y ago
Svelte. Rather than const [name, setName] = useState('blastonico') ... setName('nailer') You do: let name = 'blastonico' ... name = 'nailer' Also a single .svelte file includes everything you need for a component (HTML, JS, CSS), so it's easier to manage.
- efields 2y ago
  Vue is also nice.
  - nailer 2y ago
    Yep. Svelte's SFC was inspired by Vue. If you like Vue you'll like Svelte which is familiar but adds a compiler for simpler syntax.
    - spoiler 2y ago
      I honestly don't feel like Svelte makes things simpler. And I'm saying this as a "fan" of Svelte and think its compiler is very cool. It just feels a bit weird that there's special .svelte specific rules. Runes kinda fix this, but it's still a bit weird. I think Solid or Vue are much simpler (but only did small projects in them) and have a simpler mental model. I've not yet used Preact, but heard good things about it
      - sensanaty 2y ago
        Yeah I like Svelte a lot, but I can't help but feel Rich feels the need to be different, and not necessarily always in a good way. SvelteKit routing[1] is an example that pops out at me as being genuinely bafflingly bad to the point of comedy. [1] https://svelte.dev/docs/kit/routing https://svelte.dev/docs/kit/routing
- ptrwis 2y ago
  let name = $state('blastonico')
sensanaty 2y ago
Vue is infinitely better in pretty much every way other than available libraries (specifically UI libraries and some stuff like Motion, though that's soon-to-be framework independent), but to be honest I've never felt that problem in my 6 years working with both, and especially in more recent times pretty much everything is framework agnostic anyways, even the big popular ones like TanStack Query. The one real edge I'll give React is much better Typescript support due to tsx essentially being a superlanguage of TS. Vue's composables are very good, but it falls apart a bit in actual template usage. Tooling is also better, but that's also because it's simply used much more so has had more investment into making the tooling good compared to Volar for Vue. But in my opinion everything else surrounding Vue makes it superior. Signals are a better state management pattern, there aren't all the insane footguns that React comes with, performance is better out-of-the-box and is practically impossible to fuck up compared to React where it's hilariously easy to make even the simplest of apps be performance monstrosities, the documentation is (IMO, I find React's docs (yes I've seen the new ones) terrible) best-in-class, the gilded libraries like Pinia, Vue Router, VueUse are far superior to anything in the React ecosystem... I could keep going, but having worked with both more or less equally, I'd choose Vue 10/10 times over React, no questions asked. I can throw a junior at the codebase and be 100% confident they'll make something that's more-or-less idiomatic Vue code, even with the Composition API which is less stringent than the old Options API, whereas with React they'll always need hand holding and I'll always need to explain why things are rerendering twice or running terribly or what useMemo does or what useEffect does (or doesn't) do...
- CharlieDigital 2y ago
  Another vote for Vue. It's harder to do poorly and even when you do, it doesn't punish you the same way that React does.
- FrontAid 2y ago
  > specifically UI libraries There are certainly more UI libraries available for React than any other framework [1]. But do you think that these are also clearly better? What would be your go to framework for React? To me, it seems that the trend is going to framework-agnostic or multi-framework libraries anyway (e.g. Ark UI or Zag). [1] https://frontaid.ch/web/ui/libraries.html https://frontaid.ch/web/ui/libraries.html
seanvelasco 2y ago
Solid.js is the real alternative to React
breadwinner 2y ago
You don't need a complex framework like React. Check out this SPA app: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... It uses a 500-line router and a 500-line UI component lib.
azemetre 2y ago
I feel like most of the issues devs have with react are the community surrounding it. Lots of churn and burn libraries with breaking issues and changing APIs, NodeJS issues that effect the ecosystem (like node-sass vs dart-sass), and a snake oil aspect from charlatans that you see on social media (granted this is not limited to react, but it feels like react has the most of them).
nox101 2y ago
My experience 1. Write some solution with out a UI 2. Decide you want a UI 3. Add React 4. Be forced to re-architect your solution because react wants control of all of your state. React is supposed to be the V (View) in MVC but it requires full control of the M (model) in MVC and bleeds into the C (controller) as well. Someone will likely chime in that you can just tell React to re-render the entire UI every frame or write lots of custom functions to monitor your model but that's not really the point. No other UI paradigm requires this.
- t-writescode 2y ago
  When you say "write a solution without ui", do you mean "write a frontend solution without a ui"? What's a frontend solution without ui? I thought all of UI code was intended to serve the frontend. Are you referring to Electron apps or something?
- rtpg 2y ago
  The way you can avoid this: - design "UI struct" for what you want to display - Have React fire off events when doing actions - Those actions get piped into your UI-less solution - Your UI-less solution updates the "UI struct" - React updates the parts of the tree that was using part of your struct if you design this struct in the right way, you can have the updates be _very_ targetted (like, React doing basically no extra work). But your UI struct needs to be really carefully set up so you're not firing things off all over the place. I think it's still an easier problem than keeping your DOM in sync entirely, but it's unfortunately very easy to accidentally over-render still.
deleted 2y ago
[deleted]
terandle 2y ago
Hacker News is a bunch of older grumpy folks that want to keep using jQuery. Also some had a bad time with classic redux patterns that were a terrible atrocity - but also not reacts fault, however they have a strong association with each other. Modern react w/ modern state management patterns is a joy to use.
- phist_mcgee 2y ago
  Remember too, that the loudest minority is not always right. There are millions of developers happily using react every day. They just don't come onto HN to complain about the "woeful state" of frontend.
- ncann 2y ago
  What is considered "modern state management" these days?
  - terandle 2y ago
    If building a SSR site with nextjs use react server components and react context If building a SPA site with vite use tanstack/react-query and react context. There are other great libraries like zustand and jotai that can make sense in certain kinds of more complex applications.

bandrami 2y ago

Using a scripting or templating language on the server to form and send HTML and CSS to the client as $DEITY intended

Muromec 2y ago
Django is still there and is still better than Phoenix by the way. I didn't really touch it in about 10 years, but ... nothing changed. It's amazing!
- doodlesdev 2y ago
  > and is still better than Phoenix by the way. What aspects of Django do you think still stand out compared to Phoenix? It seems like a very solid framework, specially with the recent release of Phoenix LiveView 1.0, which seems like a pretty solid approach to frontend. For context, I’ve worked with Django before but didn’t particularly enjoy the experience—not because of the framework itself (its documentation, ORM, and admin tooling are excellent) but because I’m not a fan of Python, particularly its packaging ecosystem and approach to async, which I find lacking. I haven’t used Phoenix or Elixir before, so I’m curious to hear from someone who has experience with both.
  - Muromec 2y ago
    Django is really thought out and polished in terms of devx. Take ORM for example. You write a model and you get out of the box: - migrations to create the model and to apply schema changes; - form validation for crud; - admin with permissions to edit it; - helpers to get model by id or throw 404. Phoenix kinda is in the same market, but you write your migrations yourself, admin panel is a package somebody slapped on top, etc. It’s not that Phoenix isn’t usable, but getting on that level takes time and effort
vundercind 2y ago
Unironically this. The fastest “web apps” I’ve seen that weren’t absolutely required to be javascript-heavy to operate by virtue of what they do, have been mostly or entirely rendered server-side and have just sent entire pages for most interactions. Still performed better than 99% of webapps.

nailer 2y ago

Svelte. Rather than const [name, setName] = useState('blastonico') ... setName('nailer') You do: let name = 'blastonico' ... name = 'nailer' Also a single .svelte file includes everything you need for a component (HTML, JS, CSS), so it's easier to manage.

efields 2y ago
Vue is also nice.
- nailer 2y ago
  Yep. Svelte's SFC was inspired by Vue. If you like Vue you'll like Svelte which is familiar but adds a compiler for simpler syntax.
  - spoiler 2y ago
    I honestly don't feel like Svelte makes things simpler. And I'm saying this as a "fan" of Svelte and think its compiler is very cool. It just feels a bit weird that there's special .svelte specific rules. Runes kinda fix this, but it's still a bit weird. I think Solid or Vue are much simpler (but only did small projects in them) and have a simpler mental model. I've not yet used Preact, but heard good things about it
    - sensanaty 2y ago
      Yeah I like Svelte a lot, but I can't help but feel Rich feels the need to be different, and not necessarily always in a good way. SvelteKit routing[1] is an example that pops out at me as being genuinely bafflingly bad to the point of comedy. [1] https://svelte.dev/docs/kit/routing https://svelte.dev/docs/kit/routing
ptrwis 2y ago
let name = $state('blastonico')

sensanaty 2y ago

Vue is infinitely better in pretty much every way other than available libraries (specifically UI libraries and some stuff like Motion, though that's soon-to-be framework independent), but to be honest I've never felt that problem in my 6 years working with both, and especially in more recent times pretty much everything is framework agnostic anyways, even the big popular ones like TanStack Query. The one real edge I'll give React is much better Typescript support due to tsx essentially being a superlanguage of TS. Vue's composables are very good, but it falls apart a bit in actual template usage. Tooling is also better, but that's also because it's simply used much more so has had more investment into making the tooling good compared to Volar for Vue. But in my opinion everything else surrounding Vue makes it superior. Signals are a better state management pattern, there aren't all the insane footguns that React comes with, performance is better out-of-the-box and is practically impossible to fuck up compared to React where it's hilariously easy to make even the simplest of apps be performance monstrosities, the documentation is (IMO, I find React's docs (yes I've seen the new ones) terrible) best-in-class, the gilded libraries like Pinia, Vue Router, VueUse are far superior to anything in the React ecosystem... I could keep going, but having worked with both more or less equally, I'd choose Vue 10/10 times over React, no questions asked. I can throw a junior at the codebase and be 100% confident they'll make something that's more-or-less idiomatic Vue code, even with the Composition API which is less stringent than the old Options API, whereas with React they'll always need hand holding and I'll always need to explain why things are rerendering twice or running terribly or what useMemo does or what useEffect does (or doesn't) do...

CharlieDigital 2y ago
Another vote for Vue. It's harder to do poorly and even when you do, it doesn't punish you the same way that React does.
FrontAid 2y ago
> specifically UI libraries There are certainly more UI libraries available for React than any other framework [1]. But do you think that these are also clearly better? What would be your go to framework for React? To me, it seems that the trend is going to framework-agnostic or multi-framework libraries anyway (e.g. Ark UI or Zag). [1] https://frontaid.ch/web/ui/libraries.html https://frontaid.ch/web/ui/libraries.html

seanvelasco 2y ago

Solid.js is the real alternative to React

breadwinner 2y ago

You don't need a complex framework like React. Check out this SPA app: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... It uses a 500-line router and a 500-line UI component lib.

azemetre 2y ago

I feel like most of the issues devs have with react are the community surrounding it. Lots of churn and burn libraries with breaking issues and changing APIs, NodeJS issues that effect the ecosystem (like node-sass vs dart-sass), and a snake oil aspect from charlatans that you see on social media (granted this is not limited to react, but it feels like react has the most of them).

nox101 2y ago

My experience 1. Write some solution with out a UI 2. Decide you want a UI 3. Add React 4. Be forced to re-architect your solution because react wants control of all of your state. React is supposed to be the V (View) in MVC but it requires full control of the M (model) in MVC and bleeds into the C (controller) as well. Someone will likely chime in that you can just tell React to re-render the entire UI every frame or write lots of custom functions to monitor your model but that's not really the point. No other UI paradigm requires this.

t-writescode 2y ago
When you say "write a solution without ui", do you mean "write a frontend solution without a ui"? What's a frontend solution without ui? I thought all of UI code was intended to serve the frontend. Are you referring to Electron apps or something?
rtpg 2y ago
The way you can avoid this: - design "UI struct" for what you want to display - Have React fire off events when doing actions - Those actions get piped into your UI-less solution - Your UI-less solution updates the "UI struct" - React updates the parts of the tree that was using part of your struct if you design this struct in the right way, you can have the updates be _very_ targetted (like, React doing basically no extra work). But your UI struct needs to be really carefully set up so you're not firing things off all over the place. I think it's still an easier problem than keeping your DOM in sync entirely, but it's unfortunately very easy to accidentally over-render still.

deleted 2y ago

[deleted]

terandle 2y ago

Hacker News is a bunch of older grumpy folks that want to keep using jQuery. Also some had a bad time with classic redux patterns that were a terrible atrocity - but also not reacts fault, however they have a strong association with each other. Modern react w/ modern state management patterns is a joy to use.

phist_mcgee 2y ago
Remember too, that the loudest minority is not always right. There are millions of developers happily using react every day. They just don't come onto HN to complain about the "woeful state" of frontend.
ncann 2y ago
What is considered "modern state management" these days?
- terandle 2y ago
  If building a SSR site with nextjs use react server components and react context If building a SPA site with vite use tanstack/react-query and react context. There are other great libraries like zustand and jotai that can make sense in certain kinds of more complex applications.