JavaScript, Node.JS and IOT

Posted On
Most of you know the old school approach on IOT and JavaScript (node.js etc.) that you can connect to a device using a serial port, wifi etc. from your computer and send the instructions. 

This is no longer the best solution for the next gen products.  As some of you already know, JXcore wraps the IO around the popular JavaScript engines and provides node.js application interface on many platforms. It's not that hard to expect JavaScript will be taking it's first citizen place on next gen smart products.

I'm personally a mini / tiny board collector and I do not see any reason not to run most of the logic / IO on the board instead having a need of external computer that uses the target device as a puppet.

Let's start with the mini boards. Some weeks ago, I received my new Raspberry Pi 2 with 4 cores in it's new cute box. Pi is one of the lots of other mini boards I have been buying last years. I do really appreciate the mini boards. They control my home media, central backup and I use them to develop apps on every possible screen and environment. 

I have to admit that the new Pi 2 has an amazing performance comparing to similar price boards (with a similar level of stability!). It didn't took much time compiling whole JXcore right from the beginning and I'm able to run my media server node.js app multi-threaded thanks to JXcore's multi-tasking capabilities and Pi 2's quad cores. I've to tell that it works really fast!

Raspberry Pi 2 cost me around 35-40 USD including the box, adapter etc. (no battery included) I feel like it's a reasonable price knowing the market range nowadays.  However, smart phones are also entering into the same price range with the mini boards and they do offer even more features. Most of the time, you don't even need to buy a smart phone to develop something though. Almost every single person around has a smart phone in their pockets, and probably a year or two old at their home. Even more, you can find a basic smart phone for 43 USD. It has a camera, touch screen, battery and more. There you have a fully featured IoT starter unit for a very small price. 

I was talking to Ugur (my partner from Nubisa Inc.) about the future of JavaScript, JXcore (node.js) and IoT's. As some of you already know, JXcore wraps the IO around the popular JavaScript engines and provides node.js application interface on many platforms including Android and iOS. Yes, you can run node apps on mobile devices and mini boards!

There you have your device for 40 USD that you can hack using JavaScript. JXcore works standalone on all the devices so the app you develop can perform many tricky tasks without requiring any connection to network or any external puppeting.  

How about the tiny boards?  i.e. An Arduino board with only 256KB or less flash memory. Check DukTape JavaScript engine for a starter. JXcore can work with multiple JavaScript engines. Although it's not just about the underlying JavaScript engine, still having a node.js framework with multiple JavaScript engine capabilities and a suitable engine for the task is a good start. I already took lots of hours of Sami (the creator of DukTape) and feel like we are in the good direction. I do see JXcore running on tiny boards.   

Intel's Edison brought lots of horse-power into tiny board concept. This horse power is more than enough to run JXcore entirely. Hopefully they will start advertising their horse power instead old school puppeting approaches. 

I do appreciate Microsoft will be offering Windows 10 on Pi 2 for free. Moreover, Qualcomm will be offering a very powerful board for Windows ARM. You will be running JavaScript node apps on Windows ARM using JXcore. No puppeting, no external dependencies. Isn't it nice ?

Stick with JavaScript, Node.JS, and JXcore!

[Read more]

Node.JS truly on Android and iOS

Posted On
Finally we've managed to put sample projects on Github for Android, and iOS. Android sample is a standalone 'hello world' project for Eclipse IDE. iOS sample is an actual Cordova/Phonegap plugin. Soon we are going to add Android support to this plugin too.

We are not planning to put an application designer etc. in front of JXcore. Indeed we are going to make the Cordova plugin as usable/stable as we can. Then, we leave it up to mobile developers and mobile platform owners to develop solutions using JXcore. We envision and design JXcore to be technology embeddable to any other solution while you can develop your mobile applications. 

Making Node.js run on mobile devices was a long and tricky process. The general opinion is 'Node.js' runs on Android because it has V8. V8 is Google, Google is Android... The fact is, yes, it's technically possible and you can even make it work after patching it at some level but Node.js's design is not suitable for embedding into another app. Node.js was initially considered for server environment as a standalone application. As a result, if you are planning to embed Node.js into your precious Android solution (or any other), the list below might give you an idea on what is awaiting you;

- Something went wrong with JavaScript, node instance ... Restart your App!
- Node.JS doesn't cleanup the memory on exit (why should it do that, it's a standalone process)
- Node.JS tends to exit 'process' for many situations. (your whole app!)
- You can not have more than a single instance of Node.JS
- It doesn't provide anything to interact with your JavaScript files under APK
- Are you a JNI expert ?

This list goes on. I'm not criticizing node.js. It perfectly does what it's designed to do. That's why JXcore exists and handles everything else for node.js on mobile.

On our journey, some people told us, don't use 'SpiderMonkey' go with 'JavascriptCore', while many others were supporting our decision. Why SpiderMonkey is the best choice available;

- It's as fast as V8 
- ASM.JS 
- Amazing support from SpiderMonkey team (which is a life saver)
- To make the whole node.js work, you need to patch the underlying JS engine, if you patch JavascriptCore, you should use it as a dynamic library (LGPL). Unfortunately, App Store doesn't allow you to do that!

We are at the beginning. There are lots of possibilities ahead of us.

Visit JXcore's Github repository and start hacking!
[Read more]

Now ASM.JS is available for Node.JS Applications

Posted On
ASM.JS, an extraordinarily optimizable, low-level subset of JavaScript. Now it's available for Node applications. The latest JXcore (Github) embeds SpiderMonkey in addition to V8 JavaScript engine. As you might know V8 was able to run ASM.JS codes without much problem but there was no optimization or performance gain in place (actually it is even slower). As a result, it never made any sense to use ASM.JS code on a Node.JS application.

Since JXcore has SpiderMonkey in place (in addition to V8), now it's time to show a basic sample.

Save the JavaScript lines below into asmjs.js file

function AsmJSFibonacci() {
  "use asm";

  function fib(n) {
    n = n | 0;
    var value = 1;
    var prev = 1;
    var i = 1;
    var t = 0;
    for (;
      (i | 0) < (n | 0); i = (i + 1) | 0) {
      t = prev;
      prev = value;
      value = (value + t) | 0;
    }
    return value | 0;
  }

  function many_fib(n) {
    n = n | 0;
    var i = 1;
    var total = 0;
    var calc = 0;
    var z = 0;
    var limit = 2000;
    for (; (z | 0) < (limit | 0); z = (z + 1) | 0) {
      for (; (i | 0) < (n | 0); i = (i + 1) | 0) {
        calc = fib((i | 0)) | 0;
        total = ((total | 0) + (calc | 0)) | 0;
        total = (total - 452433) | 0;
      }
      i = 1 | 0;
    }

    return total | 0;
  }

  return many_fib;
}

var asm_fib = AsmJSFibonacci();


var nfib = function (numMax) {
  var x;
  for (var i = 0, j = 1, k = 0; k < numMax; i = j, j = x, k++) {
    x = i + j;
  }

  return x;
};

var normal_fib = function (n) {
  var total = 0;
  var calc = 0;
  for (var z = 0; z < 2000; z++) {
    for (var i = 1; i < n; i++) {
      calc = nfib(i);
      total += calc;
      total -= 452433;
    }
  }

  return total;
};

var start = process.hrtime();
var res = asm_fib(34);
start = process.hrtime(start);
console.log("ASMJS Time", start, res);

start = process.hrtime();
res = normal_fib(34);
start = process.hrtime(start);
console.log("NORMAL Time", start, res);

And Run!
(you can run it with 'nodejs' or 'jxcore' using V8 engine though. But you should build 'jxcore' with 'spidermonkey' from the sources in order to see how it behaves with a proper ASM.JS support.

jxcore-spidermonkey build:
ASMJS Time [ 0, 1213238 ] 122000
NORMAL Time [ 0, 1909488 ] 122000

jxcore-v8 build:
ASMJS Time [ 0, 7572855 ] 122000
NORMAL Time [ 0, 2347491 ] 122000

Looks like ASM.JS & SpiderMonkey is the winner for the above sample. This is not a performance comparison indeed. There are already many performance comparisons available on ASM.JS performance.

You may want to ask 'what the heck is "require.withAsmJS" ? SpiderMonkey requires "compileAndGo" option enabled for an ASM.JS script. This is not a case for a normal Node.JS JavaScript since "compile" and "go" are two separate steps. For this reason, JXcore has a new addition to "require" interface for JavaScript files with ASM.JS Luke Wagner from SpiderMonkey told me this is no longer an issue. JXcore is updated accordingly. Simple 'require' works now. (sample code is also updated)
[Read more]

JXcore, What's going on?

Posted On
About 10 months ago, we forked Node.JS and started building JXcore. Many people wondered what in the world we were doing by forking Node.JS. We have a big vision and a unique view of how programmers will develop applications in the future. We started by breaking that vision into many pieces that are closely tied. Node.JS is the central pieces of that vision. In this article, I will try to explain some of those pieces that we have completed and some others we are currently working on.

Soon, JXcore will be open sourced under the same license as Node.JS. It's been almost 10 months since we first started patching Node.JS in order to support multithreaded logical instances under the same process. During this time, we changed a very large part of the project sources in order to implement several key features. As a result we re-structured some key parts of Node.JS right from the beginning.

I'm going to come back to re-structuring part later but let me first explain the differences between Node.JS and JXcore. Node.JS, as defined from the main repository, is an asynchronous (evented) IO framework on top of V8 JavaScript engine. JXcore is a fork of Node.JS with additional features including support for multiple JavaScript instances for Node apps (using different threads under the same process). Soon (very soon) JXcore will offer an alternative JavaScript engine other than V8. So you can either use V8 (versions) or the other engine(s).

Since Node.JS is built on top of V8, it is no surprise that it inherits some habits like multiple processes instead multiple threads for managing separate logical parts. I have to admit, although V8 operates multiple JavaScript instances / threads properly, I was surprised by the number of developers against the idea of multiple threads when we came up with the first beta months ago. I believe the initial reaction was mostly because of a misunderstanding (or misleading) on the way we described our multi-threading support. What we implemented was a capability to allow multiple separated logic instances benefiting from multiple cores, not making JavaScript work multi-threaded.

Another challenge facing Node.JS developers is the hosting situation. We believe the difficulty of hosting Node.JS applications is a major problem that needs to be addressed. I have years of .NET experience and in my opinion Node.JS is a powerful platform that you can develop enterprise level applications in a shorter time than ASP.NET. On the other hand, hosting an ASP.NET application requires less technical background and it is much smoother to manage. There are many hosting alternatives compared to hosting a Node.JS application and I'm not even comparing the cost of hosting Node versus ASP.NET. This has to change! Indeed, ASP.NET is around for almost a decade but there are technical reasons for the problems instead being around for a longer period of time.

Last month, we released a free Parallel Plesk Node.JS extension hoping to make Node.JS hosting options available to a larger audience and make it cost effective. The extension is getting better with the updates thanks to Plesk team and its users. Hopefully, small companies and the individual Node.JS developers will find these hosting options useful for their web applications.

In order to develop the Plesk extension, we implemented some key features to make it easier to host a Node.JS application (Multithreading, monitoring, system wide application configuration as you can limit CPU, memory etc) similar to hosting a PHP or ASP.NET application. Coming weeks, we will have an alternative approach to host Node.JS applications easier, and cost effective than ever.

NPM (Node Package Manager) hosts thousands of modules developed by individuals and companies to add additional features to Node. Indeed, NPM is one of coolest package managers. The growth rates of NPM modules is a clear proof. But there are problems not exactly caused by NPM rather how Node.JS have been evolving. There are many Node.JS applications still using version 0.6 and 0.8. Having different versions of V8 makes it almost impossible to develop and compile native Node modules once and for all. It is clear that some module developers may not follow the latest Node versions and keep their modules compatible. As most of the community knows, NPM now includes many outdated packages which would otherwise be very useful. Since we are going to open source JXcore with multiple JavaScript engine option, re-structuring the native module development was inevitable. 

Node.JS has it's own way of dealing with incompatible modules. If a native modules uses 'nan', it has a better chance to survive over multiple releases unless the module doesn't use some critical (non-standard) stuff from the JavaScript engine. And unfortunately, 'nan' may not handle multiple JavaScript engines or pre-compiled binaries per platform. Implementing 'nan' was a very clever hack. But it is still a hack. As the user base of Node.JS grows, a more proper solution must be implemented. In JXcore, we are in the process of completing an interface which will work with multiple JavaScript engines and still be compatible to multiple JavaScript instances per process.

Hopefully, the concept of multiple JavaScript engines will convince more enterprises transition to using Node. One of the key advantages of supporting multiple JavaScript engines is being able to deploy Node applications on mobile platforms. But we are thinking even further. We believe JavaScript will be the best choice for the Internet of Things as we already see some practical usages. We hope to make HTML, CSS, and JavaScript native citizens for all platforms.

As Node applications are deployed on mobile and embedded devices, programmers are faced with the challenge of protecting their JavaScript source code. One option is to "uglify" your source code and hope that nobody will try to extract your code. For many companies this is not even an option. That's one of the reasons why we implemented JXcore packaging feature which protects your source code and instantly creates a package that works on every platform. 

And mobile IDEs. Based on JXcore mobile, Node.JS will be a unique platform with its own IDEs working on mobile devices.  We want to make Node.JS application development easier from development to hosting for every level of developers.

Parts of what I described here is already available. Others will be released over the course of next few months. But this is only part of our overall vision. Stayed tuned for more...
[Read more]