6 ms·

Do all the high quality folks just leave the JS community beyond a certain threshold?

by MichaelZuo 2y ago

randall 2y ago
Or start making their own stuff and ignoring most of the community.
- moron4hire 2y ago
  After a couple of years of doing this, you've built up a backlog of your own, bespoke library code that makes you into a wizard. People are amazed at what you can do and perplexed with how little time it takes you to do it. Nobody else can understand how it's built, but for some reason that's not their problem? It's not like they're taking the time to understand how React is built, either. But as soon as you do something on your own, whoooa buddy. Cowboy programmer alert. It's not good engineering if it's a single, coherent, vertically integrated system. It's only good engineering if it's a mishmash of half-solutions teetering on top of each other.
  - golergka 2y ago
    So you never work in teams with other people again?
    - moron4hire 2y ago
      This feels like a knee-jeek false dichotomy. But in a sense, it's kind of right. I didn't work in teams anymore. I manage them. I still do a lot of programming. And I expect my developers to be competent enough to read other people's code and figure out how it works, what it does, how to use it, based on the tests and plenty of extant examples. I don't want developers who can only be productive in libraries that everyone else's is using/posting YouTube tutorials on/feeding LLM training corpus'. The problem with adopting other people's software is that you have to make it work for your purposes, all while accepting it was only ever originally designed for their purposes. And if that's open source and you contribute to it, then you have to make sure all your changes don't break other people's work. But with my own libraries, I can break anything I want. I have, like, 5 projects using them. It's not a big deal to discover an architectural problem and completely refactor it away to a newer, better design, propagating the change to all the others that use it in fairly short order. And I don't have to argue with anyone about it. I can just do it and get the work done and prove it was the right thing to do long before any Github PR would ever get out of review.
  - randall 2y ago
    Exactly.
  - ericmcer 2y ago
    You are about 4 years behind the curve, everyone uses JS Frameworks that bundle most of the libraries you will need for general dev together now. I don't understand why people get so up in arms over npm modules, as if you could stand up code that does the same things in another language without having to manage dependencies.
    - moron4hire 2y ago
      Because most of the stuff in NPM sucks. I'm not going to keep going back to a store that has sold me nothing but shit so far just on your promise that somewhere, buried deep in the back, is a not-turd.
    - briandear 2y ago
      Rubygems does an excellent job of this.
    - int_19h 2y ago
      In another language, much of what you go to npm for would be in the standard library.
ericwood 2y ago
Or the person you're replying to is overly generalizing a very large diverse community after extrapolating a few bad experiences.
noirscape 2y ago
JavaScript has the unfortunate situation of having years upon years of terrible standard library design, leading to people building lots of small libraries on top of those libraries to get things that were basic functionality in other languages. Then people started stacking more and more things on top of those libraries, creating a giant dependency morass of microdependencies that larger frameworks are now build on top of. And because all these frameworks do things just different enough from each other, every larger library that a dev would want to integrate with those frameworks now needs a specialized version to work with those frameworks. In most languages, if you want to know how something works, you can usually dig into your dependency tree and by the time you hit the stdlib's optimization spaghetti/language internals, you'll probably have figured out what's causing your snag/what the library is expecting out of you. In JavaScript, you hit the dependency morass and have to give up. Most competent devs then decide to pick another language. You can write very legible JavaScript these days, even without a framework, but it looks nothing like JavaScript used in a framework. The other language I know of with this issue is, ironically, Rust.
- mixmastamyk 2y ago
  Please explain the rust angle?
  - webmaven 2y ago
    The implication is that Rust's conservatism regarding what is blessed to go into the standard library sets up a similar dynamic.
  - noirscape 2y ago
    Similar "lots of microdependencies" issue, born in Rusts case from the desire to keep a conservatively sized standard library. It's a smaller problem in the sense that Rust has stronger API contracts as opposed to the absolute disaster that NodeJS is, but in terms of code comprehension you hit a similar dependency morass. The one thing salvaging Rust for now is a lack of similar frameworks, but who knows how long that will last.
Izkata 2y ago
It's more that the low-quality people are way more numerous than otherwise. For example, in the 2000s and 2010s, javascript had the lowest barrier to entry by far thanks to browser dev tools, so a lot of what you saw was people with no prior experience teaching people with no prior experience. These people are still around, and while plenty have improved, they still form the basis of modern javascript practice.
- briandear 2y ago
  This is exactly it. There is probably some bad embedded C floating around, but the barrier to entry is higher and thusly that world seems to be a lot more rigorous than the JS flavor of the day.
  - AlotOfReading 2y ago
    Embedded C usually isn't much better quality than JS, it's just less public. There's very little overlap with the relatively high quality OSS C available.
erikerikson 2y ago
No but the variance is very high

Do all the high quality folks just leave the JS community beyond a certain threshold?

randall 2y ago

Or start making their own stuff and ignoring most of the community.

moron4hire 2y ago
After a couple of years of doing this, you've built up a backlog of your own, bespoke library code that makes you into a wizard. People are amazed at what you can do and perplexed with how little time it takes you to do it. Nobody else can understand how it's built, but for some reason that's not their problem? It's not like they're taking the time to understand how React is built, either. But as soon as you do something on your own, whoooa buddy. Cowboy programmer alert. It's not good engineering if it's a single, coherent, vertically integrated system. It's only good engineering if it's a mishmash of half-solutions teetering on top of each other.
- golergka 2y ago
  So you never work in teams with other people again?
  - moron4hire 2y ago
    This feels like a knee-jeek false dichotomy. But in a sense, it's kind of right. I didn't work in teams anymore. I manage them. I still do a lot of programming. And I expect my developers to be competent enough to read other people's code and figure out how it works, what it does, how to use it, based on the tests and plenty of extant examples. I don't want developers who can only be productive in libraries that everyone else's is using/posting YouTube tutorials on/feeding LLM training corpus'. The problem with adopting other people's software is that you have to make it work for your purposes, all while accepting it was only ever originally designed for their purposes. And if that's open source and you contribute to it, then you have to make sure all your changes don't break other people's work. But with my own libraries, I can break anything I want. I have, like, 5 projects using them. It's not a big deal to discover an architectural problem and completely refactor it away to a newer, better design, propagating the change to all the others that use it in fairly short order. And I don't have to argue with anyone about it. I can just do it and get the work done and prove it was the right thing to do long before any Github PR would ever get out of review.
- randall 2y ago
  Exactly.
- ericmcer 2y ago
  You are about 4 years behind the curve, everyone uses JS Frameworks that bundle most of the libraries you will need for general dev together now. I don't understand why people get so up in arms over npm modules, as if you could stand up code that does the same things in another language without having to manage dependencies.
  - moron4hire 2y ago
    Because most of the stuff in NPM sucks. I'm not going to keep going back to a store that has sold me nothing but shit so far just on your promise that somewhere, buried deep in the back, is a not-turd.
  - briandear 2y ago
    Rubygems does an excellent job of this.
  - int_19h 2y ago
    In another language, much of what you go to npm for would be in the standard library.

ericwood 2y ago

Or the person you're replying to is overly generalizing a very large diverse community after extrapolating a few bad experiences.

noirscape 2y ago

JavaScript has the unfortunate situation of having years upon years of terrible standard library design, leading to people building lots of small libraries on top of those libraries to get things that were basic functionality in other languages. Then people started stacking more and more things on top of those libraries, creating a giant dependency morass of microdependencies that larger frameworks are now build on top of. And because all these frameworks do things just different enough from each other, every larger library that a dev would want to integrate with those frameworks now needs a specialized version to work with those frameworks. In most languages, if you want to know how something works, you can usually dig into your dependency tree and by the time you hit the stdlib's optimization spaghetti/language internals, you'll probably have figured out what's causing your snag/what the library is expecting out of you. In JavaScript, you hit the dependency morass and have to give up. Most competent devs then decide to pick another language. You can write very legible JavaScript these days, even without a framework, but it looks nothing like JavaScript used in a framework. The other language I know of with this issue is, ironically, Rust.

mixmastamyk 2y ago
Please explain the rust angle?
- webmaven 2y ago
  The implication is that Rust's conservatism regarding what is blessed to go into the standard library sets up a similar dynamic.
- noirscape 2y ago
  Similar "lots of microdependencies" issue, born in Rusts case from the desire to keep a conservatively sized standard library. It's a smaller problem in the sense that Rust has stronger API contracts as opposed to the absolute disaster that NodeJS is, but in terms of code comprehension you hit a similar dependency morass. The one thing salvaging Rust for now is a lack of similar frameworks, but who knows how long that will last.

Izkata 2y ago

It's more that the low-quality people are way more numerous than otherwise. For example, in the 2000s and 2010s, javascript had the lowest barrier to entry by far thanks to browser dev tools, so a lot of what you saw was people with no prior experience teaching people with no prior experience. These people are still around, and while plenty have improved, they still form the basis of modern javascript practice.

briandear 2y ago
This is exactly it. There is probably some bad embedded C floating around, but the barrier to entry is higher and thusly that world seems to be a lot more rigorous than the JS flavor of the day.
- AlotOfReading 2y ago
  Embedded C usually isn't much better quality than JS, it's just less public. There's very little overlap with the relatively high quality OSS C available.

erikerikson 2y ago

No but the variance is very high