A couple of things we got wrong ten years ago

7 thoughts on “A couple of things we got wrong ten years ago”

1. Eric,

   Well, what I really want in 2016 is a Java powered flying car :)

   -Dustin

   Répondre

2. Kurt,

   Yes, these are exactly the kind of things I have in mind…

   I think that you could also use the same kind of principles than Pylons in Python and route HTTP requests to object methods. Being a XSLT fan, I would suggest to use XSLT as a templating language and get a nice and competitive framework!

   Eric

   Répondre

3. Damien,

   The JavaScript on Rails framework that I am dreaming of wouldn’t be especially targeted to rookie developers!

   That being said, you are raising a very valid point and many developers badly need to be trained on Web technologies and especially on HTTP. In fact, this feeling has been my initial motivation for publishing « Professional Web 2.0 Programming« .

   I’ll also add that there are probably more benefits in using the same language client and server side than copy/pasting documents! On the contrary, I’d even say that the main benefit is to avoid copy/pasting like we do with algorithms if we don’t have the same language…

   Eric

   Répondre

4. I believe that early on the Netscape IPlanet Server did have a quasi-JavaScripty sort of language that never really managed to catch on. While I agree (somewhat) with the statement on XForms (and I’m trying to promote it pretty heavily), I think that a solid JavaScript framework on the server actually isn’t all that bad an idea – if your idea of JavaScript is more closely modeled on its ability to model with hashed templates, open object prototyping and work within a framework of extant server objects than it is in the script-kiddie world of animating a rollover. Moreover, JavaScript can be compiled quite readily, which is where the speed benefits derive from, not the language itself (if you can get around the sometimes byzantine forms of Perl or PHP, then JavaScript’s a piece of cake!)

   For instance, a typical contemporary server side JavaScript might look something like:

   Servelet.getInstance({
   paint:function(){
   var authState = (new Authenticator()).authenticate(
   Request.params.name,Request.params.password);
   if (authState){
   Response.write(<div>
   	<h1>You're in!</h1>
   	<p>Hello, World!</p>
   </div>);
   else {
   Response.write(<div>
   	<h1>Fat Chance</h1>
   	<p>Go away!!</p>
   </div>);
   }
   
   });

   This assumes that you’ve passed your functionality as an object instance (so you could conceivably use JSON here, though it’d be an incredible security hole) and that you have Request, Response, and Authenticate objects available (not to mention a little E4X, though that’s not a strict requirement.

   JavaScript is used as a binding and glue language, and is quite good in both of those roles. I don’t necessarily see this being any worse than PHP, and the syntax is closer to the C++/Java model than Ruby, Python, or PHP.

   Répondre

5. One thing which bothers me with the same language on server and client side is that it confuses a great deal rookie developers. Not that rookies can’t evolve, but we have to take in account that most of the web applications today are not developed by « real developers ». At the beginning it’s already hard to make them understand that there are two completely unrelated environments, client and servers, which communicate only with small pieces of information. If now, you put the same language, possibly mixed in the same container (think an ASP page using VBScript as client side scripting), it’s going to be a nightmare too coach newbies. Another problem is application maintenance (most web application are throw away, but we see nonetheless 6 or 7 years all web applications happily maintained and running); when enhancing or fixing a software, one key point is to establish quickly your mental map of the source: having copied and pasted code in several, dealing with two completely unrelated environments, just confuses the reading.

   Répondre

6. Dustin,

   The thing I really don’t like about applets is that they break the web architecture still more than bad Ajax applications do!

   Anyway, we’ll see in 2016 if one of us was right…

   Eric

   Répondre

7. I disagree with you. I think Java on the client side will start to really expand, and running JavaScript on the server side sounds only minimally beneficial.

   10 years ago everyone complained about how slow Java was on the client side, and they were right, but these days nobody complains about it (read: Moore’s Law). I use Eclipse every day, and I think it’s a great app. Azureus is another client side Java app that works great. In fact their latest version, Zudeo (http://www.zudeo.com/az-web/app), installs via Java Web Start, one of the first real apps I’ve encountered to use JWS, and it is incredibly slick. I think we’ll likely see more apps like this. Just looking at my dock, I’ve got JEdit, AquaData Studio, Oxygen XML Editor, and Oracle SQL Developer. That’s (with Eclipse and Zudeo) 7 java apps that I use every day! I realize these are mostly developer apps, but I think as Linux UIs get better and better, more people will substitute Linux for Windows and it will make sense for companies to make consumer apps in Java, like the new Azureus, since it can run anywhere. JWS is great because all of the installation/updates/distribution framework is already there, and easy to use.

   As for JavaScript on the server side. Sounds alright with me if someone builds a nice framework around it like Rails or Grails (as you said), but I don’t see any real need for it to happen. In fact, if XForms ever becomes a reality, it will pretty much do away with JavaScript on the client side (except in special cases). I admit a bias though – JavaScript just seems like a mess to me, and doing a large scale project with it sounds awful.

   Just my 2 cents,
   -Dustin

   Répondre