4 ms·

This is a symptom of a lot of developers thinking they have to write code exactly like everyone else (or at least, strictly adhere to "best practices"). It's a

This is a symptom of a lot of developers thinking they have to write code exactly like everyone else (or at least, strictly adhere to "best practices"). It's a very subtle disease, but I've noticed it again and again over the years. Reading between the lines, this is a criticism of hooks if they're viewed as a wholesale replacement for classes; from experience I'd argue they're not—they're just a convenient tool for simplifying common patterns. I'd imagine the author knows that to be the case and instead of just using classes where appropriate (or where they wanted), they had to rationalize using hooks because of the aforementioned "but everybody else is using hooks" problem. I suffered from this behavior for years before I realized it was impeding my work. The term that came to mind for the phenomenon was "The Invisible Developer:" a non-existent developer sitting over your shoulder always judging you for your programming choices. That developer doesn't exist. If instead how "in fashion" your code is is the standard on your team: you're on the wrong team.

stefan_ 6y ago
That's not a developers fault, that is the insane JS ecosystem. Every year, everything old breaks and everything new is different. Of course no one can keep up, develop intuition and good practices, so all that's left to do is copy. That is how learning works, only the curve never flattens (and nothing is really learned, nothing is gained).
- HiFaraz 6y ago
  Nothing old broke with the introduction of hooks.
  - cnity 6y ago
    This is true, but even as a fan of hooks, I must admit that you'd be fighting a losing battle if you tried to convince your coworkers to merge your PRs with classes in them, in most places.
    - debacle 6y ago
      That is a problem with your coworkers, certainly.
- rglover 6y ago
  That's just the illusion that's created by the inexperience of most JavaScript developers. You don't have to continually learn the bleeding edge stuff. What they don't tell you (arguably, because it doesn't pay their bills) is that what you should learn is the language. Once you understand that, you can comfortably adapt to any new library/framework/whatchamacallit relatively quickly. Most of what you've described is just peer pressure. The only reason I know that is that I shared this exact opinion until I said "this is stupid" and started doing things my own way (to much success and peace).
  - mlsarecmg 6y ago
    Learning the language is one part, but what enables you to make an application are patterns and paradigms: inflating, mvc, mvvm, immutability, functional. These work for all languages, you learn one once, you can apply it everywhere. It just so happens that maybe every 10-20 years a paradigm replaces another. Since i started writing code in the 90s this happened maybe three times. As far as i am concerned all this ever-changing js fatigue talk is complete rubbish. Even the tooling, we're using the same tools that we used 5 years ago (Webpack, Babel, TS, React, Jest, ...). Microsoft/Apple change their platform toolkits quicker than that! Class lifecycles being replaced by hooks is a radical but much needed change. Learning it isn't complicated and it will enable you to venture on as everything around you sheds the class based component approach. Swiftui, Vue, Svelte and ofc React are just the beginning.
  - perlgeek 6y ago
    > Once you understand that, you can comfortably adapt to any new library/framework/whatchamacallit relatively quickly. I disagree. If you know typescript, it's still quite a leap to be able to code with angular, and debug weird stuff where you stare at a blank page, and the back trace in the dev tools include not even a single line of code you wrote. Also, the language isn't really enough. You need to be familiar with the tooling (npm/yarn, babel, whatever) to use most libraries; so unless you do everything from scratch, you have to deal at least with the churn of the toolchain.
- deltron3030 6y ago
  >Every year, everything old breaks and everything new is different. It's great for online educators and others who monetize devs though.. The JS ecosystem almost seems like it's self promotional, where the monetization opportunities result in a higher self marketing activity of individuals on platforms like Twitter, which of course builds up hype and draws more people into it.
- hajile 6y ago
  I get so tired of the churn claim. Let's look over some stuff ES6 -- 2015 jQuery -- 2006 React -- 2013 React Native -- 2015 Redux -- 2015 VueJS -- 2013 6to5 (now Babel) -- 2015 Webpack -- 2012 ESLint -- 2013 jslint -- 2002 ExpressJS -- 2010 Lodash -- 2012 UnderscoreJS (basically the same API as Lodash) -- 2009 D3 -- 2011 Blockly -- 2012 Node Red -- 2013?? (I'm not sure when IBM first released the project) Bootstrap -- 2011 PDF.js -- 2011 WinJS -- 2012 SocketIO -- 2012 ThreeJS -- 2010 dotenv -- 2015 momentJS -- 2011 node-sass -- 2012 Winston -- 2014 yargs -- 2011 Modernizr -- 2009 Jasmine -- 2010 Mocha -- 2011 Jest -- 2015 All of these are at least 5 year old and most are 8-9 years old. Look over the most downloaded npm packages and you'll find this to be generally true for all the top packages.
  - perlgeek 6y ago
    angular.js -- 2010 - 2016 angular -- 2016 That's an example where, when you jumped on the bandwagon at the height of the hype, you were thrown into a backwards incompatible rewrite pretty quickly. And while npm has been around for quite some time, my outsider impression is that was, for some time, basically discouraged from use, because yarn was so much better. Compare that to Ruby on Rails -- 2004, Catalyst (Perl) -- 2005, Django (Python) 2003. Time moves slower in enterprises, with upgrade cycles more on the scale of 3 to 10 years.
    - hajile 6y ago
      Angular 2 shared a name for marketing reasons, but was/is 100% unrelated as every major idea in Angular turned out to be bad. Yarn solved some npm issues they refused to tackle, but npm got motivated and has now solved most of them. Meanwhile, yarn 2's release has been a disaster and has seemingly resulted in most people (myself included) moving back to npm. I've done Rails and Django work. Rails in particular took years to migrate to the next version. I'd add that Rails has seen 6 versions in 16 years which gives around 1 major breaking upgrade every 3 years (in truth, there's been about 1 major change per year as point releases are pretty big). Likewise, wikipedia gives almost 20 major django updates (I haven't used it in several years, but point updates used to have a very big risk of breaking the project I was working on).
lttlrck 6y ago
There is a real pressure from the ecosystem though. When looking for a library there is good chance that anything recent is written with hooks in mind, and the examples are primarily hook based and the issue tracker is full of questions about hooks... so while you can try to alter your own behavior it feels like you're swimming against the tide.
- rglover 6y ago
  See my reply to _stefan above (responding to the need to use something out of necessity for lack of alternative). In respect to swimming against the tide, this is where experience comes in and knowing both how and _why_ something works the way it does. Over time, you can develop your own opinions and not have to worry that much about what everyone else is up to. Admittedly because I mostly work alone that's a privileged POV of sorts, but I think teams can "act as an individual" and adopt a similar attitude (scale of team permitting).
vsareto 6y ago
Well, code reviewers can choose to enforce best practices, so you kind of do have to write code in a certain way according to them.
smhmd 6y ago
I, for one, do not mind developers adhering to some common patterns/best practices. Whenever I open a codebase foreign to me, I bank on those patterns to understand the app to be able to contribute, learn, etc. Seeing new patterns would be helpful to myself, of course. But, there's a good chance I would bail out if I don't have a huge need learning that codebase.
brentm 6y ago
Hooks do draw you in the direction of a wholesale replacement just because of their incompatibility with classes. I wouldn't consider that to be a bad thing but it does take some time to adjust to the change at first.
grishka 6y ago
I'm an Android developer who despises Kotlin, reactive programming, and "the Google way" in general. My main gripe with all this is that it needlessly complicates everything that can already be done in Java with vanilla SDK. All these additions are touted as a way to write fewer code and do it faster, but the problem is, it's all rather complex under the hood and requires you to hold a lot of context in your head at all times. And if you want to read someone else's code, you gotta have the encyclopedic knowledge of Kotlin, because characters are apparently a dollar each and it's not like we can spare some to write code with actual words people can search for. And to make it even worse, "the Google way" is a moving target. It's constantly evolving just for the sake of change. In the end, I'm sticking with Java and vanilla SDK because it just works and only changes ever so slightly with each major OS release. Also my apps run pretty darn fast on 7-year-old devices because they only use the CPU to do useful work.
- suyash 6y ago
  Good example, React is to web what Kotlin Android is to Android, over complicated and bloatware.
- noema 6y ago
  I find Kotlin more readable than Java in most cases -- less noise to drown out the actual logic. Could you provide an example of a language feature which requires you to "hold context in your head"? It's possible that you have just worked in bad codebases abusing Kotlin sugar. Inferred types for example can improve readability, but only if the variables are named appropriately.
  - grishka 6y ago
    > Could you provide an example of a language feature which requires you to "hold context in your head"? Extensions. Basically every project has its own dialect of Kotlin that you have to know everything about if you're to understand anything. And good luck doing that without an IDE. > It's possible that you have just worked in bad codebases abusing Kotlin sugar. I've never actually worked with Kotlin, I've just seen many examples of it. The problem is, the language itself pushes the developer to use all the sugar, and they have to control that themselves. As opposed to Java, where writing unreadable code would take extra effort because of how dumb and simple the language itself is. Also, to me it feels like an abstraction on top of Java that gets in my way as opposed to being helpful. I love dumb programming languages.
satvikpendem 6y ago
Exactly. I wrote this in another comment but I've been following a Github issue about hook support in Flutter, and I understood React hooks much better after reading that than I ever did before. It is clear now what exactly the problems hooks solve are, composable life-cycle state reuse. I think that because most people don't really understand why hooks were even needed, they can't wrap their minds around them. https://github.com/flutter/flutter/issues/51752 https://github.com/flutter/flutter/issues/51752

stefan_ 6y ago

That's not a developers fault, that is the insane JS ecosystem. Every year, everything old breaks and everything new is different. Of course no one can keep up, develop intuition and good practices, so all that's left to do is copy. That is how learning works, only the curve never flattens (and nothing is really learned, nothing is gained).

HiFaraz 6y ago
Nothing old broke with the introduction of hooks.
- cnity 6y ago
  This is true, but even as a fan of hooks, I must admit that you'd be fighting a losing battle if you tried to convince your coworkers to merge your PRs with classes in them, in most places.
  - debacle 6y ago
    That is a problem with your coworkers, certainly.
rglover 6y ago
That's just the illusion that's created by the inexperience of most JavaScript developers. You don't have to continually learn the bleeding edge stuff. What they don't tell you (arguably, because it doesn't pay their bills) is that what you should learn is the language. Once you understand that, you can comfortably adapt to any new library/framework/whatchamacallit relatively quickly. Most of what you've described is just peer pressure. The only reason I know that is that I shared this exact opinion until I said "this is stupid" and started doing things my own way (to much success and peace).
- mlsarecmg 6y ago
  Learning the language is one part, but what enables you to make an application are patterns and paradigms: inflating, mvc, mvvm, immutability, functional. These work for all languages, you learn one once, you can apply it everywhere. It just so happens that maybe every 10-20 years a paradigm replaces another. Since i started writing code in the 90s this happened maybe three times. As far as i am concerned all this ever-changing js fatigue talk is complete rubbish. Even the tooling, we're using the same tools that we used 5 years ago (Webpack, Babel, TS, React, Jest, ...). Microsoft/Apple change their platform toolkits quicker than that! Class lifecycles being replaced by hooks is a radical but much needed change. Learning it isn't complicated and it will enable you to venture on as everything around you sheds the class based component approach. Swiftui, Vue, Svelte and ofc React are just the beginning.
- perlgeek 6y ago
  > Once you understand that, you can comfortably adapt to any new library/framework/whatchamacallit relatively quickly. I disagree. If you know typescript, it's still quite a leap to be able to code with angular, and debug weird stuff where you stare at a blank page, and the back trace in the dev tools include not even a single line of code you wrote. Also, the language isn't really enough. You need to be familiar with the tooling (npm/yarn, babel, whatever) to use most libraries; so unless you do everything from scratch, you have to deal at least with the churn of the toolchain.
deltron3030 6y ago
>Every year, everything old breaks and everything new is different. It's great for online educators and others who monetize devs though.. The JS ecosystem almost seems like it's self promotional, where the monetization opportunities result in a higher self marketing activity of individuals on platforms like Twitter, which of course builds up hype and draws more people into it.
hajile 6y ago
I get so tired of the churn claim. Let's look over some stuff ES6 -- 2015 jQuery -- 2006 React -- 2013 React Native -- 2015 Redux -- 2015 VueJS -- 2013 6to5 (now Babel) -- 2015 Webpack -- 2012 ESLint -- 2013 jslint -- 2002 ExpressJS -- 2010 Lodash -- 2012 UnderscoreJS (basically the same API as Lodash) -- 2009 D3 -- 2011 Blockly -- 2012 Node Red -- 2013?? (I'm not sure when IBM first released the project) Bootstrap -- 2011 PDF.js -- 2011 WinJS -- 2012 SocketIO -- 2012 ThreeJS -- 2010 dotenv -- 2015 momentJS -- 2011 node-sass -- 2012 Winston -- 2014 yargs -- 2011 Modernizr -- 2009 Jasmine -- 2010 Mocha -- 2011 Jest -- 2015 All of these are at least 5 year old and most are 8-9 years old. Look over the most downloaded npm packages and you'll find this to be generally true for all the top packages.
- perlgeek 6y ago
  angular.js -- 2010 - 2016 angular -- 2016 That's an example where, when you jumped on the bandwagon at the height of the hype, you were thrown into a backwards incompatible rewrite pretty quickly. And while npm has been around for quite some time, my outsider impression is that was, for some time, basically discouraged from use, because yarn was so much better. Compare that to Ruby on Rails -- 2004, Catalyst (Perl) -- 2005, Django (Python) 2003. Time moves slower in enterprises, with upgrade cycles more on the scale of 3 to 10 years.
  - hajile 6y ago
    Angular 2 shared a name for marketing reasons, but was/is 100% unrelated as every major idea in Angular turned out to be bad. Yarn solved some npm issues they refused to tackle, but npm got motivated and has now solved most of them. Meanwhile, yarn 2's release has been a disaster and has seemingly resulted in most people (myself included) moving back to npm. I've done Rails and Django work. Rails in particular took years to migrate to the next version. I'd add that Rails has seen 6 versions in 16 years which gives around 1 major breaking upgrade every 3 years (in truth, there's been about 1 major change per year as point releases are pretty big). Likewise, wikipedia gives almost 20 major django updates (I haven't used it in several years, but point updates used to have a very big risk of breaking the project I was working on).

lttlrck 6y ago

There is a real pressure from the ecosystem though. When looking for a library there is good chance that anything recent is written with hooks in mind, and the examples are primarily hook based and the issue tracker is full of questions about hooks... so while you can try to alter your own behavior it feels like you're swimming against the tide.

rglover 6y ago
See my reply to _stefan above (responding to the need to use something out of necessity for lack of alternative). In respect to swimming against the tide, this is where experience comes in and knowing both how and _why_ something works the way it does. Over time, you can develop your own opinions and not have to worry that much about what everyone else is up to. Admittedly because I mostly work alone that's a privileged POV of sorts, but I think teams can "act as an individual" and adopt a similar attitude (scale of team permitting).

vsareto 6y ago

Well, code reviewers can choose to enforce best practices, so you kind of do have to write code in a certain way according to them.

smhmd 6y ago

I, for one, do not mind developers adhering to some common patterns/best practices. Whenever I open a codebase foreign to me, I bank on those patterns to understand the app to be able to contribute, learn, etc. Seeing new patterns would be helpful to myself, of course. But, there's a good chance I would bail out if I don't have a huge need learning that codebase.

brentm 6y ago

Hooks do draw you in the direction of a wholesale replacement just because of their incompatibility with classes. I wouldn't consider that to be a bad thing but it does take some time to adjust to the change at first.

grishka 6y ago

I'm an Android developer who despises Kotlin, reactive programming, and "the Google way" in general. My main gripe with all this is that it needlessly complicates everything that can already be done in Java with vanilla SDK. All these additions are touted as a way to write fewer code and do it faster, but the problem is, it's all rather complex under the hood and requires you to hold a lot of context in your head at all times. And if you want to read someone else's code, you gotta have the encyclopedic knowledge of Kotlin, because characters are apparently a dollar each and it's not like we can spare some to write code with actual words people can search for. And to make it even worse, "the Google way" is a moving target. It's constantly evolving just for the sake of change. In the end, I'm sticking with Java and vanilla SDK because it just works and only changes ever so slightly with each major OS release. Also my apps run pretty darn fast on 7-year-old devices because they only use the CPU to do useful work.

suyash 6y ago
Good example, React is to web what Kotlin Android is to Android, over complicated and bloatware.
noema 6y ago
I find Kotlin more readable than Java in most cases -- less noise to drown out the actual logic. Could you provide an example of a language feature which requires you to "hold context in your head"? It's possible that you have just worked in bad codebases abusing Kotlin sugar. Inferred types for example can improve readability, but only if the variables are named appropriately.
- grishka 6y ago
  > Could you provide an example of a language feature which requires you to "hold context in your head"? Extensions. Basically every project has its own dialect of Kotlin that you have to know everything about if you're to understand anything. And good luck doing that without an IDE. > It's possible that you have just worked in bad codebases abusing Kotlin sugar. I've never actually worked with Kotlin, I've just seen many examples of it. The problem is, the language itself pushes the developer to use all the sugar, and they have to control that themselves. As opposed to Java, where writing unreadable code would take extra effort because of how dumb and simple the language itself is. Also, to me it feels like an abstraction on top of Java that gets in my way as opposed to being helpful. I love dumb programming languages.

satvikpendem 6y ago

Exactly. I wrote this in another comment but I've been following a Github issue about hook support in Flutter, and I understood React hooks much better after reading that than I ever did before. It is clear now what exactly the problems hooks solve are, composable life-cycle state reuse. I think that because most people don't really understand why hooks were even needed, they can't wrap their minds around them. https://github.com/flutter/flutter/issues/51752 https://github.com/flutter/flutter/issues/51752