5 ms·

The biggest practical benefits of plain JS over TS are that: * code is terser * the JS standard is more stable/standardised * code can be distributed uncompi

by fergie 6y ago

The biggest practical benefits of plain JS over TS are that: * code is terser * the JS standard is more stable/standardised * code can be distributed uncompiled * code has broader tooling support * code can be reasoned about and debugged directly and natively in web browsers without the need for sourcemaps/plugins/etc. * file sizes are generally smaller * there are fewer config files * there are fewer moving parts and therefore fewer sources of error * there are fewer levels of abstraction and therefore fewer sources of error * etc. (TS diehards will argue that typing ameliorates higher error rates)

globuous 6y ago
* no compile time I've been using vanilla JS when not using Reason and it is pretty nice. I hate that safari does not support arrow function methods though (as they allow you to not have to bind `this` in the constructor). concerning you post scriptum in brackets, what I like with types is: 1. refactoring becomes simpler 2. understanding APIs becomes simpler
- Ennea 6y ago
  Which version of Safari are you using? According to caniuse[0], arrow functions are supported in Safari starting with version 10, which is over four years old at this point. [0] https://www.caniuse.com/arrow-functions https://www.caniuse.com/arrow-functions
  - inbx0 6y ago
    They said "arrow function methods", so I assume they're looking for public class fields support [1], not only arrow functions support per se. Public class fields (apart from static fields) are also supported in Safari though since September. [1]: https://caniuse.com/mdn-javascript_classes_public_class_fields https://caniuse.com/mdn-javascript_classes_public_class_fiel...
    - globuous 6y ago
      Yes, that's exactly what I meant! Nice! Indeed, I had in mind a script I wrote just around that time and I guess the iPhone I was testing on was not fully updated. Just checked on my Safari on Big Sur and they do work now, sweet ! Should have tried / checked before commenting, thanks for the heads up ;)
- temporallobe 6y ago
  Fat arrow functions are a core part of ES6. If your version of Safari doesn’t support these, I would argue it doesn’t support ES6.
temporallobe 6y ago
I’ve been a huge supporter of VanillaJS for years. In my opinion, standard modern JavaScript is powerful enough to stand on its own for all of the reasons you state. The biggest problem with transpiled languages is that there is yet another level of abstraction to reason about, so debugging can become quite tricky. Many platforms already make layout and markup too abstract (JSF, Slim, to name a few). Now, if you’re working with something like Angular, TypeScript makes sense and is portable within that ecosystem, but that’s it. I once wrote a widget/plugin in pure JavaScript and it worked perfectly well. However, because the project’s “standard” was to use Coffeescript, I was forced to rewrite it in that. Luckily I found a Javascript to Coffeescript converter, which in the end I found extremely amusing because that of course gets compiled to Javascript, which had been written in Javascript in the first place. The resultant code looked like a bad translation of English to Italian and back to English again.
addicted 6y ago
I write pure TS code, and I never use sourcemaps to debug (Chrome Dev Tools has a setting that allows you to disable using sourcemaps). And our code is setup to compile to ES2015, I believe. The reason is simple. Typescript's compilation to JS is really straightforward. You can predict the code that will be generated trivially, because the vast majority of the time it does nothing more than stripping away types. Since we compile down to ES2015, there are a few additional trivial transformations to handle unsupported features like "let" correctly, but they are also trivial to understand.

by fergie 6y ago

globuous 6y ago

* no compile time I've been using vanilla JS when not using Reason and it is pretty nice. I hate that safari does not support arrow function methods though (as they allow you to not have to bind `this` in the constructor). concerning you post scriptum in brackets, what I like with types is: 1. refactoring becomes simpler 2. understanding APIs becomes simpler

Ennea 6y ago
Which version of Safari are you using? According to caniuse[0], arrow functions are supported in Safari starting with version 10, which is over four years old at this point. [0] https://www.caniuse.com/arrow-functions https://www.caniuse.com/arrow-functions
- inbx0 6y ago
  They said "arrow function methods", so I assume they're looking for public class fields support [1], not only arrow functions support per se. Public class fields (apart from static fields) are also supported in Safari though since September. [1]: https://caniuse.com/mdn-javascript_classes_public_class_fields https://caniuse.com/mdn-javascript_classes_public_class_fiel...
  - globuous 6y ago
    Yes, that's exactly what I meant! Nice! Indeed, I had in mind a script I wrote just around that time and I guess the iPhone I was testing on was not fully updated. Just checked on my Safari on Big Sur and they do work now, sweet ! Should have tried / checked before commenting, thanks for the heads up ;)
temporallobe 6y ago
Fat arrow functions are a core part of ES6. If your version of Safari doesn’t support these, I would argue it doesn’t support ES6.

temporallobe 6y ago

I’ve been a huge supporter of VanillaJS for years. In my opinion, standard modern JavaScript is powerful enough to stand on its own for all of the reasons you state. The biggest problem with transpiled languages is that there is yet another level of abstraction to reason about, so debugging can become quite tricky. Many platforms already make layout and markup too abstract (JSF, Slim, to name a few). Now, if you’re working with something like Angular, TypeScript makes sense and is portable within that ecosystem, but that’s it. I once wrote a widget/plugin in pure JavaScript and it worked perfectly well. However, because the project’s “standard” was to use Coffeescript, I was forced to rewrite it in that. Luckily I found a Javascript to Coffeescript converter, which in the end I found extremely amusing because that of course gets compiled to Javascript, which had been written in Javascript in the first place. The resultant code looked like a bad translation of English to Italian and back to English again.

addicted 6y ago

I write pure TS code, and I never use sourcemaps to debug (Chrome Dev Tools has a setting that allows you to disable using sourcemaps). And our code is setup to compile to ES2015, I believe. The reason is simple. Typescript's compilation to JS is really straightforward. You can predict the code that will be generated trivially, because the vast majority of the time it does nothing more than stripping away types. Since we compile down to ES2015, there are a few additional trivial transformations to handle unsupported features like "let" correctly, but they are also trivial to understand.