4 ms·

It's astonishing how complex this has become. All the server component stuff is great technologically speaking and if you're using React, it's a very welcome th

It's astonishing how complex this has become. All the server component stuff is great technologically speaking and if you're using React, it's a very welcome thing as this will lead in the long term to less bloated applications for end users. But as a developer I just can't stand all the complexity and the magic going on. And now a React compiler is on its way too. This is just too much.

davnicwil 3y ago
> now a React compiler is on its way too I googled for this and couldn't find anything. Do you have any links that give more info about this?
- matvp 3y ago
  There isn't much info out there yet, but this video is a small preview: https://youtu.be/lGEMwh32soc https://youtu.be/lGEMwh32soc The latest update is mentioned in the March 2023 blog post: https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-optimizing-compiler https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...
  - davnicwil 3y ago
    Ah, interesting! My tldr of this is it'll be a transform of easy to read idiomatic react code using hooks etc into more performant code that avoids unnecessary rerenders by statically analysing where optimisations like memoisation can be injected without changing behavior. Pretty smart stuff but also, yeah, perhaps a bit of a black hole of complexity. I can immediately imagine issues with debugging or somehow relying on the side effects of spurious rerenders and that breaking things in the real world. You'd hope code like this does not exist in the wild... and yet exist it does :-)
    - 0xblinq 3y ago
      As I replied above, all is neat and great until you have to debug something not working as expected.
steve_adams_86 3y ago
I actually see the React compiler plans as a net positive. It introduces complexity in the toolchain which seems bad, but should serve to eliminate a lot of development pains they've introduced over the years. If they get it right, I expect that the dev and user experience on the other side could be quite a bit better. Automatic memoization, signals under the hood, eventually moving away from the VDOM — so much of what people have come to find cumbersome about React can be eliminated by a compilation step doing a lot of these things for us. It's a bit strange that so many React developers don't know when or why to utilize useCallback, useMemo, etc... but maybe it was a mistake to expose those and leave it to developers to know when to use them, given that in a declarative system it can be automatically determined where it would be beneficial or not. I'd prefer to use something else with a more thoughtful design and implementation, but React is well-entrenched. I don't think we'll stop using it any time soon. I still like it, too. The frontend world has arguably had to deal with much worse problems than the complexity of React, and it's a well-worn path that's typically easy to traverse by now. So, net positive I hope.
- 0xblinq 3y ago
  Until things fail or don’t go as expected and it’s imposible to know what the hell is going wrong. That’s the biggest problem with complexity, not just understanding it from the user point of view.
  - steve_adams_86 3y ago
    I agree. At the moment that’s what’s going wrong in countless react applications already though, largely due to things a compiler could catch automatically. I’m not saying it’s perfect, but I expect the case you’re anticipating will be less common (though harder to resolve) than the ones which plague people today (whether they realize it does or not… The lack of awareness is one of the worst parts in my opinion, and why resolving it in the background seems ideal).
duped 3y ago
> But as a developer I just can't stand all the complexity and the magic going o It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago.
- the_only_law 3y ago
  > It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago. Some of us got into the field because of the curiosity of wanting to know how things worked and weren’t satisfied by vague, high level, abstract versions. I imagine this is why I’m so poor at math and physics though.
  - duped 3y ago
    There's nothing wrong with that, but physics and math are also about taking understanding, then building useful abstractions around it to deal with inherent complexity. I find the "complexity bad and makes me sad" attitude around development to be almost paradoxical - our job is literally to abstract things. If you seek for complete understanding you'll never find it. There's always an abstraction underneath and one to build on top.
    - the_only_law 3y ago
      That’s fair, FWIW, I don’t hate abstractions, and often prefer them (recently had a project I switched form primarily C to primarily Erlang because the abstractions provided allowed an amazing level of expressiveness given my project), but I like having a idea of how my abstractions work and preferably where to look when they fail.
- 0xblinq 3y ago
  Well, then it’s not JavaScript anymore? I love abstractions, but lately all the ones provided by next.js related to the server stuff are pretty leaky, and the compiler looks to me like it’s going to be the most leaky of them. There’s also that thing about understanding your layer and the layer below to be able to debug. At this point “my layer” is complex enough that I can’t even think on debugging what’s going on with an error in a hook that was inserted by a compiler while SSRing a client side component which toggles a drop-down.

davnicwil 3y ago

> now a React compiler is on its way too I googled for this and couldn't find anything. Do you have any links that give more info about this?

matvp 3y ago
There isn't much info out there yet, but this video is a small preview: https://youtu.be/lGEMwh32soc https://youtu.be/lGEMwh32soc The latest update is mentioned in the March 2023 blog post: https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-optimizing-compiler https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...
- davnicwil 3y ago
  Ah, interesting! My tldr of this is it'll be a transform of easy to read idiomatic react code using hooks etc into more performant code that avoids unnecessary rerenders by statically analysing where optimisations like memoisation can be injected without changing behavior. Pretty smart stuff but also, yeah, perhaps a bit of a black hole of complexity. I can immediately imagine issues with debugging or somehow relying on the side effects of spurious rerenders and that breaking things in the real world. You'd hope code like this does not exist in the wild... and yet exist it does :-)
  - 0xblinq 3y ago
    As I replied above, all is neat and great until you have to debug something not working as expected.

steve_adams_86 3y ago

I actually see the React compiler plans as a net positive. It introduces complexity in the toolchain which seems bad, but should serve to eliminate a lot of development pains they've introduced over the years. If they get it right, I expect that the dev and user experience on the other side could be quite a bit better. Automatic memoization, signals under the hood, eventually moving away from the VDOM — so much of what people have come to find cumbersome about React can be eliminated by a compilation step doing a lot of these things for us. It's a bit strange that so many React developers don't know when or why to utilize useCallback, useMemo, etc... but maybe it was a mistake to expose those and leave it to developers to know when to use them, given that in a declarative system it can be automatically determined where it would be beneficial or not. I'd prefer to use something else with a more thoughtful design and implementation, but React is well-entrenched. I don't think we'll stop using it any time soon. I still like it, too. The frontend world has arguably had to deal with much worse problems than the complexity of React, and it's a well-worn path that's typically easy to traverse by now. So, net positive I hope.

0xblinq 3y ago
Until things fail or don’t go as expected and it’s imposible to know what the hell is going wrong. That’s the biggest problem with complexity, not just understanding it from the user point of view.
- steve_adams_86 3y ago
  I agree. At the moment that’s what’s going wrong in countless react applications already though, largely due to things a compiler could catch automatically. I’m not saying it’s perfect, but I expect the case you’re anticipating will be less common (though harder to resolve) than the ones which plague people today (whether they realize it does or not… The lack of awareness is one of the worst parts in my opinion, and why resolving it in the background seems ideal).

duped 3y ago

> But as a developer I just can't stand all the complexity and the magic going o It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago.

the_only_law 3y ago
> It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago. Some of us got into the field because of the curiosity of wanting to know how things worked and weren’t satisfied by vague, high level, abstract versions. I imagine this is why I’m so poor at math and physics though.
- duped 3y ago
  There's nothing wrong with that, but physics and math are also about taking understanding, then building useful abstractions around it to deal with inherent complexity. I find the "complexity bad and makes me sad" attitude around development to be almost paradoxical - our job is literally to abstract things. If you seek for complete understanding you'll never find it. There's always an abstraction underneath and one to build on top.
  - the_only_law 3y ago
    That’s fair, FWIW, I don’t hate abstractions, and often prefer them (recently had a project I switched form primarily C to primarily Erlang because the abstractions provided allowed an amazing level of expressiveness given my project), but I like having a idea of how my abstractions work and preferably where to look when they fail.
0xblinq 3y ago
Well, then it’s not JavaScript anymore? I love abstractions, but lately all the ones provided by next.js related to the server stuff are pretty leaky, and the compiler looks to me like it’s going to be the most leaky of them. There’s also that thing about understanding your layer and the layer below to be able to debug. At this point “my layer” is complex enough that I can’t even think on debugging what’s going on with an error in a hook that was inserted by a compiler while SSRing a client side component which toggles a drop-down.