a) - grunt live --xyz.. based on changes?
b) - still you?
JS = as far as for me - is a more interactive / instant thing... With JS taking on like crazy as THE client side platform, all the heavy-build version came into place again...
In the browser world, I see no issues with it to use the built technology to create dedicated, performing chunks of code if the development process still can work directly based on the fine granular source. The browser has perfect cache to handle that (...sure, it will load comments as well and parse takes longer... but I still prefere it over builds...)
In Espruino / IoT world, the uplaod does already a lot of crunching so only the minimum of code is uploaded... and compared to the amount of 'code' a large, comple (single page) Web app does, it is peanuts,... penny to the dollars.
A build system that can create (and conserve) the context of modules and applications available through the IDE - settings - project - sandbox folder could though be helpful... The IDE could leave traces about what file is loaded and the build system could create trigger info for the IDE to inform it - and to user - about the new version to upload or - configurable - just do it - and configurable - also even save / start the app. I'd prefere to have the IDE as the link, because it allows to separate the dev/build space from the execution/monitoring space. The IDE is a JS thing and can 'easily' be modified.
May be this view is a bit limiting, but I could see it as good start.
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.
@Dennis, who would trigger your task runner?
a) - grunt live --xyz.. based on changes?
b) - still you?
JS = as far as for me - is a more interactive / instant thing... With JS taking on like crazy as THE client side platform, all the heavy-build version came into place again...
In the browser world, I see no issues with it to use the built technology to create dedicated, performing chunks of code if the development process still can work directly based on the fine granular source. The browser has perfect cache to handle that (...sure, it will load comments as well and parse takes longer... but I still prefere it over builds...)
In Espruino / IoT world, the uplaod does already a lot of crunching so only the minimum of code is uploaded... and compared to the amount of 'code' a large, comple (single page) Web app does, it is peanuts,... penny to the dollars.
A build system that can create (and conserve) the context of modules and applications available through the IDE - settings - project - sandbox folder could though be helpful... The IDE could leave traces about what file is loaded and the build system could create trigger info for the IDE to inform it - and to user - about the new version to upload or - configurable - just do it - and configurable - also even save / start the app. I'd prefere to have the IDE as the link, because it allows to separate the dev/build space from the execution/monitoring space. The IDE is a JS thing and can 'easily' be modified.
May be this view is a bit limiting, but I could see it as good start.