Is it planed to have Spread syntax (...) ? No, use arguments instead

Just working on a logger function that does not have to take care about the count of parameter. Something like this and like to use the spread syntax:

var logger = funktion(...params){
      console.log.apply(null, params);
} 

What do you think?

It has been asked before, but it's not high up my priority list as I feel like it doesn't actually add much, and might be a pain to implement.

JS has a built-in arguments variable:

var logger = function(){
      console.log.apply(null, arguments);
} 

should work on Espruino just fine - no need for spread at all :)

Great, so let's use arguments.

The discussion of ES6 language features is pertinent when using Espruino in a pedagogical context. If one is teaching students contemporary ES6 Javascript, the less one has to say "oh, sorry you can't do that on the Espruino", or "here's a totally different way to do that", the better.

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.

I'd like to add more features and potentially this spread operator could at some point go in, however there are (IMO) more important language features to implement first. There's a wishlist at https://github.com/espruino/Espruino/iss­ues/1302 where you can vote

Unfortunately with the current state of JS I don't see that feature parity will ever be possible - it's a moving target and pretty much all the main JS engines out there have teams of people working on them. With Espruino it's really just me and the occasional contributor, and I don't have the resources to keep implementing features at the rate they are announced.

Not only that, but we are limited by how much code will fit on a microcontroller. We can't just keep adding features because at some point things will stop fitting - we are already having to strip less-used features from the Original Espruino board virtually every release.

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 😅

Potentially the Web IDE could add polyfills, yes. There may even be some project out there that includes a bunch of polyfills? I know MDN often lists polyfills for 'new' features.

ES6 has been around since 2015 or so and is a well-defined target?

That's true, but my point was more a general one since initially Espruino didn't support ES5 and I worked hard to get most of that implemented. I could spend the next year making sure all of ES6 got implemented and there'd just be another question identical to yours saying: "ES7 has been around since 2016 or so and is a well-defined target?"

even more so if the current standard library is shrunk by shifting less common functions to compile-time includes

Yes, on very constrained targets this would make a lot of sense. But moving compiled C functions to JS does hurt performance significantly.

Transpiler

You might not like it, but this is the obvious method to ensure that all of the newest language features (not just ES6) can get implemented.

Language features

I think where it makes sense we can definitely add these features, assuming there is time. Spread as per https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Operators/Spre­ad_syntax actually looks doable in a reasonably easy way.

The syntax in declarations like var logger = function(...params) { console.log.apply(null, params); } is more problematic though, and realistically to do it nicely (as well as default arguments) we need to change the way that function arguments are stored. It's something I would like to do, but it's quite a big change - I just wrote this up at https://github.com/espruino/Espruino/iss­ues/2266

However, it's worth noting that some features (like async) just aren't compatible with the way Espruino works and implementing them properly would be a total nightmare. The JS architects assume the engine is build in a specific way (parsed into a parse tree, then bytecode/jit) and so they sometimes come up with syntax (like arrow functions - which I did manage to implement) that end up being very problematic to implement.