You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, is there a forum? Mailinglist? Because this is not an issue, this post should/would be posted to a forum, if there was one.
I just read your blog post from 2018 with the reasoning behind your attitude against eval. Which is all obvious and fine - except that I'm missing one use case: Updating or exchanging code during runtime. I'm not talking about bug fixes, but about (possibly just) temporary modules added (and removed) at some point during runtime. For example, we have a use case for LED lighting systems with many communicating IoT devices controlling lamps and one could just let users add "light methods" later. Those modules don't have to be thought of in advance of deploying the lamps. I think this is exactly one of the string points of a JS engine: Code can be updated (added to) any time.
To the question of the subject line: Obviously, given that eval is supported now, your blog post point about the use of meager on-device resources to compile new scripts is true, so how about adding byte code precompiled on the developer machine instead of JS code? The main point above is not that it has to be "JS" (text code), but that it can be done during runtime.
The text was updated successfully, but these errors were encountered:
As you found, we use GitHub issues for answering questions. We are also active on Twitter @moddabletech for quick questions.
I'm not sure it is fair to characterize our position as an "attitude against eval." The practical use of eval on embedded platforms are more limited than on the web platform due to resource constraints. We've shared our recommendations based on our own experience.
You are correct that the limited applicability of eval does not have to limit the ability to deploy code to a device once it has "left the factory" by adding precompiled JavaScript byte code instead of precompiled JavaScript source code. We demonstrated that at Bay Area Maker Faire 2018 as described in our blog post about the event under the Apps for Things section. More recently I demonstrated deploying precompiled JavaScript apps as byte code to a hacked Sonoff B1 lightbulb running the Moddable SDK. I showed that at both the IoT Festival at MIT and the Scripts and Things meetup at the Moddable office in Palo Alto. We call these JavaScript applications for IoT "mods".
There is an example application in my personal GitHub repository that can be used to deploy mods to an embedded device. The runmod readme describes the process and tools involved. Have a look.
First, is there a forum? Mailinglist? Because this is not an issue, this post should/would be posted to a forum, if there was one.
I just read your blog post from 2018 with the reasoning behind your attitude against eval. Which is all obvious and fine - except that I'm missing one use case: Updating or exchanging code during runtime. I'm not talking about bug fixes, but about (possibly just) temporary modules added (and removed) at some point during runtime. For example, we have a use case for LED lighting systems with many communicating IoT devices controlling lamps and one could just let users add "light methods" later. Those modules don't have to be thought of in advance of deploying the lamps. I think this is exactly one of the string points of a JS engine: Code can be updated (added to) any time.
To the question of the subject line: Obviously, given that eval is supported now, your blog post point about the use of meager on-device resources to compile new scripts is true, so how about adding byte code precompiled on the developer machine instead of JS code? The main point above is not that it has to be "JS" (text code), but that it can be done during runtime.
The text was updated successfully, but these errors were encountered: