I'm not sure if this is exactly what you mean, but I remember reading awhile back about GWT (Google Web Toolkit). I've never actually used it, but from what I hear you basically write all your code in Java, and it compiles into optimized, cross-browser Javascript. Basically it allows you to build and debug an application with a true IDE and programming language, then just plop the generated Javascript into your site.
Actually, now that I've read about it since starting this comment, it's not at all what you need, but still kind of a cool concept. I guess they built GMail and Google Reader with it. Anyway, here's the page about it and a sample Mail application built with it:
This seems like it might be the best thing that's currently available, but the JS interpreter is in Java.
http://appjet.com/download
I haven't tried it yet, but I keep hoping that someone will come along and do this well. I've considered doing it myself several times, based on the Mozilla SpiderMonkey JS interpreter.
Wow, AppJet is pretty cool, but not quite what I want. It looks like a slick PHP replacement, but it still seems to emphasize manually writing the HTML response with a series of print statements.
For example, in the sample code, the "storage" and "StorableObject" objects only exist in the serverside JavaScript engine. The HTML response sent to the browser doesn't even contain a single line of JavaScript, not to mention these objects.
What I want is something that automatically captures the state of the serverside JavaScript engine and serializes it to the HTML response such that when the browser reads it, the clientside JavaScript engine is initialized to the same state the serverside engine finished with. This provides a sort of seamless portability where the code you write for the server *is* the code you write for the client.
Anyway, it actually seems rather straightforward to do what I want -- there must plenty of open-source JavaScript engines that could be encapsulated for serverside use. And if we can use the exact same engine as is actually in the browser (perhaps the Firefox JavaScript engine), all the better.
Furthermore, the serialization format is really quite straightforward: at the end of the serverside script just iterate across all global JavaScript classes objects and spit out as JavaScript. Then call the "onload" handler when done.
2:55 PM
For Expensify I'm finding that I can't avoid coding in half a dozen languages simultaneously. At any point in time I will have active windows in C++, PHP, HTML, JavaScript, CSS... and... English. Half a dozen. Anyway, it's a nuisance and I'd like to consolidate.
In particular, I don't like how I generate and manipulate HTML in two places, with two different languages: PHP and JavaScript. PHP spits out a bunch of HTML, along with a bunch of JavaScript to manipulate that HTML via the DOM. It generally works OK, but I'm finding that I generally end up writing the same code twice. Not exactly, but enough to be annoying.
Consider the case of a dynamic page, like a web-based email reader. Something where there's a ton of data that is transformed into HTML in some sophisticated way. There's a range of ways to do it: Web 1.0 way: Read everything into PHP memory, process, output into static HTML with links. That works fine, except every time you do anything you need to ask the server to regenerate the page. Which leads to: Web 2.0 way: Read everything into JavaScript memory, process, output into dynamic DOM. This lets the browser do everything locally and avoid asking the server unless it's really necessary. But it has a downside: when the page loads it's completely blank while the JavaScript does its thing. (Similarly, if the browser doesn't support JavaScript, it's just dead.)
As a result, I'd like is some combination of the two where the same code and execution engine is used on both the server *and* client. Then the process would go like:
1) Server reads everything into server-side JavaScript memory
2) Server generates HTML DOM according to whatever logic
3) Server serializes the entire state of the page -- both the HTML DOM as well as the JavaScript VM -- into a big HTML/JavaScript blob.
4) The browser deserializes this blob straight into the HTML DOM and JavaScript VM -- without any big "onload" handler that builds the page from scratch.
5) The exact same code that was initially used by the server to generate the page is used by the browser to manipulate that page.
Make sense? So rather than having two sets of HTML modification code (PHP to generate it, JavaScript to manipulate it), have just one set of code that is run on both the client and server.
And to top it all off, if the browser doesn't have JavaScript, it'll still get a fully-formed HTML page.
In this model, the programmer wouldn't even think of "generating an HTML page with associated JavaScript". Rather, you'd think of building a page up using a series of JavaScript, CSS, HTML, database, and other resources, and then just calling "document.serializeToBrowser()" or something when the page is in a state that you want to send to the user.
Does something like this exist? I see lots of stuff up on Wikipedia, but none of it quite fits the bill.
-david
posted by David Barrett at 3:18 AM on Dec 17, 2008
"Christmas Wish: ServerSide JavaScript"
3 Comments -
I'm not sure if this is exactly what you mean, but I remember reading awhile back about GWT (Google Web Toolkit). I've never actually used it, but from what I hear you basically write all your code in Java, and it compiles into optimized, cross-browser Javascript. Basically it allows you to build and debug an application with a true IDE and programming language, then just plop the generated Javascript into your site.
Actually, now that I've read about it since starting this comment, it's not at all what you need, but still kind of a cool concept. I guess they built GMail and Google Reader with it. Anyway, here's the page about it and a sample Mail application built with it:
GWT
Mail sample
9:53 AM
This seems like it might be the best thing that's currently available, but the JS interpreter is in Java.
http://appjet.com/download
I haven't tried it yet, but I keep hoping that someone will come along and do this well. I've considered doing it myself several times, based on the Mozilla SpiderMonkey JS interpreter.
9:52 PM
Wow, AppJet is pretty cool, but not quite what I want. It looks like a slick PHP replacement, but it still seems to emphasize manually writing the HTML response with a series of print statements.
For example, in the sample code, the "storage" and "StorableObject" objects only exist in the serverside JavaScript engine. The HTML response sent to the browser doesn't even contain a single line of JavaScript, not to mention these objects.
What I want is something that automatically captures the state of the serverside JavaScript engine and serializes it to the HTML response such that when the browser reads it, the clientside JavaScript engine is initialized to the same state the serverside engine finished with. This provides a sort of seamless portability where the code you write for the server *is* the code you write for the client.
Anyway, it actually seems rather straightforward to do what I want -- there must plenty of open-source JavaScript engines that could be encapsulated for serverside use. And if we can use the exact same engine as is actually in the browser (perhaps the Firefox JavaScript engine), all the better.
Furthermore, the serialization format is really quite straightforward: at the end of the serverside script just iterate across all global JavaScript classes objects and spit out as JavaScript. Then call the "onload" handler when done.
2:55 PM