Comments on: Volta, GWT and leaky abstractions http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/ because there are few things that are less logical than business logic Mon, 19 Dec 2011 16:13:58 +0000 hourly 1 http://wordpress.org/?v=3.3 By: James http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/comment-page-1/#comment-2294 James Sun, 03 Feb 2008 22:50:59 +0000 http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/#comment-2294 @Bruce: You've clarified a point that I think I could possibly have been a bit clearer about myself. I'm not intending to be anti-GWT/Volta/RJS here so much as pro-JavaScript. As you say, actual JavaScript objects, via JSNI or however, will help to fill in the gaps and I quite agree. @Mats/@A_min: see my response to Bruce. While it is possible to do a lot in GWT/Volta, and perhaps most things, IMO you are doing yourselves a disservice if you hide from the raw JavaScript aspect of it altogether. The fact remains that there will be gaps and cases that it doesn't cover where you will need to resort to JavaScript to do what you need to do. Besides, as I said, JavaScript isn't quite the monster that we tend to think of it as being. @Bruce: You’ve clarified a point that I think I could possibly have been a bit clearer about myself. I’m not intending to be anti-GWT/Volta/RJS here so much as pro-JavaScript. As you say, actual JavaScript objects, via JSNI or however, will help to fill in the gaps and I quite agree.

@Mats/@A_min: see my response to Bruce. While it is possible to do a lot in GWT/Volta, and perhaps most things, IMO you are doing yourselves a disservice if you hide from the raw JavaScript aspect of it altogether. The fact remains that there will be gaps and cases that it doesn’t cover where you will need to resort to JavaScript to do what you need to do. Besides, as I said, JavaScript isn’t quite the monster that we tend to think of it as being.

]]> By: Bruce Johnson http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/comment-page-1/#comment-2276 Bruce Johnson Fri, 01 Feb 2008 16:43:19 +0000 http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/#comment-2276 GWT is indeed a leaky abstraction. This is the case both because (1) all abstractions leak, and (2) we designed GWT that way on purpose. GWT aims to provide lots of leverage around the problem of building complex, portable Ajax code for browsers. But that is very intentionally not the same thing as trying to enforce some sort of idealized walled garden, pretending that it isn't really a browser underneath. That would be hopelessly unrealistic and probably not even in the developer's best interest. What if a hot new plug-in comes out (e.g. Google Gears)? You need to make it easy to use any browser technology directly from a GWT code base. That's the reason for GWT's JavaScript Native Interface (JSNI) and its special treatment of the JavaScriptObject class as a zero-overhead handle to actual JS objects. We like to think this philosophy provides the best of both worlds: easy interop with handwritten JavaScript, yet highly optimized compiled JavaScript code. (Check out the JS code produced by the latest versions of the GWT compiler to see just how far it goes optimizing Java source.) GWT is indeed a leaky abstraction. This is the case both because (1) all abstractions leak, and (2) we designed GWT that way on purpose.

GWT aims to provide lots of leverage around the problem of building complex, portable Ajax code for browsers. But that is very intentionally not the same thing as trying to enforce some sort of idealized walled garden, pretending that it isn’t really a browser underneath. That would be hopelessly unrealistic and probably not even in the developer’s best interest. What if a hot new plug-in comes out (e.g. Google Gears)? You need to make it easy to use any browser technology directly from a GWT code base. That’s the reason for GWT’s JavaScript Native Interface (JSNI) and its special treatment of the JavaScriptObject class as a zero-overhead handle to actual JS objects.

We like to think this philosophy provides the best of both worlds: easy interop with handwritten JavaScript, yet highly optimized compiled JavaScript code. (Check out the JS code produced by the latest versions of the GWT compiler to see just how far it goes optimizing Java source.)

]]> By: A_min http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/comment-page-1/#comment-2256 A_min Tue, 29 Jan 2008 03:05:38 +0000 http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/#comment-2256 I believe, that GWT will go being great ... there is seriously no need for us to think how to let browsers execute ... Lets just focus more on the logic, let the browsers world become an independent feild, an abstracted one ... Let the computer do this job Moreover, I must tell JavaScript experts that GWT and others will start making web browsers techonologies more sophisticated and harder to implement, this is mainly because GWT will become very famous soon... This is a revolution for java again ... Thanks to Google ... I believe, that GWT will go being great … there is seriously no need for us to think how to let browsers execute … Lets just focus more on the logic, let the browsers world become an independent feild, an abstracted one … Let the computer do this job

Moreover, I must tell JavaScript experts that GWT and others will start making web browsers techonologies more sophisticated and harder to implement, this is mainly because GWT will become very famous soon… This is a revolution for java again … Thanks to Google …

]]> By: Mats Helander http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/comment-page-1/#comment-2127 Mats Helander Thu, 13 Dec 2007 20:12:13 +0000 http://jamesmckay.net/2007/12/volta-gwt-and-leaky-abstractions/#comment-2127 "I am also sceptical of the benefit of being able to move parts of your application between the client and the server. Far from making things simpler, this could introduce a whole new can of worms if it is not carefully thought out, partly in terms of performance, particularly if you end up with a very chatty interface between them," Well, the risk is certainly there, agreed. But you also have the potential to build a lot less chatty, more high performing applications. Before, as soon as the client needed any interesting computation done it would have to call the server for this...well, at least it would if I had coded it, since wild horses couldn't make me attempt implementing complex computations in JavaScript. Yet again. But now I can write the computations in C# but have them execute as JavaScript on the client. This means the client won't have to call back to the server anymore, making for a less chatty and probably more responsive app - and potentially more high performing since it can then utilize the client's idle supercomputer instead of further overloading a poor server. /Mats “I am also sceptical of the benefit of being able to move parts of your application between the client and the server. Far from making things simpler, this could introduce a whole new can of worms if it is not carefully thought out, partly in terms of performance, particularly if you end up with a very chatty interface between them,”

Well, the risk is certainly there, agreed. But you also have the potential to build a lot less chatty, more high performing applications.

Before, as soon as the client needed any interesting computation done it would have to call the server for this…well, at least it would if I had coded it, since wild horses couldn’t make me attempt implementing complex computations in JavaScript. Yet again.

But now I can write the computations in C# but have them execute as JavaScript on the client. This means the client won’t have to call back to the server anymore, making for a less chatty and probably more responsive app – and potentially more high performing since it can then utilize the client’s idle supercomputer instead of further overloading a poor server.

/Mats

]]>