Hacker News new | ask | show | jobs
by whatever_dude 3242 days ago
What I can't recommend enough (and hinted at in the article) is for someone to use a transpiler like Babel (and core-js, babel-preset-env, and etc). There's no reason not to use many of the new features and new functions of ES2015+, and you can do that right now even if you're targeting old browsers with transpilation and a bit of automatic shimming.
2 comments

Transpilation is wonderful but it does add a lot of complexity to the build chain. I'm with you the language features are worth it but it's just a quirk of developing for browsers that they don't move as fast as JS itself and that all of this extra machinery is necessary.
Not sure that's true anymore with TypeScript.

They made a real focus on tooling and it's been widely adopted.

In intellij it's as simple as turning on the option and creating a .ts file, the identically named js file is then dropped in the same directory (by default) and you just include that.

It's about 2 minutes from start to finish to setup.

Then it's a natural progression to using https://www.typescriptlang.org/docs/handbook/tsconfig-json.h...

I mean sure if you are going with a split bundle, hot code reloading and tree shaking via webpack then there is a high start cost but ts on it's own is rather fantastic.

vscode does the same thing as intellij if you want to try it without downloading intellij.

> Not sure that's true anymore with TypeScript.

Excellent point, and one of the less-advertised benefits of using TypeScript.

I tend to use Babel/Webpack in most of my projects, mostly because I have the time to waste on keeping up with the 'bleeding edge' and I kind of enjoy it (in perhaps a slightly masochistic way).

That said, more than once I picked TypeScript for some project not primarily because of its main purpose, but rather because it offered a simple way to transpile 'ESNext' to ES5. Despite the fact that a basic Babel/Webpack setup is second nature to me now, it still feels easier to just use TypeScript to do all of it at once, and get types as part of the deal!

Yep and TS makes it trivial to target old JS versions and in 2.4 you can use the type inference on normal JS as well.

Its all a win.

How does debugging in the browser console work when you use that approach?
Normally you have mapping files which tell your browser which bits correlate to the outputted "compiled" code.

Thus in your browser you see the code you write, you put in breakpoints as desired, and everything generally works.

I don't have much depth as to how it all works behind the scenes though, I'd love to know more.

The feature is called "source maps". Here's an MDN article about it https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_...
Like everyone said it works perfectly well with source maps. You get proper debug errors, break points, etc.

That said, it is another thing you need to maintaining and depending on the number of transformations your code has to go through, you introduce more points where the source map can break.