5 ms·

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 stan

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.
- halostatue 6y ago
  SSJS has existed more or less from the beginning of JS. https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10.pdf https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10... Any general purpose language will be used in ways and places that it was not expected to be used. Both Netscape and MS offered some level of SSJS, and MS added a JScript Windows Script Host.

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.
halostatue 6y ago
SSJS has existed more or less from the beginning of JS. https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10.pdf https://docs.oracle.com/cd/E19957-01/816-6410-10/816-6410-10... Any general purpose language will be used in ways and places that it was not expected to be used. Both Netscape and MS offered some level of SSJS, and MS added a JScript Windows Script Host.