This argument kind of goes the other way as well - if you need a more compact bundle size you should use a minifier first and foremost.
1 Like
I do agree with your argument, but I wonder what should be the limit for using “modern” JS features in the output. Maybe 93%/node version from 3 years ago is indeed too recent, though 
Yeah this is definitively something we need to figure out a good strategy for, when it’s worth using newer features and what the bar for introducing them is. In my view, it’s a matter of doing thorough research in at least these areas:
- How widespread is support for the syntax and what’s our tolerance?
- Is it faster or at least as fast as the current thing it compiles to? If it’s slower, is it worth adding anyway? Why?
- What actual benefits does it bring and does the above justify the benefits?
Modern syntax can be great for sure (we compile async/await to actual async/await as an example) but we need to be quite careful and mindful about what we introduce, and why.
5 Likes
That sounds like a great approach to it!
Thanks for the great work you and the others have been doing in the language lately, btw. Every new feature makes me a bit jealous of people who work with ReScript 
4 Likes
This code uses double options everywhere btw.
It should be { bar?: string }
The runtime representation of option chaining is something one can analyse separately.
For now, the focus should be on the ergonomics of the syntax extension, and whether there’s enough interest to support it.
3 Likes
I always vaguely assumed that there’d be a bsconfig option for target ES version, to control the features used in the JS output. Then people could choose to involve a bundling-for-legacy step in their build setup or not. Is that not something that’s planned to be configurable at all?
Something I would LOVE to see, even more than optional chaining, automatic or otherwise, would be optional chaining with pipes…
let example = apple(_)?->orange?->grame("fruit")->basket
3 Likes