Web clients and decentralization of processing power. 
Tuesday, October 2, 2007, 06:52 PM
Posted by Administrator
Recent technologies such as Adobe's AIR, Microsoft's SilverLight and Google Gears show an interesting (and in my opinion, welcome) trend in better utilizing the processing power of the desktop client. I've read articles praising the thin client model over the fat client model and also have seen articles advocating the fat client model, while debunking myths about the advantages of using thin clients. As is many times the case in these sort of arguments, the truth depends on the application, and the correct path is usually finding a correct balance of both methodologies. However, for a long time there was not much freedom to find that balance due to lack of client side technologies for powerful and stateful browser applications.

This is why I feel that the technologies mentioned above are finally a step in the right direction. So if we now have these tools, you then may ask why was JNEXT created ?

There are four main reasons:

  1. The first working version of JNEXT (it wasn't called that at the time) was written before any of these technologies was publicly available. Due to my involvement with other projects at the time, I just never got around to packaging it properly and making it publicly available.

  2. I suspect that at least one of the technologies mentioned have some sort of commercial agenda which will eventually conflict with interoperability (you can probably guess which), so there is a risk that using that technology, might limit the scope of your efforts to the confines of that agenda. JNEXT has no agenda other than offering developers more freedom to decide how to divide the processing load between the Web Client and Web Server.

  3. Simplicity. A turnoff for me in any technology is unnecessary complexity. JNEXT provides a fast learning curve for both using existing JavaScript native extensions (as can be seen by looking at the short sample in the home page) and developing new extensions. This again was influenced by my experience of time wasted understanding unnecessarily complex API's or searching for good samples.

  4. Another thing I dislike in frameworks is unnecessary bloat. With JNEXT, keeping a small footprint was an important factor. The size of the bridge component that connects JavaScript to the native code is 204K for the NPAPI version and 384K for the ActiveX version (in version 1.0.5). The size of the native extensions this bridge loads depends on how the native components are implemented but you only need to load the relevant extensions for your application's purpose. The size of the JavaScript extension framework is 3K with an addition of around 3K on average of JavaScript wrapper code for every new native extension.



I hope you'll find JNEXT helpful for your applications and hope enough developers will extend it with new and useful extensions. The goal is to give more power to developers and any contribution is always appreciated



[ 2 comments ] ( 73 views )   |  permalink  |   ( 2.9 / 60 )

<<First <Back | 1 | 2 | 3 | 4 | 5 | 6 | 7 | Next> Last>>