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.
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.
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)
What I've been doing is just writing in ES6 and testing on Chrome, then after its towards V 1.0 I'll add webpack to the staging branch.
Very little work to switch from a bunch of script tags to a bundle towards the end of active development, much faster than bundling every single time I change the code a little bit.
That is, of course, unless I have to compile typescript, then I'll just target ES5 anyways.