You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Gordon
Yes, that sounds familiar ;)
The problem is that there's not enough manpower to just do what everyone wants. Espruino is only relatively popular today because I've ignored many (often good) requests or put them aside until they could be implemented with less effort or were actually blocking something/someone.
What I'm finding is, it's better for something to work 100% of the time than for it to have an extra feature that doesn't work correctly. Nobody notices when things just work, but they remember for a long time when they break :)
I think it has to be. It would be totally insane to try and re-implement the features of a full-blown OS like Linux. There are now people building Espruino boards into real things, and I don't want the firmware to get so big that it will no longer work on the existing boards. It's already getting to be a bit of a squeeze on the original Espruino.
The way I see it, if Espruino grows to bigger uCs, it becomes so big that keeping it bug-free becomes a real nightmare. It'll start to have requirements near uClinux, and then performance starts to look bad compared to native code or stripped-out desktop JS engines.
However if Espruino stays roughly where it is in terms of code size and instead gets smaller, lower power and cheaper with Moore's law, then it could really stand a chance of doing well.
My general priority list with Espruino is:
I'm not saying HTTP/1.1 is a bad idea. But we shouldn't do it just because 1.0 is 'old' - especially if it means that we then have to maintain a 1.0 version for the Espruino boards with less flash memory.
IMO things like IPv6 (and especially TLS) are significantly higher priority - they're not just 'nice to have', but enable Espruino's use in entirely new areas.