4 ms·

Jaxer: The AJAX Server

16 points by luccastera 19y ago

nreece 19y ago
Reminds of classic ASP, which could actually run JScript on the client as well as the server. However, eventually, this technique results in a spaghetti of UI, logic and DB code - all in one place. Ideally, these tiers should not be tightly-coupled.
- LogicHoleFlaw 19y ago
  If we can keep just the UI in the Jaxer<->Browser world with logic and DB elsewhere, then this problem may be alleviated. I think that directly manipulating the DOM on the server, rather than working with raw HTML is the big win. Having the client and the server seeing eye-to-eye on the logical representation of the document being transmitted removes one of the many impedance mismatches in web programming.
- tx 19y ago
  Agreed. It also reminds me of current ASP.NET where you can manipulate DOM (as long as it's marked with runat=server) as well, only with ASP.NET you also get super-powers of .NET runtime. To me it sounds like a bunch of browser/JavaScript dudes are trying to write server-side software, being unaware of how it must be properly written. Seeing SQL surrounded by HTML tags is so late 90s... The real gains, however, will happen when we'll be able to do it exactly backwards: run typical server-side code (blessed with rich runtime) inside of the browser. Browser's DOM (runtime) sucks. This is why there are so many browser-side runtimes being developed right now: Flex/Silerlight/JavaFX. Aptana got it wrong.
LogicHoleFlaw 19y ago
Oh, this is very clever. It's a mozilla-based server-side DOM+Javascript implementation which mediates between a client browser and a backend http server. So you can do DOM manipulation and Javascript processing on the server, the client, or both. It supports connecting to local and remote web services so you can leverage your own backend or an external third-party site. And you can manipulate that DOM before sending the data back to your client! Interesting, very interesting. It sounds promising as a way to tightly couple your server processing to your client display. Transparently calling between the server and the client is an interesting approach. My big concern is adding what seems like just another layer in your server stack. Aptana seems to think that Jaxer can replace other server-side technologies like PHP or RoR, but I'm not convinced. I also think that tightly interweaving your server and client could generate some massively ugly code and nearly unmaintainable codebases. Proper separation of concerns could be very tricky. Now if they'll just get it running on Linux maybe I can check it out.
tlrobinson 19y ago
I've been experimenting with using Rhino (Mozilla's JavaScript interpreter written in Java) on top of Java servlets (Tomcat, in my case). After working through a few issues it's working pretty well. You can even compile JavaScript to Java bytecode for better performance. Rhino is great because it lets you use all the zillions of Java libraries directly from JavaScript without the Java... dynamic typing, no compilation, etc. I can do things like: importPackage(Package.java.io); var writer = new FileWriter("hello.txt"); writer.write("Hello world!"); writer.close();
- kirubakaran 19y ago
  "After working through a few issues it's working pretty well." Can you please elaborate so that we can learn from your experience?
  - tlrobinson 19y ago
    Mostly silly Java things like classpath issues. Also, to get importPackage() you need to do: Scriptable scope = new ImporterTopLevel(context); instead of: Scriptable scope = context.initStandardObjects(); But now I'm having problems getting John Resig's env.js (a browser environment emulator) working because it uses getters and setters, which are new to Rhino 1.6R7. I thought I was using the latest version (it's the one in both JAVA_HOME/jre/lib/ext/js.jar and TOMCAT_HOME/shared/lib/js.jar)
    - kirubakaran 19y ago
      Thanks. I don't know Java. So will using Rhino require me to learn at least some?
      - tlrobinson 19y ago
        Yeah it helps to know a little Java to get it up and running, but you just need a little glue to get Rhino talking to the servlet and vice versa. Plus if you want to use the Java libraries from JavaScript you at least need to be familiar with the APIs (or know how to look them up in the javadocs) Take a look at Helma if you don't want to deal with all that, it uses Rhino: http://helma.org/ http://helma.org/
thomasfl 19y ago
Jaxer could be great if someone just made a decent MVC framework and used jaxer for html templates. It's worth to have a look at TrimJunction, a JavaScript port of Rails implemented in rhino http://code.google.com/p/trimpath/wiki/TrimJunction http://code.google.com/p/trimpath/wiki/TrimJunction In my opinion, ruby code is way more readable than javascript. Here's a direct comparison of a rails and a junction app http://code.google.com/p/trimpath/wiki/RubyRailsVsJavaScriptJunction http://code.google.com/p/trimpath/wiki/RubyRailsVsJavaScript...
edw519 19y ago
How does this affect performance? I don't see any mention of unnecessary round trips.

16 points by luccastera 19y ago

Reminds of classic ASP, which could actually run JScript on the client as well as the server. However, eventually, this technique results in a spaghetti of UI, logic and DB code - all in one place. Ideally, these tiers should not be tightly-coupled.

LogicHoleFlaw 19y ago
If we can keep just the UI in the Jaxer<->Browser world with logic and DB elsewhere, then this problem may be alleviated. I think that directly manipulating the DOM on the server, rather than working with raw HTML is the big win. Having the client and the server seeing eye-to-eye on the logical representation of the document being transmitted removes one of the many impedance mismatches in web programming.
tx 19y ago
Agreed. It also reminds me of current ASP.NET where you can manipulate DOM (as long as it's marked with runat=server) as well, only with ASP.NET you also get super-powers of .NET runtime. To me it sounds like a bunch of browser/JavaScript dudes are trying to write server-side software, being unaware of how it must be properly written. Seeing SQL surrounded by HTML tags is so late 90s... The real gains, however, will happen when we'll be able to do it exactly backwards: run typical server-side code (blessed with rich runtime) inside of the browser. Browser's DOM (runtime) sucks. This is why there are so many browser-side runtimes being developed right now: Flex/Silerlight/JavaFX. Aptana got it wrong.

LogicHoleFlaw 19y ago

Oh, this is very clever. It's a mozilla-based server-side DOM+Javascript implementation which mediates between a client browser and a backend http server. So you can do DOM manipulation and Javascript processing on the server, the client, or both. It supports connecting to local and remote web services so you can leverage your own backend or an external third-party site. And you can manipulate that DOM before sending the data back to your client! Interesting, very interesting. It sounds promising as a way to tightly couple your server processing to your client display. Transparently calling between the server and the client is an interesting approach. My big concern is adding what seems like just another layer in your server stack. Aptana seems to think that Jaxer can replace other server-side technologies like PHP or RoR, but I'm not convinced. I also think that tightly interweaving your server and client could generate some massively ugly code and nearly unmaintainable codebases. Proper separation of concerns could be very tricky. Now if they'll just get it running on Linux maybe I can check it out.

tlrobinson 19y ago

I've been experimenting with using Rhino (Mozilla's JavaScript interpreter written in Java) on top of Java servlets (Tomcat, in my case). After working through a few issues it's working pretty well. You can even compile JavaScript to Java bytecode for better performance. Rhino is great because it lets you use all the zillions of Java libraries directly from JavaScript without the Java... dynamic typing, no compilation, etc. I can do things like: importPackage(Package.java.io); var writer = new FileWriter("hello.txt"); writer.write("Hello world!"); writer.close();

kirubakaran 19y ago
"After working through a few issues it's working pretty well." Can you please elaborate so that we can learn from your experience?
- tlrobinson 19y ago
  Mostly silly Java things like classpath issues. Also, to get importPackage() you need to do: Scriptable scope = new ImporterTopLevel(context); instead of: Scriptable scope = context.initStandardObjects(); But now I'm having problems getting John Resig's env.js (a browser environment emulator) working because it uses getters and setters, which are new to Rhino 1.6R7. I thought I was using the latest version (it's the one in both JAVA_HOME/jre/lib/ext/js.jar and TOMCAT_HOME/shared/lib/js.jar)
  - kirubakaran 19y ago
    Thanks. I don't know Java. So will using Rhino require me to learn at least some?
    - tlrobinson 19y ago
      Yeah it helps to know a little Java to get it up and running, but you just need a little glue to get Rhino talking to the servlet and vice versa. Plus if you want to use the Java libraries from JavaScript you at least need to be familiar with the APIs (or know how to look them up in the javadocs) Take a look at Helma if you don't want to deal with all that, it uses Rhino: http://helma.org/ http://helma.org/

thomasfl 19y ago

Jaxer could be great if someone just made a decent MVC framework and used jaxer for html templates. It's worth to have a look at TrimJunction, a JavaScript port of Rails implemented in rhino http://code.google.com/p/trimpath/wiki/TrimJunction http://code.google.com/p/trimpath/wiki/TrimJunction In my opinion, ruby code is way more readable than javascript. Here's a direct comparison of a rails and a junction app http://code.google.com/p/trimpath/wiki/RubyRailsVsJavaScriptJunction http://code.google.com/p/trimpath/wiki/RubyRailsVsJavaScript...

edw519 19y ago

How does this affect performance? I don't see any mention of unnecessary round trips.