Embedded JavaScript programming

First there was client side JavaScript, then we got server side JavaScript, called Node.JS. Next step is embedded side JavaScript programming.

As you know, JavaScript is not Java. JS has many characteristics that makes it behave much unlike Java. First of all, in JS external function calls are asynchronous, non-blocking. This means when you request for certain resource, your call returns immediately, and your request is served later. Then, callback function you provided may be invoked or not. This approach makes JavaScript ideal for distributed computing, as the same phenomena occurs over there. You request something, and you may or may not get the response. 

Second, server sessions are stateless, as session management is typically off-loaded to the client side as well.  In Java implementation, memory consumption and CPU load is increased proportionally to number of concurrent sessions. In JS, all calls are served in a single-threaded event loop. Thus no new context is created for each new session, which reduces memory consumption dramatically.  These same features, which make JavaScript superscalar in heavy load server systems, makes it suitable for low-end embedded systems as well. Client side session management and asynchronous calls both makes your embedded implementation more lightweight. 

Of course, JavaScript is not suitable for the most time-critical sections of your code, help of other languages is needed for that. However, real-time requirements typically covers only small fraction of the whole code base. Integrating external native functions calls is much easier with JavaScript than in Java. Last but not least, JavaScript integrates with your web UI by nature, yet another reason why to choose JS over Java.

My recommendation; implement real-time and performance critical parts of your embedded code with just plain C, and do the rest with JavaScript. This way you get both the performance and productivity at once.