4 ms·

> creating your own one-off language It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuratio

> creating your own one-off language It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages. I believe this is a much underappreciated risk, that some projects will pay a significant price for, a few years from now. We are managing it on our projects by preferring TypeScript, which appears to be advancing forward at a healthy yet careful pace, and which offers some configurability of the exact meaning of the language (in the form of settings in one file), yet does not offer unlimited arbitrary combinations of add-ons. (That said, the Babel ecosystem is amazing, with lots of very interesting work by very smart people.)

Touche 10y ago
> It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages. It don't know what you mean, but it's certainly avoidable. You can do a few things: * Only use language features of the browsers you are targeting. If you are targeting evergreen browsers (not IE) you can use most of ES2015 including classes, arrow functions, and template literals. * Or use a transpiler but stick to some sane judgment of presets, preferable Stage 3 or greater, but at least stuff that's on the standards track. * Don't use stuff like this: https://www.npmjs.com/package/babel-root-import https://www.npmjs.com/package/babel-root-import that exists only to save yourself a couple of keystrokes.