Espruino IDE vs 'API':
You may get what you need from the espruino-tools project. I think it's unfair to compare the Web IDE to the Arduino IDE, which derives from Wiring which in turn is a fork of Processing. The Web IDE is much easier to extend and based on more modern and well documented technologies. I for one like it (even though I've ended up rarely using it, it's neat for demos and when trying out interfacing with new devices).
With the espruino-tools it is very easy to use practically any editor. I use sublime, brackets and atom with success.
NPM:
One concern with using npm (especially if npm install is not done each upload, which would then probably add some overhead in the time it takes to upload) would be that it kind of encourages quick fixes per user. With the current system, a user is more inclined to file a report, or fix the problem immediately.
Also, making npm available could quickly lead to a lot of questions about why things does not work etc. The Espruino is an embedded device with low memory and the interpreter does have some 'quirks' which a module author should know about and leverage/work around. Pulling in something 'simple' as _underscore will not probably be very successful.
"I make a small change to my code":
There's no such thing ;)
You should and would test the thing. So far I've had one such instance with the RFID module, it broke on my 1v72. The first thing I did was to upgrade to 1v74 (it was a module that had been running for a while) - and you guessed it. It worked!
In conclusion:
I think both approaches make sense. With the npm approach you put more responsibility on the user.
I imagine scenarios like this:
User reads a blog with a project that uses explicit versions (that's what bloggers are used to, because often the runtime itself can be upgraded with npm - so you can 'require' an identical setup). Then user copies code and config. Uploads but it does not work. Why? Because there's been an API change since the release and the Espruino running on the user's device is newer and incompatible.
Maybe the Espruino could be an npm module?
Maybe modules should alert the user if it's using a well known incompatible module/espruino version pair?
I don't mean to seem overly negative, I would probably like this feature - but I'm not convinced it's the right approach.
Npm shines for web because there are so many permutations of the javascript environment, but for the Espruino there's just one. Furthermore, the code that runs on the device should be written specifically for the device, so it's really not much argument about being able to pull in other npm modules.
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.
Some thoughts in random order:
Espruino IDE vs 'API':
You may get what you need from the espruino-tools project. I think it's unfair to compare the Web IDE to the Arduino IDE, which derives from Wiring which in turn is a fork of Processing. The Web IDE is much easier to extend and based on more modern and well documented technologies. I for one like it (even though I've ended up rarely using it, it's neat for demos and when trying out interfacing with new devices).
With the espruino-tools it is very easy to use practically any editor. I use sublime, brackets and atom with success.
NPM:
One concern with using npm (especially if npm install is not done each upload, which would then probably add some overhead in the time it takes to upload) would be that it kind of encourages quick fixes per user. With the current system, a user is more inclined to file a report, or fix the problem immediately.
Also, making npm available could quickly lead to a lot of questions about why things does not work etc. The Espruino is an embedded device with low memory and the interpreter does have some 'quirks' which a module author should know about and leverage/work around. Pulling in something 'simple' as _underscore will not probably be very successful.
"I make a small change to my code":
There's no such thing ;)
You should and would test the thing. So far I've had one such instance with the RFID module, it broke on my 1v72. The first thing I did was to upgrade to 1v74 (it was a module that had been running for a while) - and you guessed it. It worked!
In conclusion:
I think both approaches make sense. With the npm approach you put more responsibility on the user.
I imagine scenarios like this:
User reads a blog with a project that uses explicit versions (that's what bloggers are used to, because often the runtime itself can be upgraded with npm - so you can 'require' an identical setup). Then user copies code and config. Uploads but it does not work. Why? Because there's been an API change since the release and the Espruino running on the user's device is newer and incompatible.
Maybe the Espruino could be an npm module?
Maybe modules should alert the user if it's using a well known incompatible module/espruino version pair?
I don't mean to seem overly negative, I would probably like this feature - but I'm not convinced it's the right approach.
Npm shines for web because there are so many permutations of the javascript environment, but for the Espruino there's just one. Furthermore, the code that runs on the device should be written specifically for the device, so it's really not much argument about being able to pull in other npm modules.
My all too many bytes on the matter.