5 ms·

Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Nobody was stupid. We humans just can't really predict wha

by SiVal 6y ago

Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Nobody was stupid. We humans just can't really predict what will work out and what won't in the future, and this was one of those frustrating cases like carving in stone, where every mistake you make is permanent. But a combination of various factors made the web an enormously impactful medium. It's too important to take the approach of "well, let's just add some good stuff to the bad and live with it" where we don't have to. We have to in the browser, but we don't have to on the server. I want to see the "benefit of hindsight, rebuild it better" design of TypeScript matched with a server-side equivalent, which looks like Deno. I hope Deno succeeds.

tantalor 6y ago
What are you talking about?
wmf 6y ago
I'm pretty sure multicore was a thing in 2009, though.
- josephg 6y ago
  It was, and since 2009 the recommendation has been to run an instance of nodejs per CPU core. The justification is that if you're already scaling your app between servers, you shouldn't need a separate mechanism to scale across multiple cores in a single server. I'm not sure when the cluster API was added, but its been in nodejs's core for a long time. (Not that you need to use it, but still.) https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html
  - chrisweekly 6y ago
    yeah `pm2` has even made this painless since (many years ago)
naiveai 6y ago
I find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?
- pietrovismara 6y ago
  Know the language and use automatic linting to exclude the bad parts without effort. Here you go, Javascript/Typescript is suddenly a decent language too.
- SiVal 6y ago
  No, you're making a good point, but my meaning was that TypeScript is a language that is always (and has always been) written as an improved, benefit-of-hindsight, good-parts-only language. It does of course allow any old JS to be used, but that has always been for the purpose of allowing code already written in JavaScript to be called from code written in TypeScript. No TypeScript project, library, or tutorial is ever written like old JS, so TS's allowance of old code that was already written as JS is like a C compiler's escape to assembly, where inline assembly is valid code handled by the C compiler but isn't really C. Traditional JS with new features added, or traditional Node with new features added is the opposite case, where the old standard is being extended, unlike the TS or C+asm case, where the new standard has a mechanism for calling back to the old if necessary. (Deno could still be what I'm talking about even if they added a Node-emulation-library to allow it to call modules written for Node, but I have no idea whether such a thing is planned.)
  - int_19h 6y ago
    Unfortunately, that's not a very accurate analogy. TS also inherits all of JS runtime semantics unchanged, and there's just as much if not more wrongness there.
    - anchpop 6y ago
      I wish for a version of TS where I could have === automatically rewritten to use _.isEqual, that way [1,2,3] === [1,2,3] would return true.
qsort 6y ago
> Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Anything even remotely successful has to commit to its previous choices, even when they were unfortunate (did anybody say C++?). One of the reasons why Node had the impact it had was that it used plain JS and committed to supporting the standard language. I myself prefer writing in statically-typed languages, but the JS direction is frankly commendable; ES6 looks nothing like OG JS, and the fact you can run basically the same code on the browser and on node is a massive bonus. With that said, I hope Deno succeeds as well, having more choices is a good problem to have!
earthboundkid 6y ago
TBF, on the browser side, they have been slowly fixing some of the worst "oops" stuff. First they added "strict mode" and now they have type="module", both of which turn off a lot of bad behaviors. Deno is kind of like that for the backend.

by SiVal 6y ago

tantalor 6y ago

What are you talking about?

wmf 6y ago

I'm pretty sure multicore was a thing in 2009, though.

josephg 6y ago
It was, and since 2009 the recommendation has been to run an instance of nodejs per CPU core. The justification is that if you're already scaling your app between servers, you shouldn't need a separate mechanism to scale across multiple cores in a single server. I'm not sure when the cluster API was added, but its been in nodejs's core for a long time. (Not that you need to use it, but still.) https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html
- chrisweekly 6y ago
  yeah `pm2` has even made this painless since (many years ago)

naiveai 6y ago

I find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?

pietrovismara 6y ago
Know the language and use automatic linting to exclude the bad parts without effort. Here you go, Javascript/Typescript is suddenly a decent language too.
SiVal 6y ago
No, you're making a good point, but my meaning was that TypeScript is a language that is always (and has always been) written as an improved, benefit-of-hindsight, good-parts-only language. It does of course allow any old JS to be used, but that has always been for the purpose of allowing code already written in JavaScript to be called from code written in TypeScript. No TypeScript project, library, or tutorial is ever written like old JS, so TS's allowance of old code that was already written as JS is like a C compiler's escape to assembly, where inline assembly is valid code handled by the C compiler but isn't really C. Traditional JS with new features added, or traditional Node with new features added is the opposite case, where the old standard is being extended, unlike the TS or C+asm case, where the new standard has a mechanism for calling back to the old if necessary. (Deno could still be what I'm talking about even if they added a Node-emulation-library to allow it to call modules written for Node, but I have no idea whether such a thing is planned.)
- int_19h 6y ago
  Unfortunately, that's not a very accurate analogy. TS also inherits all of JS runtime semantics unchanged, and there's just as much if not more wrongness there.
  - anchpop 6y ago
    I wish for a version of TS where I could have === automatically rewritten to use _.isEqual, that way [1,2,3] === [1,2,3] would return true.

qsort 6y ago

> Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Anything even remotely successful has to commit to its previous choices, even when they were unfortunate (did anybody say C++?). One of the reasons why Node had the impact it had was that it used plain JS and committed to supporting the standard language. I myself prefer writing in statically-typed languages, but the JS direction is frankly commendable; ES6 looks nothing like OG JS, and the fact you can run basically the same code on the browser and on node is a massive bonus. With that said, I hope Deno succeeds as well, having more choices is a good problem to have!

earthboundkid 6y ago

TBF, on the browser side, they have been slowly fixing some of the worst "oops" stuff. First they added "strict mode" and now they have type="module", both of which turn off a lot of bad behaviors. Deno is kind of like that for the backend.