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.
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.
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:
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.
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.
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 ;)
I'm willing to accept the basic hypothesis that's static typing makes for less runtime errors. The type system in well thought out languages like elm or rust makes coding in them pretty simple. I don't think that typescript's type system is good enough to actually deliver on this promise.
It's very easy, in my experience, to spend 5 minutes writing a function that I am 100% sure will work fine in JavaScript, and then spend 15 minutes trying to figure out how to type it. I'm sure that this is partly due to my own lack of understanding. Typing is basically a huge add-on to the cognitive load when using this superset.
Of course, it could just be that I'm not very good at typescript. But it's a new technology, and it's very possible to find yourself on a project with people who aren't that experienced with it.
Additionally, I think the type system really pushes you towards object oriented programming. This is fundamentally at odds with the way most people write ReactJS.
Lastly, while deno is becoming a more viable option, most JavaScript development is taking place in node, meaning you have to transpile it. TypeScript adds the overhead of needing a build tool. Using `.mjs` files makes it so easy to spin up a project without any dependencies, something the HN crowd is always kvetching about.
> I'm willing to accept the basic hypothesis that's static typing makes for less runtime errors. The type system in well thought out languages like elm or rust makes coding in them pretty simple. I don't think that typescript's type system is good enough to actually deliver on this promise.
I can only share my experience in multiple companies and products that it does deliver and it can result in a dramatic decrease of defects.
> I'm sure that this is partly due to my own lack of understanding. Typing is basically a huge add-on to the cognitive load when using this superset. [...] Of course, it could just be that I'm not very good at typescript. But it's a new technology, and it's very possible to find yourself on a project with people who aren't that experienced with it.
Tools don't come for free. You need to understand TypeScript in order to use it effectively. In my experience having at least a couple senior or principal developers with TypeScript proficiency makes a huge difference, not just because they can assist and guide you, but because with TypeScript they can create a well typed ecosystem that results in it being easier for developers to code safely and following a well thought-out architecture (or rather, make it harder to not do it right), and set up linters & autofixers and other tooling to make things even easier.
> Additionally, I think the type system really pushes you towards object oriented programming. This is fundamentally at odds with the way most people write ReactJS.
I'm curious what gives you this impression. The codebases I've worked with are heavily functional, with very little OO code —sometimes it makes sense— and if anything TS helps us do FP better.
