4 ms·
Is that a high-quality article? It feels like yet another clueless hype with arguments stretched to make a point. there’s no need to allocate space to a class
by wruza 5y ago
Is that a high-quality article? It feels like yet another clueless hype with arguments stretched to make a point.
there’s no need to allocate space to a class instance, then call a render() function, you just call the function
That module exports a class, not an instance (not that it was significant). React still allocates vdom nodes at mount, by using sort of new Component for function components and new Hello for class-based ones. It has to store useFoo()-states somewhere anyway.
setName(response.data,name)
That ‘name’ symbol was never defined. Or is it response.data.name?
And the graph shows the same growth rate way before ‘hooks’ were released (2017), which makes “With hooks … has grown” a little non-sequitur. See also the same graph with react-hooks: https://insights.stackoverflow.com/trends?tags=jquery%2Cangularjs%2Cangular%2Creactjs%2Creact-hooks https://insights.stackoverflow.com/trends?tags=jquery%2Cangu...
- true_religion 5y agoI don’t really understand the authors reasoning either. Classes in JavaScript are just sugar around functional closures. In fact, you can use hooks inside of React component subclasses with a little fiddling [1]. The fact that the official react doesn’t support it is basically a design decision. It’s not impossible, but they just want to draw a clear line in the sand about how they think React code should be written. 1. https://www.npmjs.com/package/react-universal-hooks https://www.npmjs.com/package/react-universal-hooks
- EMM_386 5y ago> Classes in JavaScript are just sugar around functional closures. One of the key red flags I look for in articles like this are whenever the "overhead" of classes is mentioned, such as with "there’s no need to allocate space to a class instance", without any actual metrics showing what this "space overhead" or "performance penalty" amounts to. It seems like more of a misconception about how JavaScript works. There may be some overhead, but do we know what it actually is in a real world application? Or are we just going on assumptions about what we feel is "light" versus "heavy", often frequently with a biased opinion because we simply don't like OOP concepts?
- austincheney 5y agoPerformance and classes are a complicated subject. In short classes execute very fast in V8 jsVM for similar reasons they benefit lower level languages like C++. That improvement applies to the syntax only and almost exclusively to micro benchmarks. The problem with classes, and OOP in general, is that there is a lot of decoration that goes into the code in real world use cases. That decoration is generally not beneficial to performance, such as: getters, setters, a bunch of unnecessary implicit reference calls, access to the DOM using a bunch of unnecessary abstraction layers, and so forth. If you are the kind of JS expert that is easily capable of not using OOP you can probably get this right and make really fast use of classes, but that’s not the primary audience.
- cjblomqvist 5y agoYeah, the arguments in this article are not the arguments why hooks are better than classes, or why they exist at all. There is a reason though. I actually think the Vue docs explain it quite well (should be pretty easy to translate to React): https://v3.vuejs.org/guide/composition-api-introduction.html#why-composition-api https://v3.vuejs.org/guide/composition-api-introduction.html...
- jerrygoyal 5y agoas soon as I saw it's a SO article i closed it. I have gone through enough low quality SO articles and podcasts to understand that they write these for SEO not devs.
- black3r 5y agonot SEO but recruiters and name recognition. Most of these low quality blogs are written by IT students who aren't top of their class and want to stand out in some other way.
- aaaaaaaaaaab 5y agoI wish these people would go back to collecting those useless developer certificates. At least they didn't pollute search results with their low-effort blogspam back then.
- Zababa 5y ago> Is that a high-quality article? It feels like yet another clueless hype with arguments stretched to make a point. Honestly, most articles on the stackoverflow blog feel like that. They are usually shallow. See for example the recent articles about design patterns https://stackoverflow.blog/2021/10/13/why-solve-a-problem-twice-design-patterns-let-you-apply-existing-solutions-to-your-code/ https://stackoverflow.blog/2021/10/13/why-solve-a-problem-tw... and REST APIs https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/ https://stackoverflow.blog/2020/03/02/best-practices-for-res....
- hliyan 5y agoI was also put off by the author not being able to make the distinction between a library and a framework. The two are almost the inverse of each other: a framework is an application scaffolding while libraries are the building blocks that fit into said scaffolding.
- delta1 5y agoconst [Name, setName] = useState("") But yes he got the capitalisation wrong.
- aaaaaaaaaaab 5y agoIt's not an article. It's more like "content marketing".