4 ms·

I have mixed feelings about this as I do JavaScript transpilers. I’m totally in favour of using transpilers to support older platforms. What has happened thou

by jarym 6y ago

I have mixed feelings about this as I do JavaScript transpilers. 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

chris_st 6y ago
I think I see what you're saying, and I agree about supporting older platforms. 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".
- freedomben 6y ago
  Likewise. We have a big important codebase that was started a little before all the ES6 features hit. Had it been written in ES5 at the time it would be a pain to work in. However it's still a pleasure because it is ES6 with snippets from ES7. We no longer use the transpiler, and were disciplined about only using features that were definitely coming. I'm glad we did.
  - earthboundkid 6y ago
    Yeah, there's no way to convince people to write ES5 once they've seen ES6+. :-) But the problem was that the JS ecosystem never totally got a consistent story about how to stop transpiling. They were transpiling in Node, which makes no damn sense. They were shipping transpiled bundles without the code needed to turn the transpilation off in the future. It was and is a big mess where now that ES6 is supported everywhere, you can't actually use it because even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap even if you don't want it. 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.
    - RobertKerans 6y ago
      Bloody regenerator is the worst for this (I know, IE11 support and all...). Or, even worse, the "regenerator runtime is not defined" error
    - lioeters 6y ago
      > even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap This is somewhat mitigated by the use of babel-preset-env and browserslist. https://github.com/browserslist/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.
- ritchiea 6y ago
  But this is taking one of the worst parts of the Javascript ecosystem and inventing it for Ruby. Despite Ruby not suffering from Javascript problems like having a subpar standard library and missing essential language features like a standard import syntax.
- apozem 6y ago
  I am biased from working so much with SPA frameworks like Angular and React, at this point I've given up. So many frontend processes these days involve some kind of build process to minify or transpile that I figure... why not always use the most advanced features? May as well pick the JavaScript/TypeScript flavor with the best developer ergonomics.
wh-uws 6y ago
I would say more developers like this about the JavaScript ecosystem than don't. 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?
- ludamad 6y ago
  This. Async/await was a dream for standards orgs - yet I was using it. It felt like shaping, or at least sampling, the future
nicoburns 6y ago
> 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. 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.
- waylandsmithers 6y ago
  Right- with JS the developer has little insight into or control over what interpreter will be used to run the code, so with Ruby I think there are fewer advantages to portability. 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?
  - Vinnl 6y ago
    Probably the same as happened to CoffeeScript: people with codebases in CoffeeScript are now stuck with a language that just few people know and is hardly maintained any more, and additionally doesn't really have that many particularly exciting features any more compared to the language proper.
monocasa 6y ago
I also don't get what the value add is in this case. 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?
- dragonwriter 6y ago
  > 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.
mekster 6y ago
> writing to future standards that are not supported by the current underlying interpreter. 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.
dragonwriter 6y ago
> 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. 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.

by jarym 6y ago

chris_st 6y ago

I think I see what you're saying, and I agree about supporting older platforms. 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".

freedomben 6y ago
Likewise. We have a big important codebase that was started a little before all the ES6 features hit. Had it been written in ES5 at the time it would be a pain to work in. However it's still a pleasure because it is ES6 with snippets from ES7. We no longer use the transpiler, and were disciplined about only using features that were definitely coming. I'm glad we did.
- earthboundkid 6y ago
  Yeah, there's no way to convince people to write ES5 once they've seen ES6+. :-) But the problem was that the JS ecosystem never totally got a consistent story about how to stop transpiling. They were transpiling in Node, which makes no damn sense. They were shipping transpiled bundles without the code needed to turn the transpilation off in the future. It was and is a big mess where now that ES6 is supported everywhere, you can't actually use it because even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap even if you don't want it. 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.
  - RobertKerans 6y ago
    Bloody regenerator is the worst for this (I know, IE11 support and all...). Or, even worse, the "regenerator runtime is not defined" error
  - lioeters 6y ago
    > even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap This is somewhat mitigated by the use of babel-preset-env and browserslist. https://github.com/browserslist/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.
ritchiea 6y ago
But this is taking one of the worst parts of the Javascript ecosystem and inventing it for Ruby. Despite Ruby not suffering from Javascript problems like having a subpar standard library and missing essential language features like a standard import syntax.
apozem 6y ago
I am biased from working so much with SPA frameworks like Angular and React, at this point I've given up. So many frontend processes these days involve some kind of build process to minify or transpile that I figure... why not always use the most advanced features? May as well pick the JavaScript/TypeScript flavor with the best developer ergonomics.

wh-uws 6y ago

I would say more developers like this about the JavaScript ecosystem than don't. 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?

ludamad 6y ago
This. Async/await was a dream for standards orgs - yet I was using it. It felt like shaping, or at least sampling, the future

nicoburns 6y ago

> 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. 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.

waylandsmithers 6y ago
Right- with JS the developer has little insight into or control over what interpreter will be used to run the code, so with Ruby I think there are fewer advantages to portability. 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?
- Vinnl 6y ago
  Probably the same as happened to CoffeeScript: people with codebases in CoffeeScript are now stuck with a language that just few people know and is hardly maintained any more, and additionally doesn't really have that many particularly exciting features any more compared to the language proper.

monocasa 6y ago

I also don't get what the value add is in this case. 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?

dragonwriter 6y ago
> 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.

mekster 6y ago

> writing to future standards that are not supported by the current underlying interpreter. 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.

dragonwriter 6y ago

> 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. 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.