6 ms·

This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a rea

This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a really great handle on the entire situation, how it got there, what exactly the root of the problems are, and (sometimes) how it can be fixed. And while I partially agree in some cases, I don't think this is in any way a problem specific to the JS ecosystem. There is definitely a lack of quality in a whole lot of JavaScript code out there. But I've also seen TONS of horribly written Ruby gems, .Net libraries, Java apps, even Dockerfiles. It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with tons of horrible options for networking libraries, SQLite helpers, or whatever else wasn't fleshed out well. And that was just the _platform_ maturing with a language that was already quite mature. With JS you have not only the language itself maturing and changing rather quickly, but also all the underlying platforms, package management systems, security issues, etc. Patterns, best practices, and standards often take quite a while to surface and become established. And they seem so obvious in hindsight! Which is why I think we get a lot of people coming from other ecosystems who seem to have selectively forgotten about that happening in their own established tech niche.

vlovich123 6y ago
That could be the case. It could also be the case that those deeply rooted in the Javascript ecosystem aren't listening to domain experts. The numerous security problems with how NPM installs dependencies was pointed out as problematic from the get go by language maintainers, package manager maintainers, & security experts from other projects. I think it's possible that Javascript is getting better & more responsive here & I bet at least some of the defensiveness was that it has also been unfairly criticized which makes it hard to separate signal from noise.
brazzy 6y ago
> It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with Node is about half a year younger than Android, and npm another half year. Javascript is, of course, over a decade older. If JS, Node, NPM, etc is "still maturing" after all that time, then that is a pretty strong indication that there is something wrong with that ecosystem.
- joekrill 6y ago
  It's not a scenario where you can look at "absolute years from inception". It's all relative. With the JS ecosystem, you have rapidly changing Web APIs and standards, varying degrees of browser support and Node versions. And no real "central authority" to guide things in a specific direction. With Android you have a much more managed platform, with Google providing at least some guidance on best practices (explicitly or not). I'm sure the recent introduction of Kotlin added some complexities and confusion to that system. But I still don't think things are changing as rapidly as they are in the JS world, and from so many different angles.
  - bena 6y ago
    I mean, if Javascript is eternally stuck in a state of "still maturing" or it's environment make maturation take much longer than other ecosystems, then wouldn't that make it just a bad ecosystem?
  - kerkeslager 6y ago
    > With the JS ecosystem, you have rapidly changing Web APIs and standards, varying degrees of browser support and Node versions. And no real "central authority" to guide things in a specific direction. All of these (except Node versions) are constraints of the original problem domain: running user interface code in a browser. These are unavoidable for client-side Javascript. But these are not constraints of server-side or command line code, so it's absurd to write server-side code under these constraints. Server-side JavaScript should not exist. Command line utilities written in Javascript should not exist. What part of using having a bunch of completely different ways to bind to events to read a file makes any sense? https://stackoverflow.com/questions/9168737/read-a-text-file-using-node-js https://stackoverflow.com/questions/9168737/read-a-text-file...
    - akiselev 6y ago
      > But these are not constraints of server-side or command line code, so it's absurd to write server-side code under these constraints. Server-side JavaScript should not exist. Command line utilities written in Javascript should not exist. This is a myopic view entirely disconnected from reality. The purpose of code isn't to be perfect or pretty, its purpose is to do useful work. The most relevant constraint is always available resources which is dominated by human capital and experience. Productivity is measured using useful output, not code quality. > What part of using having a bunch of completely different ways to bind to events to read a file makes any sense? The part that puts food on the table. I can't name a single language I have any experience with that has One True Way™ of binding to events except for C and assembly which can only pass callable pointers around.
rudolph9 6y ago
People seems to forget how many people program in JavaScript. Just because the average is low doesn’t mean there aren’t just as many really good ones out there as any other language. It might be common to have lots of dependencies but I can tell you gist hand you only need a few with a really shallow tree to build a full featured web app (both server and client).
- koolba 6y ago
  It’s not just the average that’s low. It’s the median as well. There’s an incredible long tail of skill with JS and the related ecosystem.
  - deleted 6y ago
    [deleted]
- kerkeslager 6y ago
  It's possible to write good code in bad languages.
kerkeslager 6y ago
> This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a really great handle on the entire situation, how it got there, what exactly the root of the problems are, and (sometimes) how it can be fixed. Never in the last 11 years have I not been professionally developing JavaScript to some degree, and I fully stand by what was said in the post above. > It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Then why are things getting worse? > Patterns, best practices, and standards often take quite a while to surface and become established. The best practice for JavaScript at this point is to use the few good libraries (in most cases, that's literally only React) and beyond that, do as little in JavaScript as you can to minimize its impact on your system. User experience comes before everything, so that means you still have to do a lot of JavaScript.
- tashoecraft 6y ago
  It's very limited to think that the user experience comes before everything. If I focus purely on the user and not my business I don't have a business. If I do something good for the user experience but in fact breaks the law, then I am no longer in business. The user is incredibly important, but it's all a balancing act of resources and where to dedicate them.
  - kerkeslager 6y ago
    If your business doesn't serve its users, I am not particularly concerned that you don't have a business. Its my impression that most relevant laws are geared toward protecting users from businesses, but I'd be open to hearing if you know of any exceptions (GDPR isn't one--secretly collecting data on users without their consent isn't serving users, it's harming users).
    - tashoecraft 6y ago
      User experience is a broad term. People here generally think of speed, but in fact that can actually result in a worse user experience. I believe users react better to a loader that takes longer for certain tasks like calculating tax returns because they like to think the computer worked hard to get the best result. It’s not always black and white. I have had to implement features that are awful for the users, but are required by law to have. Others to protect the business from liability. I’m not saying doesn’t serve users as the original comment was “user experience” and was specifically mentioning JavaScript in terms of a presumably slow site. User experience is many things and all of them need to be considered. I totally agree that sites have gotten way to bloated, but the js community is recognizing that and trying to work on it, lazy loading and improvements to module bundling are going to help. I think the craze of tiny packages is coming to an end. Libraries post proudly when they have zero dependencies. As the community evolves it’ll improve, though some sites will probably continue to get worse as higher ups demand more features.

vlovich123 6y ago

That could be the case. It could also be the case that those deeply rooted in the Javascript ecosystem aren't listening to domain experts. The numerous security problems with how NPM installs dependencies was pointed out as problematic from the get go by language maintainers, package manager maintainers, & security experts from other projects. I think it's possible that Javascript is getting better & more responsive here & I bet at least some of the defensiveness was that it has also been unfairly criticized which makes it hard to separate signal from noise.

brazzy 6y ago

> It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with Node is about half a year younger than Android, and npm another half year. Javascript is, of course, over a decade older. If JS, Node, NPM, etc is "still maturing" after all that time, then that is a pretty strong indication that there is something wrong with that ecosystem.

joekrill 6y ago
It's not a scenario where you can look at "absolute years from inception". It's all relative. With the JS ecosystem, you have rapidly changing Web APIs and standards, varying degrees of browser support and Node versions. And no real "central authority" to guide things in a specific direction. With Android you have a much more managed platform, with Google providing at least some guidance on best practices (explicitly or not). I'm sure the recent introduction of Kotlin added some complexities and confusion to that system. But I still don't think things are changing as rapidly as they are in the JS world, and from so many different angles.
- bena 6y ago
  I mean, if Javascript is eternally stuck in a state of "still maturing" or it's environment make maturation take much longer than other ecosystems, then wouldn't that make it just a bad ecosystem?
- kerkeslager 6y ago
  > With the JS ecosystem, you have rapidly changing Web APIs and standards, varying degrees of browser support and Node versions. And no real "central authority" to guide things in a specific direction. All of these (except Node versions) are constraints of the original problem domain: running user interface code in a browser. These are unavoidable for client-side Javascript. But these are not constraints of server-side or command line code, so it's absurd to write server-side code under these constraints. Server-side JavaScript should not exist. Command line utilities written in Javascript should not exist. What part of using having a bunch of completely different ways to bind to events to read a file makes any sense? https://stackoverflow.com/questions/9168737/read-a-text-file-using-node-js https://stackoverflow.com/questions/9168737/read-a-text-file...
  - akiselev 6y ago
    > But these are not constraints of server-side or command line code, so it's absurd to write server-side code under these constraints. Server-side JavaScript should not exist. Command line utilities written in Javascript should not exist. This is a myopic view entirely disconnected from reality. The purpose of code isn't to be perfect or pretty, its purpose is to do useful work. The most relevant constraint is always available resources which is dominated by human capital and experience. Productivity is measured using useful output, not code quality. > What part of using having a bunch of completely different ways to bind to events to read a file makes any sense? The part that puts food on the table. I can't name a single language I have any experience with that has One True Way™ of binding to events except for C and assembly which can only pass callable pointers around.

rudolph9 6y ago

People seems to forget how many people program in JavaScript. Just because the average is low doesn’t mean there aren’t just as many really good ones out there as any other language. It might be common to have lots of dependencies but I can tell you gist hand you only need a few with a really shallow tree to build a full featured web app (both server and client).

koolba 6y ago
It’s not just the average that’s low. It’s the median as well. There’s an incredible long tail of skill with JS and the related ecosystem.
- deleted 6y ago
  [deleted]
kerkeslager 6y ago
It's possible to write good code in bad languages.

kerkeslager 6y ago

> This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a really great handle on the entire situation, how it got there, what exactly the root of the problems are, and (sometimes) how it can be fixed. Never in the last 11 years have I not been professionally developing JavaScript to some degree, and I fully stand by what was said in the post above. > It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Then why are things getting worse? > Patterns, best practices, and standards often take quite a while to surface and become established. The best practice for JavaScript at this point is to use the few good libraries (in most cases, that's literally only React) and beyond that, do as little in JavaScript as you can to minimize its impact on your system. User experience comes before everything, so that means you still have to do a lot of JavaScript.

tashoecraft 6y ago
It's very limited to think that the user experience comes before everything. If I focus purely on the user and not my business I don't have a business. If I do something good for the user experience but in fact breaks the law, then I am no longer in business. The user is incredibly important, but it's all a balancing act of resources and where to dedicate them.
- kerkeslager 6y ago
  If your business doesn't serve its users, I am not particularly concerned that you don't have a business. Its my impression that most relevant laws are geared toward protecting users from businesses, but I'd be open to hearing if you know of any exceptions (GDPR isn't one--secretly collecting data on users without their consent isn't serving users, it's harming users).
  - tashoecraft 6y ago
    User experience is a broad term. People here generally think of speed, but in fact that can actually result in a worse user experience. I believe users react better to a loader that takes longer for certain tasks like calculating tax returns because they like to think the computer worked hard to get the best result. It’s not always black and white. I have had to implement features that are awful for the users, but are required by law to have. Others to protect the business from liability. I’m not saying doesn’t serve users as the original comment was “user experience” and was specifically mentioning JavaScript in terms of a presumably slow site. User experience is many things and all of them need to be considered. I totally agree that sites have gotten way to bloated, but the js community is recognizing that and trying to work on it, lazy loading and improvements to module bundling are going to help. I think the craze of tiny packages is coming to an end. Libraries post proudly when they have zero dependencies. As the community evolves it’ll improve, though some sites will probably continue to get worse as higher ups demand more features.