Still need to get the packaging complete but I hope to release a new version of JNEXT some day next week. Meanwhile here's a sneak preview of what you can do:
<script language="JavaScript">
myDB.query( "select * from ex" );
var row;
while ( (row = myDB.getRow()) != null )
{
strHTML += "<tr>";
for (var i=0; i<row.length; i++)
{
strHTML += "<td>" + row[ i ] + "</td>";
}
strHTML += "</tr>";
}
</script>
[ 2 comments ] ( 32 views ) | permalink |
( 3 / 753 )I thought of implementing Mac OS/X support first but getting my hands on a Mac OS/X system has been delayed... if there are any OS/X developers out there that want to take on the task - please contact me.
Anyway, the next step is creating an extension for database support, which will include all major databases. After that, support for additional socket types.
Good things are coming your way :-)
[ add comment ] ( 5 views ) | permalink |
( 3 / 934 )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:
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.
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.
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.
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 ] ( 89 views ) | permalink |
( 3 / 1308 )Whew - documentation and packaging have been completed (at the expense of my sleeping hours...)
Anyway, version 1.0.5 contains many improvements and the sources contain everything for anyone who wishes to write new extensions.
[ add comment ] ( 4 views ) | permalink |
( 3 / 1072 )Main updates in this version:
Support for using JNEXT simultaneously in multiple browser tabs
POP3 Client sample to demonstrate the simplicity of writing applications with JNEXT
Source code: common framework for writing JNEXT plugins + a filereader sample that demonstrates how you can quickly use the plugin framework to write your own native extensions.
I hope to release this within a day or two - version has been tested - all that is left now is the packaging bureaucracy...
[ add comment ] ( 3 views ) | permalink |
( 3 / 691 )
Calendar
