3 ms·

I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolu

by nikanj 2y ago

I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.

ibash 2y ago
Class components was the last good react idea.
- teitoklien 2y ago
  Functional Components are 10x easier and cleaner to use in React
  - akritrime 2y ago
    You could already use functional components before. The main issue with React now is all these hooks and effects.
    - crooked-v 2y ago
      The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components. While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.
      - azangru 2y ago
        > as compared to the total uncomposability of class components How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs. Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods. I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.
      - cageface 2y ago
        Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great. The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.
        thomasfromcdnjs 2y ago
        I didn't like hooks from the get go because it was the first time I found the automagical behavior that web dev was somewhat leaving behind starting to creep back in. It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all)) Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power. I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state
        cageface 2y ago
        I've seen a lot of JS frameworks come and go. Eventually they all become hard to work with as complexity accretes to address more use cases and keep performance up. The same is true of native frameworks. SwiftUI and Compose are great when you're just getting started but as soon as you start building complex apps things get hairy fast. I think we still just haven't figured out how to build a UI toolkit that is both highly expressive to use and performant for complex UIs. I think there are some really great ideas in hooks but it might take a new language built around them to make them truly ergonomic. The React compiler is a step in that direction.
  - fire_lake 2y ago
    Functional Components are not functional in the sense of functional programming. They are shared mutable state.
    - patates 2y ago
      Function-based components. They have vaguely functional aspects but they are not functional indeed. I think most people say functional because "function-based" is too long.
    - lastdong 2y ago
      If I recall correctly we have stateless functional components (not managing any state). Functional in React should mean immutable state.
- oaxacaoaxaca 2y ago
  I miss class components! (I know we _can_ use them still but it's hard to convince teams of people to stick with them and ignore what the docs say are best practices for the last five years.)
wtf242 2y ago
It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch. no thanks. I will stick with Rails.
- interstice 2y ago
  To be fair I’ve had similar issues with Rails
  - thibaut_barrere 2y ago
    In that regard, my experience has been the following churn scale: JavaScript churns more than Rails which churns more than Elixir/Phoenix. I believe this is caused by “how sound the fundamentals are” (technical debt in the language itself and its stdlib).
    - creshal 2y ago
      PHP devs meanwhile: You guys churn? For better or worse, you can take 10+ years old PHP code and it'll mostly just work.
      - kalleboo 2y ago
        I maintain a PHP codebase that dates back 15 years and I can count the breaking changes on one hand, and they were all tiny one-line changes
      - rjh29 2y ago
        I wrote a bookmark manager in 2005-ish using security-conscious PHP, and it still works great. I rewrote it in React for fun and not only is it totally out of date, but Github's dependabot has sent me probably 200+ security advisories based on its dependencies.
rimliu 2y ago
I have a harsher take, 95% where react is used it is used without the need.
- tmountain 2y ago
  Prior to React, most developers just invented a strategy for structuring code on the client side. What’s your preferred alternative?
  - Varriount 2y ago
    React isn't a way of structuring code though. It's a whole (huge) framework dedicating to making web apps/pages. And most of the time it seems to be used to replicate functionality that the browser can already natively do (for example, navigating to another page). You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a problem using the back button or ctrl-clicking links while navigating GitHub - which is not something I can say of most other React and heavy-js websites.
    - 000ooo000 2y ago
      >replicate functionality that the browser can already natively do That's.. basically every lib. Welcome to abstractions.
- 000ooo000 2y ago
  The minimum technology required to solve a problem isn't always the same technology that a team has experience with, has existing projects/code in, can readily hire for, etc. Nor is it necessarily the same technology capable of solving future problems. Besides, some people just like the mental model of some tools and enjoy working in that way. The idea that we have to pick the minimum tooling every single time usually seems like flawed thinking based on that out-of-context Tim Berners-Lee quote.
5350-uiop-1130 2y ago
"move fast and break things" as zuckerborg himself said most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated" effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now
- lakomen 2y ago
  And just what does a former PHP dev know about anything
rjh29 2y ago
This used to be confined to web dev, and my backend job was happily tinkering away at 15+ year old code written in stable languages and frameworks, deployed via RPM/Puppet. But we took on too many graduates and now suddenly everything is being rewritten in new languages and we have an insane amount of Kubernetes config attached to everything.

by nikanj 2y ago

ibash 2y ago

Class components was the last good react idea.

teitoklien 2y ago
Functional Components are 10x easier and cleaner to use in React
- akritrime 2y ago
  You could already use functional components before. The main issue with React now is all these hooks and effects.
  - crooked-v 2y ago
    The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components. While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.
    - azangru 2y ago
      > as compared to the total uncomposability of class components How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs. Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods. I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.
    - cageface 2y ago
      Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great. The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.
      - thomasfromcdnjs 2y ago
        I didn't like hooks from the get go because it was the first time I found the automagical behavior that web dev was somewhat leaving behind starting to creep back in. It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all)) Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power. I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state
        cageface 2y ago
        I've seen a lot of JS frameworks come and go. Eventually they all become hard to work with as complexity accretes to address more use cases and keep performance up. The same is true of native frameworks. SwiftUI and Compose are great when you're just getting started but as soon as you start building complex apps things get hairy fast. I think we still just haven't figured out how to build a UI toolkit that is both highly expressive to use and performant for complex UIs. I think there are some really great ideas in hooks but it might take a new language built around them to make them truly ergonomic. The React compiler is a step in that direction.
- fire_lake 2y ago
  Functional Components are not functional in the sense of functional programming. They are shared mutable state.
  - patates 2y ago
    Function-based components. They have vaguely functional aspects but they are not functional indeed. I think most people say functional because "function-based" is too long.
  - lastdong 2y ago
    If I recall correctly we have stateless functional components (not managing any state). Functional in React should mean immutable state.
oaxacaoaxaca 2y ago
I miss class components! (I know we _can_ use them still but it's hard to convince teams of people to stick with them and ignore what the docs say are best practices for the last five years.)

wtf242 2y ago

It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch. no thanks. I will stick with Rails.

interstice 2y ago
To be fair I’ve had similar issues with Rails
- thibaut_barrere 2y ago
  In that regard, my experience has been the following churn scale: JavaScript churns more than Rails which churns more than Elixir/Phoenix. I believe this is caused by “how sound the fundamentals are” (technical debt in the language itself and its stdlib).
  - creshal 2y ago
    PHP devs meanwhile: You guys churn? For better or worse, you can take 10+ years old PHP code and it'll mostly just work.
    - kalleboo 2y ago
      I maintain a PHP codebase that dates back 15 years and I can count the breaking changes on one hand, and they were all tiny one-line changes
    - rjh29 2y ago
      I wrote a bookmark manager in 2005-ish using security-conscious PHP, and it still works great. I rewrote it in React for fun and not only is it totally out of date, but Github's dependabot has sent me probably 200+ security advisories based on its dependencies.

rimliu 2y ago

I have a harsher take, 95% where react is used it is used without the need.

tmountain 2y ago
Prior to React, most developers just invented a strategy for structuring code on the client side. What’s your preferred alternative?
- Varriount 2y ago
  React isn't a way of structuring code though. It's a whole (huge) framework dedicating to making web apps/pages. And most of the time it seems to be used to replicate functionality that the browser can already natively do (for example, navigating to another page). You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a problem using the back button or ctrl-clicking links while navigating GitHub - which is not something I can say of most other React and heavy-js websites.
  - 000ooo000 2y ago
    >replicate functionality that the browser can already natively do That's.. basically every lib. Welcome to abstractions.
000ooo000 2y ago
The minimum technology required to solve a problem isn't always the same technology that a team has experience with, has existing projects/code in, can readily hire for, etc. Nor is it necessarily the same technology capable of solving future problems. Besides, some people just like the mental model of some tools and enjoy working in that way. The idea that we have to pick the minimum tooling every single time usually seems like flawed thinking based on that out-of-context Tim Berners-Lee quote.

5350-uiop-1130 2y ago

"move fast and break things" as zuckerborg himself said most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated" effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now

lakomen 2y ago
And just what does a former PHP dev know about anything

rjh29 2y ago

This used to be confined to web dev, and my backend job was happily tinkering away at 15+ year old code written in stable languages and frameworks, deployed via RPM/Puppet. But we took on too many graduates and now suddenly everything is being rewritten in new languages and we have an insane amount of Kubernetes config attached to everything.