11–20 of 62 posts
Presumably you mean in the browser, rather than node.js? When you can compile and use polyfills with babel and webpack, then why not?
Presumably you mean in the browser, rather than node.js? When you can compile and use polyfills with babel and webpack, then why not?
Babel and webpack make debugging with the v8 debugger a nightmare. How do you approach that and avoid using console.log everywhere? console.log can be great and 90% of the time it's enough but for that other 10% I'd rather my debugging observe the execution context instead of being part of it.
That being said, setting up sourcemaps correctly can be a bear... But it's taken most of the pain away from our debugging issues.
And if that's not possible, as long as you aren't using some of the "heavy to transpile" features like async/await, looking at the translated code directly (and stepping through it) is generally close enough to get the gist of what's going on.
Edit: the bigger headache for me is code which loses it's full stack-trace, which is becoming more and more common when transpiling async/await for reasons I haven't had time to look into.
Presumably you mean in the browser, rather than node.js? When you can compile and use polyfills with babel and webpack, then why not?
Babel and webpack make debugging with the v8 debugger a nightmare. How do you approach that and avoid using console.log everywhere? console.log can be great and 90% of the time it's enough but for that other 10% I'd rather my debugging observe the execution context instead of being part of it.
Edit: What he said /\
Working on a team of experienced non-browser devs, ES6 syntax allowed them to take the language seriously and actually try to do the right thing rather than 'commit atrocities of Javascript' (actual statement).
Presumably you mean in the browser, rather than node.js? When you can compile and use polyfills with babel and webpack, then why not?
Babel and webpack make debugging with the v8 debugger a nightmare. How do you approach that and avoid using console.log everywhere? console.log can be great and 90% of the time it's enough but for that other 10% I'd rather my debugging observe the execution context instead of being part of it.
You'd still need to do some transpiling for imports/exports and JSX, though, depending on what you use. And running different code in development and production has its risks.
ES6 also nudges the code toward a bit more uniformity that can lead to better medium term maintainability.
Am I the only one to not understand the question?
Earlier quoted context omitted.
Babel and webpack make debugging with the v8 debugger a nightmare. How do you approach that and avoid using console.log everywhere? console.log can be great and 90% of the time it's enough but for that other 10% I'd rather my debugging observe the execution context instead of being part of it.
In addition to sourcemaps, another option that I've been meaning to try is to skip most of the babel transforms for typical development builds. Chrome has had full ES2015 support for a while now and it looks like it now has async/await on stable, so it's getting to a point where it should be possible to just debug your ES2015/ES2016/whatever code within Chrome without needing source maps. You'd still need to do some…
I actually tried this for a bit. I found that it really increased the complexity of the build system for not that much of a gain.
Instead of having a "dev" build and a "prod" build, we needed a "chromeDev", a "otherBrowsersDev", and a "prod" build.
So now you have 3 separate environments for your babel configs which you need to keep in-sync, and you run the risk of the semantics being slightly different natively vs the transpiled version (Which IMO isn't that bad when you go from transpiled->native as the transpiled is normally a subset of the "native" functionality, so you are less likely to hit issues)