5 ms·

Because making a simple router or simple state management library from scratch is quite simple. So a lot of people do them to learn how the internals work, like

by ratww 4y ago

Because making a simple router or simple state management library from scratch is quite simple. So a lot of people do them to learn how the internals work, like this case here. This makes people better programmers. Some of those folks will then decide to continue the development, put some special things here and there and release it to the world to see if anyone is interested in their version of it. Most of those are ignored, which is fine. However this makes some people vocally angry, because in theory a developer should know every single packages in the world, but never the internals. Only people of a higher class or caste should be allowed to release stuff to the world. The rest are peasants. How dare they. /s

m00dy 4y ago
very well summarised :)
chiefalchemist 4y ago
Agreed. But at the same time aren't there other things to address, to tackle. This won't be popular: but tech self-proclaimes itself as innovative and then wastes time mucking around reinventing wheel after wheel after wheel. Sure, the self-edu is helpful. Of course. But does that always have to a wheel we've seen before going down a road we've been down before? Note: Not trolling or ranting. Just looking for new thoughts and ideas.
- alophawen 4y ago
  Not sure self-edu is true in the case of React. Don't forget React is a Facebook product.
- ratww 4y ago
  It really depends on what you mean by saying wheels are being "reinvented". Is it really wheel reinvention, or is it a small incremental evolution that fixes one pain point, but has to keep all other aspects the same? In this same thread there is a comment about how this little code snippet "throws away backward compatibility, plus everything else". New tech has to have backwards compatibility to even be taken serious by most people. But backwards compatibility requires not only reinventing the wheel, but also having it being on the exact same size and material as before so it fits where it was used. The only way to satisfy both of the groups above is to evolve tech that already exists and implement new findings in already existing libraries, but that will also enrage a lot of people. An example: React Hooks.
andybak 4y ago
I think you're being uncharitable. The reason people say this is because the scale of the problem is much, much worse in front-end javascript than in most other language communites and it's a real problem for people attempting to get to grips with best practice. If your explanation was correct then we'd see the same problem everywhere at the same scale but there's something about front-end javascript that seems to exacerbate this issue.
- ratww 4y ago
  I disagree that the scale of the problem is worse in the Frontend. About being uncharitable: IMO this constant mischaracterization of frontend is the real uncharitable thing here. I also do a lot of backend work and even the most "traditionally stable" programming languages (or frameworks) have a lot of churn in libraries, frameworks, patterns, toolchains, deployment methods and architectures. Which is "fine", that's how programming works! But heck, I worked recently on a 8 year old Rails app that had four different methods/libraries/frameworks being used to wrap business code. But in the frontend that would be extremely rare. If anything the frontend has been quite stable for the last 7 years or so when we settled on mostly React or Vue. The only real big change was Hooks, and even that was incremental and was an attempt to solve real problems in the ecosystem.
  - mhoad 4y ago
    This is basically gaslighting. F/E churn is still wild. I’m staring at an article right now titled the top 14 react libraries you must try in 2020. That’s not a normal thing for a ten year old framework.
    - ratww 4y ago
      How is this gaslighting? Just because someone wrote an article to profit on your FOMO doesn't mean React (and also Vue) usage in the real world hasn't been extremely stable over the years. If anything, this kind of article is the one trying to fuck with your psyche. You don't need any of the libraries in the article to make a good React app/website. Period. No, not even React-Router or Redux. And those two are probably the only ones that you'll see lots of companies/devs that actually ship stuff using. And both of them are not even that complicated, as is demonstrated in this article for the Router. Redux is also quite simple (hence why there's so many alternative implementations). If anything the ones doing the gaslighting are the ones saying that we devs need to use ultra-complex build systems and gigantic libraries to make a "real app". It's the gaslighting of saying simple architectures "won't ever work" mixed with machismo of "real programmers do X". Sure, if you want the complexity that comes with using those "must-use" libraries, feel free to have it. I won't say you're wrong by doing so. Maybe you REALLY need all 14 of them, although I doubt it. But please stop assuming that everyone is doing the same or has to. Nor try to deny the reality of me and lots of others getting things done without "14 must use libraries". Because that is the definition of gaslighting.
lloydatkinson 4y ago
What a ridiculous hyperbolic comment in response to a question around why one particular library has a ton more development than any others in the same space.

by ratww 4y ago

m00dy 4y ago

very well summarised :)

chiefalchemist 4y ago

Agreed. But at the same time aren't there other things to address, to tackle. This won't be popular: but tech self-proclaimes itself as innovative and then wastes time mucking around reinventing wheel after wheel after wheel. Sure, the self-edu is helpful. Of course. But does that always have to a wheel we've seen before going down a road we've been down before? Note: Not trolling or ranting. Just looking for new thoughts and ideas.

alophawen 4y ago
Not sure self-edu is true in the case of React. Don't forget React is a Facebook product.
ratww 4y ago
It really depends on what you mean by saying wheels are being "reinvented". Is it really wheel reinvention, or is it a small incremental evolution that fixes one pain point, but has to keep all other aspects the same? In this same thread there is a comment about how this little code snippet "throws away backward compatibility, plus everything else". New tech has to have backwards compatibility to even be taken serious by most people. But backwards compatibility requires not only reinventing the wheel, but also having it being on the exact same size and material as before so it fits where it was used. The only way to satisfy both of the groups above is to evolve tech that already exists and implement new findings in already existing libraries, but that will also enrage a lot of people. An example: React Hooks.

andybak 4y ago

I think you're being uncharitable. The reason people say this is because the scale of the problem is much, much worse in front-end javascript than in most other language communites and it's a real problem for people attempting to get to grips with best practice. If your explanation was correct then we'd see the same problem everywhere at the same scale but there's something about front-end javascript that seems to exacerbate this issue.

ratww 4y ago
I disagree that the scale of the problem is worse in the Frontend. About being uncharitable: IMO this constant mischaracterization of frontend is the real uncharitable thing here. I also do a lot of backend work and even the most "traditionally stable" programming languages (or frameworks) have a lot of churn in libraries, frameworks, patterns, toolchains, deployment methods and architectures. Which is "fine", that's how programming works! But heck, I worked recently on a 8 year old Rails app that had four different methods/libraries/frameworks being used to wrap business code. But in the frontend that would be extremely rare. If anything the frontend has been quite stable for the last 7 years or so when we settled on mostly React or Vue. The only real big change was Hooks, and even that was incremental and was an attempt to solve real problems in the ecosystem.
- mhoad 4y ago
  This is basically gaslighting. F/E churn is still wild. I’m staring at an article right now titled the top 14 react libraries you must try in 2020. That’s not a normal thing for a ten year old framework.
  - ratww 4y ago
    How is this gaslighting? Just because someone wrote an article to profit on your FOMO doesn't mean React (and also Vue) usage in the real world hasn't been extremely stable over the years. If anything, this kind of article is the one trying to fuck with your psyche. You don't need any of the libraries in the article to make a good React app/website. Period. No, not even React-Router or Redux. And those two are probably the only ones that you'll see lots of companies/devs that actually ship stuff using. And both of them are not even that complicated, as is demonstrated in this article for the Router. Redux is also quite simple (hence why there's so many alternative implementations). If anything the ones doing the gaslighting are the ones saying that we devs need to use ultra-complex build systems and gigantic libraries to make a "real app". It's the gaslighting of saying simple architectures "won't ever work" mixed with machismo of "real programmers do X". Sure, if you want the complexity that comes with using those "must-use" libraries, feel free to have it. I won't say you're wrong by doing so. Maybe you REALLY need all 14 of them, although I doubt it. But please stop assuming that everyone is doing the same or has to. Nor try to deny the reality of me and lots of others getting things done without "14 must use libraries". Because that is the definition of gaslighting.

lloydatkinson 4y ago

What a ridiculous hyperbolic comment in response to a question around why one particular library has a ton more development than any others in the same space.