4 ms·

> 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

by 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.
    - mgkimsal 6y ago
      I don't think the GP was saying JS is bad because there's not 'one true way' to read from a file. I think the GP was saying it's bad because we're trying to get it to read from a file in the first place. ('Server-side JavaScript should not exist')
    - kerkeslager 6y ago
      > The most relevant constraint is always available resources which is dominated by human capital and experience. Which is why it's particularly puzzling that JavaScript community ignores vast swaths of human capital and experience. Global state? Awesome! Principle of least astonishment? For the birds. Caring about security of your dependencies? What on earth for? > Productivity is measured using useful output, not code quality. Useful output is strongly correlated with code quality, and that correlation grows stronger as a project grows. > The part that puts food on the table. Sure, my billable rate is the same no matter what language I'm writing and if that's all you care about, okay I guess. But I've rewritten a server-side JavaScript application in Python, and my clients wouldn't hesitate to say that they got more for my billable hours than they did for the team of three JavaScript developers who wrote the original application. > 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. You need to take a bigger step back to understand what I'm saying. It's not about having One True Way, it's about keeping your code simple enough that you can read it when you come back to it a year later, you can break it into composable chunks, and reuse it. Every one of the ways on the page I linked forces you to think about an event loop in a process that's fundamentally procedural. It's fundamentally the wrong abstraction for the situation, but JavaScript literally can't represent a better abstraction.
hinkley 6y ago
npm is not 'maturing'. It is now regressing. There is no spec, there is no feature list, and so patches keep breaking behavior and then it gets declared as being on purpose. I am using several flags for CD builds that are not documented on the npm page (or at least were not when I started using them). If you are thinking of deflecting by talking about how maybe my builds are too complex then you can save your breath, because I don't want to hear it. Tinker toy apps won't have any maintenance problems, aren't the sort of things you get paid to work on for years, can be replaced instead of mucked with. And quite frankly, bringing up happy path applications just dates you as a young developer with no field experience (or worse, an idiot).
- brazzy 6y ago
  I think you replied to the wrong person.
hombre_fatal 6y ago
You compare it to Android as if Android dev isn't full of its own problems. Here is some Android complaints that I agree with from the other day: https://news.ycombinator.com/item?id=23438732 https://news.ycombinator.com/item?id=23438732 Android is definitely still maturing. So is iOS/macOS dev. I guess client development isn't as easy as we told ourselves.

by brazzy 6y ago

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.
  - mgkimsal 6y ago
    I don't think the GP was saying JS is bad because there's not 'one true way' to read from a file. I think the GP was saying it's bad because we're trying to get it to read from a file in the first place. ('Server-side JavaScript should not exist')
  - kerkeslager 6y ago
    > The most relevant constraint is always available resources which is dominated by human capital and experience. Which is why it's particularly puzzling that JavaScript community ignores vast swaths of human capital and experience. Global state? Awesome! Principle of least astonishment? For the birds. Caring about security of your dependencies? What on earth for? > Productivity is measured using useful output, not code quality. Useful output is strongly correlated with code quality, and that correlation grows stronger as a project grows. > The part that puts food on the table. Sure, my billable rate is the same no matter what language I'm writing and if that's all you care about, okay I guess. But I've rewritten a server-side JavaScript application in Python, and my clients wouldn't hesitate to say that they got more for my billable hours than they did for the team of three JavaScript developers who wrote the original application. > 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. You need to take a bigger step back to understand what I'm saying. It's not about having One True Way, it's about keeping your code simple enough that you can read it when you come back to it a year later, you can break it into composable chunks, and reuse it. Every one of the ways on the page I linked forces you to think about an event loop in a process that's fundamentally procedural. It's fundamentally the wrong abstraction for the situation, but JavaScript literally can't represent a better abstraction.

hinkley 6y ago

npm is not 'maturing'. It is now regressing. There is no spec, there is no feature list, and so patches keep breaking behavior and then it gets declared as being on purpose. I am using several flags for CD builds that are not documented on the npm page (or at least were not when I started using them). If you are thinking of deflecting by talking about how maybe my builds are too complex then you can save your breath, because I don't want to hear it. Tinker toy apps won't have any maintenance problems, aren't the sort of things you get paid to work on for years, can be replaced instead of mucked with. And quite frankly, bringing up happy path applications just dates you as a young developer with no field experience (or worse, an idiot).

brazzy 6y ago
I think you replied to the wrong person.

hombre_fatal 6y ago

You compare it to Android as if Android dev isn't full of its own problems. Here is some Android complaints that I agree with from the other day: https://news.ycombinator.com/item?id=23438732 https://news.ycombinator.com/item?id=23438732 Android is definitely still maturing. So is iOS/macOS dev. I guess client development isn't as easy as we told ourselves.