For coding pros is not problem to adapt to Espruino's limitations, or to make complicated build chains. But for beginners, this slight variation in syntax switching is not to be underestimated. Wanting to reduce this switch is a major reason we decided to start using Espruinos in our education to begin with.
I know it's not a priority because it doesn't unlock new capabilities, but if there is a desire to target the education market as well as hobbyists, language parity should be a goal.
Thanks Gordon, I appreciate it's a resource-constrained platform, and already you have achieved so much on your own.
There is a lot of flux particularly when it comes to web APIs, but ES6 has been around since 2015 or so and is a well-defined target?
Is it helpful to make a distinction of ES6 language syntax (such as spread syntax, default parameters etc) versus the ES6 'standard library' of types and functions, eg 'String.padStart', Maps and so on?
Could addressing the 'standard library' gap with a polyfill approach be considered? In principle it could be performed transparently by the Espruino IDE, in an optimised way (ala tree-shaking) so that polyfills are only added once and only if needed.
This would mean a lighter memory load, even more so if the current standard library is shrunk by shifting less common functions to compile-time includes. It would also be easier for others to contribute to (by writing a 'padStart' function, for example) in contrast to helping with the the low-level Espruino interpreter.
Gaps in language syntax, however, require writing code in a different way or introducing a transpiler. Transpiling can potentially produce very verbose code, making it less useful in a microcontroller context. The syntax gap is the bigger obstacle in terms of 'developer UX' in the context we're using Espruinos, not the 'standard library' gap.
All that said, I'm way out of my depth with my speculations, so please forgive my ignorance 😅