6 ms·

I haven't watched the 55-minute talk yet, but the 82 slides can be clicked through (ironically, the embed in the article didn't work for me on /any/ browser, bu

by niftich 10y ago

I haven't watched the 55-minute talk yet, but the 82 slides can be clicked through (ironically, the embed in the article didn't work for me on /any/ browser, but here's a direct link: [1]). The slides channel an uplifting attitude; it's okay to try tools and solutions you end up not liking in the end; it's okay to experiment; we're all in this together, and the like. One thing that stood out is the inevitable reference to how JS is a multi-implementation environment and monoculture is bad, but sadly this is much less true now than it was five years ago. Like it or not, this multi-implementation environment has coalesced (for various, sometimes bitingly valid reasons) around a very limited number of implementations, and that's just at the runtime layer; in the wider sense of environments that expose a JS engine and some APIs like Browsers or server-side runtimes, there's also not much choice left. To play on the buffet metaphor, a bewilderingly diverse selection of frameworks, tooling, and quickly-spoiling userland shenanigans exist at the topmost layer, which is fantastic for user choice, but the Web APIs underneath are growing every year, surfacing previously nonexistent functionality in the browser that every website must then decide to ignore or implement. All the while, the language itself has exited the awkward 10-year stalemate, and is receiving yearly revisions with major features. The meme that JS is an awful language needs to subside; the truth is JS is a now-mature language that is used in a rapidly evolving platform, whose APIs are hardly a bastion of stability. These days, that platform is largely driven by the whims of a single vendor, with dominant marketshare on the client, and a significant presence on the other end. (edit: before it comes up, I'm aware JS is used in various, very different environments e.g. the GNOME desktop environment -- some of these criticisms don't apply to those, but then again, neither do most of the tooling and libraries. JS in terms of this talk does seem to mean 'The Browser', and not even Node) [1] https://www.slideshare.net/slideshow/embed_code/key/ILjHOTLRvArC2q https://www.slideshare.net/slideshow/embed_code/key/ILjHOTLR...

ivanbakel 10y ago
I take issue with the last point: JS has matured like bread, not cheese. No matter the age or ingrained status of a language, we have to be able to admit its flaws, rather than go on with some learned helplessness over the whole ordeal. We can be dismissive about "memes", but sometimes groupthink is also a thing people think in a group, because it's justified by common experience. JS has been developed and provided for out of extreme necessity, and I don't think it's fair to try and prop it up using the infrastructure that arose out of that necessity - in some sense, it is the ecosystem around a sewer pipe: important, but nothing worth building a national park over. The day we stop asking "why aren't you using something other than Javascript?" is the day we collectively take a step back in terms of design thinking.
- CharlesW 10y ago
  > JS has matured like bread, not cheese. Considering that the language made huge strides forward with ES2015, ES2016, and ES2017, what does that mean? > The day we stop asking "why aren't you using something other than Javascript?" is the day we collectively take a step back in terms of design thinking. Spirited debates about JS vs. OCaml are implementation thinking.
tigershark 10y ago
It may be less awful, but I have a quite long list of languages that I would use rather than JavaScript. Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Ages ago the only alternative was GWT with all his problems.
- krapp 10y ago
  >Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Except at the end of the day, you're not actually using those languages to do anything besides generating javascript. So you're still using javascript, which means it remains just as essential as it ever was. You could just as well write the javascript being "compiled to" after learning whatever idioms make it "safe" versus vanilla js, and cut out the middleman. Javascript-as-bytecode is an antipattern.
  - tigershark 10y ago
    How you would make invalid state unrepresentable at compile time in vanilla JavaScript? How you would have an HM type systems? How you would not kill yourself in a simple app less than 100k LOC working alone? If you have an answer to all this questions then maybe I missed A LOT in the recent JavaScript evolution, but I really doubt it. And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code. So you're still using machine code, which means it remains just as essential as it ever was. You could just as well write the machine code being "compiled to" after learning whatever idioms make it "safe" versus a normal language, and cut out the middleman. Machine code-as-another language is an antipattern.'
    - krapp 10y ago
      >How you would make invalid state unrepresentable at compile time in vanilla JavaScript? >How you would have an HM type systems? Let me ask you this - how do languages which compile to javascript manage to implement these features in javascript? The answer is they don't. The javascript they generate may behave as if it were safe, but it's no more safe than any other javascript anywhere else, and no different. Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to javascript itself. >How you would not kill yourself in a simple app less than 100k LOC working alone? I don't see how this is relevant to my point, and I don't think 100 KLOC apps represent the common use case for compile-to-js languages. I never argued that compiling to javascript wasn't useful in some way, only that it's still an abstract way to write plain old every day javascript. It's simply incorrect that compile to js language have rendered javascript less relevant because they compile to javascript. >"And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code Except at the end of the day, you're not actually using those languages to do anything besides generating machine code (...) Well, no, and obviously not. Because javascript isn't machine code. It's not bytecode. It's not assembly. It's a high level, loosely typed programming language. However, if we were to accept your facile equivalence as true for the sake of argument, that javascript is no different than machine language, and that, therefore, compiling to javascript is no different than compiling to machine language, then it must also follow that writing javascript by hand is no different than compiling to machine language, and further that translating from any high level language to any other is the same as compiling to machine language. If I were to transpile from any high-level language a to any other high level language b, would it make sense to then declare b equivalent to machine code? Of course not. If you took javascript and translated it to Python, is Python then equivalent to machine language? Of course not. It's the model of treating javascript as a compile target that's absurd. If you're going to try to construct a strawman out of my reasoning and knock it down, at least try a sturdier one.

by niftich 10y ago

ivanbakel 10y ago

I take issue with the last point: JS has matured like bread, not cheese. No matter the age or ingrained status of a language, we have to be able to admit its flaws, rather than go on with some learned helplessness over the whole ordeal. We can be dismissive about "memes", but sometimes groupthink is also a thing people think in a group, because it's justified by common experience. JS has been developed and provided for out of extreme necessity, and I don't think it's fair to try and prop it up using the infrastructure that arose out of that necessity - in some sense, it is the ecosystem around a sewer pipe: important, but nothing worth building a national park over. The day we stop asking "why aren't you using something other than Javascript?" is the day we collectively take a step back in terms of design thinking.

CharlesW 10y ago
> JS has matured like bread, not cheese. Considering that the language made huge strides forward with ES2015, ES2016, and ES2017, what does that mean? > The day we stop asking "why aren't you using something other than Javascript?" is the day we collectively take a step back in terms of design thinking. Spirited debates about JS vs. OCaml are implementation thinking.

tigershark 10y ago

It may be less awful, but I have a quite long list of languages that I would use rather than JavaScript. Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Ages ago the only alternative was GWT with all his problems.

krapp 10y ago
>Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Except at the end of the day, you're not actually using those languages to do anything besides generating javascript. So you're still using javascript, which means it remains just as essential as it ever was. You could just as well write the javascript being "compiled to" after learning whatever idioms make it "safe" versus vanilla js, and cut out the middleman. Javascript-as-bytecode is an antipattern.
- tigershark 10y ago
  How you would make invalid state unrepresentable at compile time in vanilla JavaScript? How you would have an HM type systems? How you would not kill yourself in a simple app less than 100k LOC working alone? If you have an answer to all this questions then maybe I missed A LOT in the recent JavaScript evolution, but I really doubt it. And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code. So you're still using machine code, which means it remains just as essential as it ever was. You could just as well write the machine code being "compiled to" after learning whatever idioms make it "safe" versus a normal language, and cut out the middleman. Machine code-as-another language is an antipattern.'
  - krapp 10y ago
    >How you would make invalid state unrepresentable at compile time in vanilla JavaScript? >How you would have an HM type systems? Let me ask you this - how do languages which compile to javascript manage to implement these features in javascript? The answer is they don't. The javascript they generate may behave as if it were safe, but it's no more safe than any other javascript anywhere else, and no different. Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to javascript itself. >How you would not kill yourself in a simple app less than 100k LOC working alone? I don't see how this is relevant to my point, and I don't think 100 KLOC apps represent the common use case for compile-to-js languages. I never argued that compiling to javascript wasn't useful in some way, only that it's still an abstract way to write plain old every day javascript. It's simply incorrect that compile to js language have rendered javascript less relevant because they compile to javascript. >"And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code Except at the end of the day, you're not actually using those languages to do anything besides generating machine code (...) Well, no, and obviously not. Because javascript isn't machine code. It's not bytecode. It's not assembly. It's a high level, loosely typed programming language. However, if we were to accept your facile equivalence as true for the sake of argument, that javascript is no different than machine language, and that, therefore, compiling to javascript is no different than compiling to machine language, then it must also follow that writing javascript by hand is no different than compiling to machine language, and further that translating from any high level language to any other is the same as compiling to machine language. If I were to transpile from any high-level language a to any other high level language b, would it make sense to then declare b equivalent to machine code? Of course not. If you took javascript and translated it to Python, is Python then equivalent to machine language? Of course not. It's the model of treating javascript as a compile target that's absurd. If you're going to try to construct a strawman out of my reasoning and knock it down, at least try a sturdier one.