It’s not fully baked yet, but let me take a break from coding to … squee! You have no idea how excited I am right now.
Back in February, I blogged about nsjsapi, an AOLserver module that makes the SpiderMonkey JavaScript interpreter (written in C) available to Tcl. Then, in July, John Resig blogged about env.js, which he used to load jQuery under the Rhino JavaScript interpreter (written in Java). env.js is neat because it’s a JavaScript implementation of a basic browser and DOM environment which isn’t provided by either SpiderMonkey or Rhino.
However, env.js assumes its running under Rhino, or at least has all the java.* and javax.* and org.w3c.dom.* APIs available, so it doesn’t completely work under SpiderMonkey. So, I’ve set out to implement all those missing bits in JavaScript, in nsjsapi.js. (Yes, I know I’m crazy …)
After a few days of furious coding and much head-desking, I’ve gotten far enough that I can do this from an AOLserver control port:
nscp 1> set js [js create] js0x88e0838 nscp 2> js load $js /home/dossy/htdocs/js/nsjsapi.js undefined nscp 3> js load $js /home/dossy/htdocs/js/env.js undefined nscp 4> js load $js /home/dossy/htdocs/js/jquery-1.2.1.js undefined nscp 5> js eval $js {jQuery.fn.toString = DOMNodeList.prototype.toString; true;} true nscp 6> js eval $js {window.location = 'test/index.html';} undefined nscp 7> js eval $js {$('body').html()} <div><span id='foo'>This is a test.</span></div> nscp 8> js eval $js {$('div').append('<span>Hello world!</span>')} [ <div> ] nscp 9> js eval $js {$('body').html()} <div><span id='foo'>This is a test.</span><span>Hello world!</span></div>
I guess this doesn’t seem like much of an accomplishment, but it’s a huge first step towards being able to do actual JS-based server-side web development under AOLserver.
I want to iron out a strange crash bug when the JS interp. is destroyed via [js destroy], and complete the file I/O stub that isn’t finished yet, then check in nsjsapi.js. I plan to get this done in time for my talk at jQueryCamp07 this weekend.
Tags: AOLserver, jQuery, JavaScript, nsjsapi
OMG, Dossy, this is great, spectacular, wonderful !!!!
Please keep us posted about this in your blog.
I look forward to the day when I can write real server side tcl api to generate stuff like http://extjs.com/deploy/dev/examples with ExtJs.
Hamilton: ExtJS is a fantastic JS UI library, but I’m not sure what benefit there would be from executing it on the server side? Could you explain what you were thinking of?
Hi Dossy,
I have two reasons for being excited about nsjsapi and server side javascript :
1) To answer your question above. Javascript for many back-end developers is still daunting. A tcl api based on server side implementation of javascript like nsjsapi “might” make it less intimidating and easier to develop with frameworks like jQuery, ExtJS or Prototype specially among OpenACS developers. It may also make it relatively easier to write tests for javascript based web applications using tcl.
2) Performance.
As an example, I helped program a facebook application at Solutiongrove using a very nice javascript library called jsviz that generates force directed graphs. The app (http://apps.facebook.com/friendwebs/) generates force directed graphs of your friends in facebook.
One thing we noticed is that the performance of the generated graph highly depends on not only the browser you are using but also on the PC that you are using. The faster your pc, the better the performance.
Granted that we could probably speed things up by further tweaking the javascript code or rethinking the implementation, I would always wonder if performance for users who are using less powerful machines would improve if some of the calculations to generate the graph were performed on the server instead of on the web browser.
Good luck on your talk and more power.
Best,
Hamilton
Hamilton: Interesting–JavaScript is daunting? More so than, say, Tcl? As a web-based developer, at least a basic understanding of HTML and JavaScript are a minimum requirement regardless of whether you do front-end or back-end work. The same can’t be said for Tcl, or even PHP or ASP.NET or Java or anything else.
With respect to performance, I’m not convinced that JavaScript is the most performant language, nor whether either SpiderMonkey or Rhino are the most efficient implementations, either. As you point out, an application’s performance (typically) has little to do with the technology stack. Efficient application design (almost always) trumps the variations in performance between technologies.
— JavaScript is daunting? More so than, say, Tcl?
Hehe, I’d say they’re equally daunting :-)
I kinda envy the Java developers because they have GWT. They can do ajax with a syntax they are familiar with.
I think having something similar for TCL on AOLserver will add value to it.
I know we won’t be winning over new users but it might make existing users who have invested time and effort to learning TCL on AOLserver happier.