I’m totally in favour of using transpilers to support older platforms.
What has happened though in JS land is developers started using them in reverse - writing to future standards that are not supported by the current underlying interpreter.
Hoping here the same thing does not happen in Ruby
It's awesome to be able to use new features and kick their tires before the core engine dev teams invest resources in building them out.
It seems like a win / win situation here.
js devs get to use and reason about tomorrow's features today and help guide whether or not they are a good idea or even more easily come up with new ones.
Js engine devs get to see how features are used and whether or not to invest.
Honestly what is not to like about this?
JavaScript's a bit unique in this regard though, in that you don't have the option to upgrade the underlying interpreter. In most contexts where Ruby is used, it'd be much simpler just upgrade to a newer version of Ruby than start using a transpiler.
My bigger issue is that this shifts control over the language from Matz and the community to the maintainers of this transpiler. Maybe they decide they want to support something like the ++ operator as a workaround to Matz's insistence that it should not be the language. Then what?
But wow, when the ES6 features hit, and I could use them NOW, in spite of having to support IE? That was huge, and made the code so much nicer in so many ways.
I was really glad that I could, as the snaky folks say, "import from future".
It's not the worst problem for an ecosystem to have, but as someone who wants to ship smaller JS bundles, I find it annoying.
This is somewhat mitigated by the use of babel-preset-env and browserslist.
https://github.com/browserslist/browserslist
Where I work, our build tool uses a list that's (very slowly) getting reduced to evergreen browsers. On some projects, a simpler list can be used for little to no polyfills.
> transpiling in Node, which makes no damn sense
A legitimate use case would be for server-rendered apps, where it's advantageous to share code with client-side, namely transpiling module import/export (rather than CommonJS) and JSX. I do enjoy how recent versions of Node.js are embracing modern language features, even pipeline operator. Still, there are situations where transpiling server-side code makes sense.
Another maybe more relevant reason is using TypeScript, which arguably provides a leap in developer experience and code quality, beyond what browsers (or the V8 engine) would implement in the foreseeable future.
May as well pick the JavaScript/TypeScript flavor with the best developer ergonomics.
> What has happened though in JS land is developers started using them in reverse - writing to future standards that are not supported by the current underlying interpreter.
Why is that in reverse. A transpiler is, after all, and using a compiler to be able to write in a language more expressive than the language to which your code is compiled is rather normal.
Actually, that's not even “in reverse” compared to “to support older platforms”, that's how trabspilers are used to support older platforms.
If I'm using Babel to support, say, IE9 (an older platform), what I am doing is using it to compile JS not supported by IE9, largely because it's a newer standard than IE9 supported, and compiling it to what IE9 understands.
If there a difference between doing that with language features from ES6 on IE9 vs ES2019 on IE11 vs something that is a currently a Stage 3 proposal on current Chrome, sure, but none of those is the reverse of the other, they are all variations on a theme in the same direction.
What is the problem here? You can't expect billions of browsers to be updated so soon and I'd be hairless if I still had to write in ES5 just because there are still IE out there.
Currently I favor in writing TypeScript but if Ruby Next starts supporting type hinting for Ruby 3, then I'd like to give it a go as soon as possible which can even be deployed on current environment. The only problem would be the lack of editor support for the new syntax.
On the JS side, sure, you don't control the env that'll eventually run it, so a source to source compiler makes sense.
On the ruby side, why is this just not in the standard runtime? Are people trying to run newer code on older VMs that they control the deployment of?
If you mean “don't control”, probably, at least, they might be given this tooling: e.g., Ruby on App Engine Standard is 2.5, not the current 2.7.