4 ms·

Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declarati

Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-looking-on-a-résumé, and it was just gonna go downhill from there. Class components were/are just fine.

narrator 4y ago
The cycle of javascript libraries: * SHOW HN: UberTinyUltra.js Here's my new super light-weight 4k Javascript Library! * How I switched to UberTinyUltra.js from PopularFramework.js and simplified my life! * SuperCoolStartup switches to UberTinyUltra.js * How I built my unicorn on UberTinyUltra.js * UberTinyUltra.js 2.0 now with a compiler, classes, typesafety and a C++ like turing complete template language to take on the big enterprise jobs because we have too much time, attracted a lot of developers to the project, and ran out of obvious simple features to implement! * I hate you UberTinyUltra.js you are too complicated. * ShowHN: SuperTinyMega.js Here's my new super light-weight 4k Javascript Library!
- datavirtue 4y ago
  Often, things don't get bloated because the developers are bored, it stems from users requesting features because they are doing it wrong. Sort of how AWS keeps mucking with Lambdas so that thier customers can keep doing it wrong and paying too much. Or how doctors just give patients scips if they ask about a drug and it won't incur them any liability. Over and over I have seen the world shout the praises of a new paradigm that solves a problem...except they totally misunderstand the concept and run in an unintended direction. No one can fight that momentum. So they don't. It happens with nearly everything in tech.
- dntrkv 4y ago
  React is coming up on 10 years since its release. That world you describe is far from reality nowadays.
- jstummbillig 4y ago
  Well. Life moves in waves, but historically, over a long enough time frame (and if we manage not to kill ourselves), more lessons will be learned than lost, and life gets increasingly better.
- sph 4y ago
  I still remember the Parcel or Prettier saga. The first, the no-configuration bundler, the other, the no-configuration opinionated code formatter. Then, for their next big major release, the big feature was adding configuration to make it even more powerful! I haven't used them in a while so my memory might be hazy, but this is exactly the phenomenon you've described. I wonder if it's insecurity or trying to please the crowd that simple niche tools in the frontend end up being configurability behemoths. There's always a time in a JS library where someone decides to rewrite the whole thing and add plugin support, and that's the time that library goes to shit. Over long enough time you get Webpack, with more knobs than the Linux kernel, and cycles back to a version that tries to be smart and not require any configuration anymore, like 1.0 did.
neals 4y ago
what are you using these days?
- yamtaddle 4y ago
  Mainly Vue. It's OK and pretty widely used, which gets you decent library support and such. If I were starting from scratch and didn't have organizational/team inertia & experience to consider, I'd probably give things like htmx a hard look. I'd have to re-evaluate the current Android landscape because it's been a while, but I might still consider React Native only for that platform, because having RN smooth the rough edges off Android dev made it a lot more pleasant and quick, with far less time lost fighting the platform and working around/replacing bad 1st party stuff piecemeal. But maybe it's gotten better-enough in the last 4ish years that it's no longer tempting to drag in RN just to avoid native Android dev. In general though, I just no longer default to advocating React for highly-interactive sites or "webapps", as I did for a while.
engineeringwoke 4y ago
It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases
- ferdowsi 4y ago
  Funny that this whole hooks mess could have probably been better resolved with investment in developing optimization patches for v8 rather than attempting to "fix" React
  - nightski 4y ago
    It would be funny if it were true. Hooks were made for composable behavior for components.
    - Rapzid 4y ago
      My understanding as well though a lot of the details may be perf related.. Ultimately hooks are probably the way they are for the same reason Redux is the way it was(pre RTK I suppose)..
    - engineeringwoke 4y ago
      How would Facebook convince the community to dogfood their new API without some marketing buzz? It's pretty obvious that V8 has trouble optimizing changes to object properties because of the design of the spec, and they were also pretty open about it in the blogs where hooks were introduced. I think it's also clear that useEffect is harder to grok than it's lifecycle equivalents, so there might be other things at play than composability. It's also a bit funny that certain kinds of people can just brush off these things with some non-sequitur on a message board when there are almost always bigger things at play.
      - nightski 4y ago
        I was just going off my own experience with React through the years. It was very hard to compose behavior with class based components. We had to create higher order components that had functions as children which could pass down data as arguments to the child function. It really made a mess of the component hierarchy. Now you can create reusable custom hooks that can be used from any component.
ajkjk 4y ago
Heh. Arguably JS itself "invented a half-baked, partial re-implementation of objects/classes"... _in their class implementation_. God it drives me nuts that the language will allow you to spread a class into an object and it will take the properties but not the methods.
- yamtaddle 4y ago
  Oh, absolutely. Pretty much every distinctive feature of prototypal OO is best classed as "please, never ever actually use this". Adding the "class" sugar and general agreement to pretend the prototypal stuff isn't there, though, made JS OO usable-enough. But yeah, it's not great.
- H1Supreme 4y ago
  Exactly! If the Javascript implementation was better, React probably never would have had to come up with Hooks in the first place.
  - imbnwa 4y ago
    You can solve the problem Hooks purported to solve in plain, idiomatic JavaScript with classes[0] [0]https://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html https://raganwald.com/2016/07/20/prefer-composition-to-inher...
    - ajkjk 4y ago
      This thread may have an OP who prefers classes, but I'm for one 100% in favor of hooks. You could struggle and suffer to solve them with classes, or you could move on to something better.

narrator 4y ago

The cycle of javascript libraries: * SHOW HN: UberTinyUltra.js Here's my new super light-weight 4k Javascript Library! * How I switched to UberTinyUltra.js from PopularFramework.js and simplified my life! * SuperCoolStartup switches to UberTinyUltra.js * How I built my unicorn on UberTinyUltra.js * UberTinyUltra.js 2.0 now with a compiler, classes, typesafety and a C++ like turing complete template language to take on the big enterprise jobs because we have too much time, attracted a lot of developers to the project, and ran out of obvious simple features to implement! * I hate you UberTinyUltra.js you are too complicated. * ShowHN: SuperTinyMega.js Here's my new super light-weight 4k Javascript Library!

datavirtue 4y ago
Often, things don't get bloated because the developers are bored, it stems from users requesting features because they are doing it wrong. Sort of how AWS keeps mucking with Lambdas so that thier customers can keep doing it wrong and paying too much. Or how doctors just give patients scips if they ask about a drug and it won't incur them any liability. Over and over I have seen the world shout the praises of a new paradigm that solves a problem...except they totally misunderstand the concept and run in an unintended direction. No one can fight that momentum. So they don't. It happens with nearly everything in tech.
dntrkv 4y ago
React is coming up on 10 years since its release. That world you describe is far from reality nowadays.
jstummbillig 4y ago
Well. Life moves in waves, but historically, over a long enough time frame (and if we manage not to kill ourselves), more lessons will be learned than lost, and life gets increasingly better.
sph 4y ago
I still remember the Parcel or Prettier saga. The first, the no-configuration bundler, the other, the no-configuration opinionated code formatter. Then, for their next big major release, the big feature was adding configuration to make it even more powerful! I haven't used them in a while so my memory might be hazy, but this is exactly the phenomenon you've described. I wonder if it's insecurity or trying to please the crowd that simple niche tools in the frontend end up being configurability behemoths. There's always a time in a JS library where someone decides to rewrite the whole thing and add plugin support, and that's the time that library goes to shit. Over long enough time you get Webpack, with more knobs than the Linux kernel, and cycles back to a version that tries to be smart and not require any configuration anymore, like 1.0 did.

neals 4y ago

what are you using these days?

yamtaddle 4y ago
Mainly Vue. It's OK and pretty widely used, which gets you decent library support and such. If I were starting from scratch and didn't have organizational/team inertia & experience to consider, I'd probably give things like htmx a hard look. I'd have to re-evaluate the current Android landscape because it's been a while, but I might still consider React Native only for that platform, because having RN smooth the rough edges off Android dev made it a lot more pleasant and quick, with far less time lost fighting the platform and working around/replacing bad 1st party stuff piecemeal. But maybe it's gotten better-enough in the last 4ish years that it's no longer tempting to drag in RN just to avoid native Android dev. In general though, I just no longer default to advocating React for highly-interactive sites or "webapps", as I did for a while.

engineeringwoke 4y ago

It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases

ferdowsi 4y ago
Funny that this whole hooks mess could have probably been better resolved with investment in developing optimization patches for v8 rather than attempting to "fix" React
- nightski 4y ago
  It would be funny if it were true. Hooks were made for composable behavior for components.
  - Rapzid 4y ago
    My understanding as well though a lot of the details may be perf related.. Ultimately hooks are probably the way they are for the same reason Redux is the way it was(pre RTK I suppose)..
  - engineeringwoke 4y ago
    How would Facebook convince the community to dogfood their new API without some marketing buzz? It's pretty obvious that V8 has trouble optimizing changes to object properties because of the design of the spec, and they were also pretty open about it in the blogs where hooks were introduced. I think it's also clear that useEffect is harder to grok than it's lifecycle equivalents, so there might be other things at play than composability. It's also a bit funny that certain kinds of people can just brush off these things with some non-sequitur on a message board when there are almost always bigger things at play.
    - nightski 4y ago
      I was just going off my own experience with React through the years. It was very hard to compose behavior with class based components. We had to create higher order components that had functions as children which could pass down data as arguments to the child function. It really made a mess of the component hierarchy. Now you can create reusable custom hooks that can be used from any component.

ajkjk 4y ago

Heh. Arguably JS itself "invented a half-baked, partial re-implementation of objects/classes"... _in their class implementation_. God it drives me nuts that the language will allow you to spread a class into an object and it will take the properties but not the methods.

yamtaddle 4y ago
Oh, absolutely. Pretty much every distinctive feature of prototypal OO is best classed as "please, never ever actually use this". Adding the "class" sugar and general agreement to pretend the prototypal stuff isn't there, though, made JS OO usable-enough. But yeah, it's not great.
H1Supreme 4y ago
Exactly! If the Javascript implementation was better, React probably never would have had to come up with Hooks in the first place.
- imbnwa 4y ago
  You can solve the problem Hooks purported to solve in plain, idiomatic JavaScript with classes[0] [0]https://raganwald.com/2016/07/20/prefer-composition-to-inheritance.html https://raganwald.com/2016/07/20/prefer-composition-to-inher...
  - ajkjk 4y ago
    This thread may have an OP who prefers classes, but I'm for one 100% in favor of hooks. You could struggle and suffer to solve them with classes, or you could move on to something better.