4 ms·

For the section about how javascript can only be added onto (such as with typescript), I disagree. Now that we have compilers and transpilers like Babel and Ty

For the section about how javascript can only be added onto (such as with typescript), I disagree. Now that we have compilers and transpilers like Babel and Typescript, it means we can effectively code how we want (even with different languages like reasonml, ocaml, purescript, or ESNext), and in theory browser venders can simply make a new target language or version of JS that these compilers can target.

timw4mail 7y ago
I've always found this to be a strange argument. You have that layer of indirection from the transpiler (which may mean very difficult integrations with JS tools), and it isn't always trivial to interact with actual Javascript.
- WorldMaker 7y ago
  Even C is a layer of indirection that doesn't always reflect the output machine code (much less the assembly language somewhere between). Most of programming language decision making is choosing the stack of "indirections" you feel most comfortable with. Most of programming tool design is helping you navigate those indirections, and the techniques are generally the same in most cases. C you have symbol files and tools that can read them such as debuggers. JS you have sourcemaps and tools that can read them such as debuggers and browser consoles. The tools aren't always perfect, but they get better all the time. It's also a spectrum of choice for which stack you feel comfortable with. Babel and Typescript do increasingly less transpilation with major browser releases. In many cases Typescript today really is just JS with Types. Certainly options like ReasonML and Purescript exist on the opposite end of the spectrum, very little resemble JS, do a lot of more work in transpilation (and do sometimes make JS interop intentionally hard by treating it as an FFI or equivalent boundary). The added "indirection" has trade-offs in productivity, developer "comfort", project aesthetics and synergies.
- chrischen 7y ago
  If anything there are better JS tooling around writing your code with ESNext or Typescript than just plain javascript.
jbjohns 7y ago
Or you can just compile to web assembly and ignore the Javascript. Compiling down to a high level language which, itself, can often be a bit surprising or even ambiguous has always struck me as an approach of last resort. And it's not really our last resort anymore.
- meheleventyone 7y ago
  Right now you can’t ignore JS even with Wasm you still need to marshall data back and forth to do anything interesting.
  - ficklepickle 7y ago
    Or do anything with the DOM. To put anything on the screen in an accessible fashion, you will still need JS with your WASM. You can draw to a canvas with minimal JS, but lose text search, highlighting text, copy/paste and screen reader compatibility, to name a few.
WorldMaker 7y ago
A lot more of the ES2015+ features are supported by browsers today than people seem to think as well. A large number of people still think of things like arrow functions, let/const, async/await, and so forth as "esnext" features when in many cases they are "estoday". (Assuming of course you don't need to support IE11, and good luck if you do.) While TC39 has been trying to be very strict about backwards compatibility, there's still a ton of room for language evolution and it's been moving at a rather aggressive pace. Also, it's hard to call any language like (Q)BASIC or Javascript a "toy language" when it is used to build so many real world practical applications. The esoteric programming language is full of some truly interesting toy languages. Both Javascript and almost every flavor of BASIC has powered real world applications for decades. The underlying fundamentals/foundation of JS is sound enough that many things have been accomplished with the language, even if it isn't aesthetically pleasing to some (or sometimes betrays its very rough, "quick and dirty" development origins). (Then there's of course the digression in whether or not WASM is also building a sound VM option for languages that really don't want to work with JS directly on the web/in web browsers.)
- henriquez 7y ago
  I think this is a fair critique; I could have made the same case with the "toy programming language" statement left out. I love JavaScript and there are brilliant apps written in it, but I do think it's good for people to consider whether they need to depend on it in all cases.
- pdimitar 7y ago
  > Also, it's hard to call any language like (Q)BASIC or Javascript a "toy language" when it is used to build so many real world practical applications. Can we stop conflating "it's popular because we had no choice but to build web apps with it for two decades" and "it's a good language", please? Mud bricks also saw huge usage thousands of years ago. Still doesn't mean they were a good building material for houses.
  - krapp 7y ago
    >Mud bricks also saw huge usage thousands of years ago. Still doesn't mean they were a good building material for houses. But mud brick (AKA adobe) actually is a good material for building houses in certain climates, and it's still being used to this day. If it's the case that Javascript being necessary doesn't make it good, it's also the case that Javascript being old doesn't make it bad.

timw4mail 7y ago

I've always found this to be a strange argument. You have that layer of indirection from the transpiler (which may mean very difficult integrations with JS tools), and it isn't always trivial to interact with actual Javascript.

WorldMaker 7y ago
Even C is a layer of indirection that doesn't always reflect the output machine code (much less the assembly language somewhere between). Most of programming language decision making is choosing the stack of "indirections" you feel most comfortable with. Most of programming tool design is helping you navigate those indirections, and the techniques are generally the same in most cases. C you have symbol files and tools that can read them such as debuggers. JS you have sourcemaps and tools that can read them such as debuggers and browser consoles. The tools aren't always perfect, but they get better all the time. It's also a spectrum of choice for which stack you feel comfortable with. Babel and Typescript do increasingly less transpilation with major browser releases. In many cases Typescript today really is just JS with Types. Certainly options like ReasonML and Purescript exist on the opposite end of the spectrum, very little resemble JS, do a lot of more work in transpilation (and do sometimes make JS interop intentionally hard by treating it as an FFI or equivalent boundary). The added "indirection" has trade-offs in productivity, developer "comfort", project aesthetics and synergies.
chrischen 7y ago
If anything there are better JS tooling around writing your code with ESNext or Typescript than just plain javascript.

jbjohns 7y ago

Or you can just compile to web assembly and ignore the Javascript. Compiling down to a high level language which, itself, can often be a bit surprising or even ambiguous has always struck me as an approach of last resort. And it's not really our last resort anymore.

meheleventyone 7y ago
Right now you can’t ignore JS even with Wasm you still need to marshall data back and forth to do anything interesting.
- ficklepickle 7y ago
  Or do anything with the DOM. To put anything on the screen in an accessible fashion, you will still need JS with your WASM. You can draw to a canvas with minimal JS, but lose text search, highlighting text, copy/paste and screen reader compatibility, to name a few.

WorldMaker 7y ago

A lot more of the ES2015+ features are supported by browsers today than people seem to think as well. A large number of people still think of things like arrow functions, let/const, async/await, and so forth as "esnext" features when in many cases they are "estoday". (Assuming of course you don't need to support IE11, and good luck if you do.) While TC39 has been trying to be very strict about backwards compatibility, there's still a ton of room for language evolution and it's been moving at a rather aggressive pace. Also, it's hard to call any language like (Q)BASIC or Javascript a "toy language" when it is used to build so many real world practical applications. The esoteric programming language is full of some truly interesting toy languages. Both Javascript and almost every flavor of BASIC has powered real world applications for decades. The underlying fundamentals/foundation of JS is sound enough that many things have been accomplished with the language, even if it isn't aesthetically pleasing to some (or sometimes betrays its very rough, "quick and dirty" development origins). (Then there's of course the digression in whether or not WASM is also building a sound VM option for languages that really don't want to work with JS directly on the web/in web browsers.)

henriquez 7y ago
I think this is a fair critique; I could have made the same case with the "toy programming language" statement left out. I love JavaScript and there are brilliant apps written in it, but I do think it's good for people to consider whether they need to depend on it in all cases.
pdimitar 7y ago
> Also, it's hard to call any language like (Q)BASIC or Javascript a "toy language" when it is used to build so many real world practical applications. Can we stop conflating "it's popular because we had no choice but to build web apps with it for two decades" and "it's a good language", please? Mud bricks also saw huge usage thousands of years ago. Still doesn't mean they were a good building material for houses.
- krapp 7y ago
  >Mud bricks also saw huge usage thousands of years ago. Still doesn't mean they were a good building material for houses. But mud brick (AKA adobe) actually is a good material for building houses in certain climates, and it's still being used to this day. If it's the case that Javascript being necessary doesn't make it good, it's also the case that Javascript being old doesn't make it bad.