JavaScript Language Abstractions

var p = Processing(CanvasElement);
p.size(100, 100);
p.background(0);
p.fill(255);
p.ellipse(50, 50, 50, 50);

Posted: December 6th, 2008

124 Comments (Show Comments)

1. Ross Boucher (December 6, 2008 at 2:11 am)

   I think Pyjamas and Objective-J have pretty different goals. Objective-J isn’t really about being Objective-C but in the browser. It’s about taking features we missed in the language, like dynamic messaging and classical inheritance, and adding them to javascript. It just happens that Objective-C had incredibly similar goals when it was created, so it was a natural fit for our needs. It’s still a strict superset of JS, and its impossible to write Obj-J code without knowing at least a little bit about plain ‘ole JS.

   On the other hand, other frameworks tend to do the same thing, if less dramatically. Prototype and Dojo both have facilities for classical inheritance, they just make it a library feature instead of a language feature. jQuery code is a bit like its own language too: I’ve never seen so many chained function calls in my life, and as someone who’s been doing JavaScript for years, it still confuses me :)

2. Azat Razetdinov (December 6, 2008 at 2:19 am)

   A link to http://www.joelonsoftware.com/articles/LeakyAbstractions.html would be convenient.

3. Jim Marion (December 6, 2008 at 2:20 am)

   John, I agree with you in the respect that hand written JavaScript, especially JavaScript written using a JavaScript abstraction library like jQuery is much more elegant and efficient, just as finely crafted, hand made furniture is much more elegant than mass produced fiber board furniture. When a purchaser of such furniture is considering a purchase, that person must consider the use and life of that furniture to determine if the mass produced version will satisfy his/her needs. Likewise, even though libraries like GWT and Oracle ADF Faces produce JavaScript that is not elegant (ugly in fact), is bloated, and does not cache well between page views, they do provide extreme productivity gains. For example, using JDeveloper with ADF Faces, a developer can drag and drop AJAX enabled components onto a page and get instant access to partial page rendering without writing a single line of code (Java, JavaScript, or otherwise). This allows the developer to focus on the business logic and data model, rather than the intricacies of the user interface. Personally, I prefer the performance benefits of a well written JavaScript UI, but it is hard to beat the productivity gains of a tool like Oracle’s JDeveloper with ADF Faces or Apache’s MyFaces.

4. Chris Frohoff (December 6, 2008 at 2:29 am)

   Though I highly value the ability to debug issues arising from leaky abstractions easily myself, even more important to me is the cross-pollination between languages and platforms; JavaScript’s (and jQuery’s) idioms and functional nature have really changed the way I think about and write code in other languages, and I wouldn’t trade that for anything but the most useful abstractions.

5. Ryan Doherty (December 6, 2008 at 3:24 am)

   I agree 100%. And I wrote something similar (though not as elegant and thoughtful) a while ago.

   This raises the issue again that many Java/whatever programmers don’t want to deal with the difficulties of web development. Using something like GWT saves them the time of learning HTML, CSS and JavaScript. Should they care if it gets the job done 99% of the time? From their perspective, web development is so impossibly frustrating and rudimentary, it’s considered beneath them.

   I’m all for writing JavaScript by hand and using a library, but it sometimes feels like a pointless argument. So many people just don’t care and would rather stick to their enterprise language of choice. I hate to be so pessimistic, but after the response to my blog post, it does feel pointless.

   http://tinyurl.com/2p5wcm

6. Josh Powell (December 6, 2008 at 4:08 am)

   It always amuses me when Java developers think they are superior to web developers. Java developers get just as lost in the web as a web developer does trying to program in Java. Different training, different priorities, different interactions in the code.

   The average Java developer doesn’t know well, and doesn’t want to know well, HTML, CSS, or javascript. It’s foreign to their experience and training. The GWT is perfect for a team comprised of java developers attempting to create a web application/web site.

   No one on those teams knows javascript well so they spend hours spinning their wheels trying to figure out the nicities like cross-browser compatibility. These teams would usually be much better served hiring a web developer then either trying to hack out their own javascript code or, doing the inevitable, and programming a java library that spits out javascript so they don’t have to deal with it. :p

7. horia314 (December 6, 2008 at 4:21 am)

   I don’t really know why people make {Python | Objective-J | X} to JavaScript compilers. It’s like translating assembly to C really. Javascript, especially in i’t 1.8 form (and probably more so in 2.0) is a beautiful and elegant language, simple enough to learn in a couple of days.

8. Tzury Bar Yochay (December 6, 2008 at 4:52 am)

   At the begining (back in 2002) I was using this kind of abstraction by developing asp.net application. Same principle of you use server side language which turns out as JavaScript objects at the client side.

   Observing the power, beauty and flexibility of JavaScript cause me to move from JavaScript “generators” to the JavaScript itself.

   Ever since, using the server mainly as the transport layer for the data, and doing rest of the job at the client.

9. Tom Robinson (December 6, 2008 at 5:01 am)

   disclaimer: I’m one of the Objective-J/Cappuccino/280slides.com devs.

   I think these technologies are trying to rectify the fact that HTML and the DOM were never meant to be application development platforms. They’re fundamentally document technologies (remember, the “D” in “DOM” is “document” and the “HT” in “HTML” is “hypertext”).

   Yes, people have figured out some best practices for developing applications directly on the DOM, but I’m not convinced they scale all that well to applications as complex as 280slides.com for example.

   Perhaps I’ve just never come across a very complex jQuery app. I would be interested in seeing an example of one if anyone knows of any.

10. kik (December 6, 2008 at 5:02 am)

    You may have added Rjs, used in ruby on rails, too (not to mention the javascript helpers).

    Even if I agree that those abstractions aren’t a good thing for a final product, it could have some interest during the development process.

    When I write server code for an application, I like to have a basic design to see approximately how it will feel. I won’t build a perfect design, just a simple layout and a few positioning. Designers will use all their art then, when I’ll sync to the repository.

    Abstract javascript generators can be used in the same fashion between server code developers and UX developers. Server code dev will just drop a few lines to be oriented by a very basic feeling of the UX, and then the UX dev will turn it in pure and elegant js.

    If you can write the js directly in your language (and the generated js will probably be better than what you would have done trying to do “quick and temporary js”), that’s a great benefit for a server code dev.

11. Tom Robinson (December 6, 2008 at 5:06 am)

    Also, as Ross points out, Objective-J is different than GWT and Pyjamas in that it’s a superset of JavaScript. If you know Objective-J then by definition you know JavaScript. This also helps with the leaky abstraction issue, as it’s trivial to do plain old JavaScript DOM manipulation, etc in Objective-J if you need to.

    If JavaScript had classical inheritance with dynamic method dispatching, and imports, we could have written Cappuccino in JavaScript. But it didn’t. Many of the techniques used in Cappuccino are simply not possible in pure JavaScript.

12. caustic (December 6, 2008 at 7:29 am)

    Growing up a large maintenable code base in JavaScript might be a nightmare. I have been coding somewhat complex application using ExtJS framework in a team of few developers. We all are not new to JavaScript, some members have years of JavaScript coding experience. Still thing get fragile very quickly and bugs proliferate. We are going to adopt GWT to see how it can impact our productivity.

13. James Tauber (December 6, 2008 at 8:19 am)

    I was the original developer of pyjamas. While I’m happy that what started out as simply a hack I did over a couple of days has been picked up by other developers, I personally am content just using jQuery. FWIW :-)

14. Anup (December 6, 2008 at 8:24 am)

    Nice post. In the .NET world, there is also Script# which compiles C# (or any .NET code, I think) into JavaScript instead of .NET IL code. It’s been around for a while and on a purely technical perspective it’s a really neat bit of technology (created by one of the guys that helped create ASP.NET)

    Agree with your general points and concerns about leaky abstractions. I can also see why people want to do it though; time to market, productivity (real or imagined, I have to say!) etc.

    In a team of predominantly good software (mid tier etc) developers, I am the only one who really does detailed CSS, JS stuff (jQuery, YUI, etc). But I think I am resigned to admit that the perceived productivity of abstractions is appealing, even if that sometimes results in lower code quality or poorer markup output. From a commercial perspective, there are always trade-offs, with the hope (and it’s usually just that) that once we get it out to market, we can then improve it later. Tough one, depending on lots of different circumstances, I guess…

15. Michael Jackson (December 6, 2008 at 9:00 am)

    @John: Great article. I’ve always felt that writing a language that really just writes (or interprets) another language under the hood can be dangerous. You lose the degree of control and understanding that you may need later on for tweaking or creating custom components.

    I think you can also make a similar argument against large JavaScript UI libraries. They may not be an abstraction of the language, but they definitely abstract away the details of the implementation which can be nice, but which can also come back to haunt you when something breaks.

16. John Smith (December 6, 2008 at 9:58 am)

    We started out writing in jquery extensively. We moved from rails + jquery/rjs to java + gwt as we were developing an application not a website, and as such, it was an order of magnitude larger and more complex than websites we had done in rails/jquery. When it got to a certain stage, we realised it was going to be impossible to maintain (as maintaining it was truly impossible – refactoring was horrid) and rewrote in gwt. Not only have we been more productive, we have the number only benefits of using java (eclipse, debugging, refactoring) which turned out to be invaluable for a large project.

    My take: for web sites use dynamic + jquery. For single page applications, use gwt.

17. Sean Catchpole (December 6, 2008 at 9:59 am)

    Abstraction provides a higher level of view allowing us to represent bigger ideas with less code. The lower language will always be faster and stronger, and the upper language more expressive and efficient. It is the job of the compiler to merge the two as seamlessly as possible. Javascript written by hand will always be faster, and given the importance of size and execution speed at the moment, that is probably the best choice. As browsers get faster at running javascript it may be more worth our time to program in languages that compile into both server and client side code. A webpage is really just the static interface for a remote application on the server. Well that’s my 2cents anyways.

18. Kwame (December 6, 2008 at 10:35 am)

    Even a good js library essentially replaces some functions so I am not sure it is fair to say gives someone new to js a good grasp. I had a very good working knowledge of js before I touched any framework and I really see it as a set of shortcuts, many or all of which I can code myself. If a framework were my first experience with js I would likely take the framework as the language itself and be utterly lost without it.

19. Matt (December 6, 2008 at 10:59 am)

    I’ve never worked with any of these abstractions, but it seems to me that the value would be eliminating duplication of code on both the server and the client. Any time I write something dynamic of any reasonable complexity, I end up writing essentially the same display logic in both the server-side template and the client side code. I hate the “flicker” that occurs when a page’s initial render depends on client-side processing. I prefer to send the entire page, as it should appear, as the initial HTML. It would be nice to call the same templating functions from both the client and the server. I’ve played around with using AJAX calls to generate the actual HTML, but that feels clunky.

20. Sébastien (December 6, 2008 at 11:32 am)

    I’d like to mention the Sugar language (http://github.com/sebastien/sugar/tree/master) which a is syntactic sugar front-end to JavaScript.

    Sugar was designed to minimize unnecessary and error-prone syntax (like the comma you always forget in a map, making blocks more compact, avoiding scoping problem in for loops, preservation of this, etc) and also provide an optional OOP layer.

    The core idea is that JavaScript semantics (prototypes, closures, objects-as-hashtables) are a very powerful base that is shadowed by a syntax that was not really designed but rather copied and then evolved on a “we need this” basis.

    Sugar is an attempt at designing a syntax from scratch around the JSsemantics — some people will like it, some people won’t, but I must say it’s been quite helpful to me and some others :)

    And, BTW, it also compiles to Python and ActionScript.

21. David Stamm (December 6, 2008 at 11:59 am)

    GWT has been out there for a few years, and I’m still waiting to hear a negative review from someone who has developed and deployed a real production web application with it. :)

    Of course, the platform’s creators and users appear to be mostly enterprise Java developers. If I were accustomed to the most advanced tool support in the software development universe, I would probably rave about it too.

    From GWT’s Google Code site:

    “Why does GWT support the Java programming language instead of language X? In a word, tools. There are lots of good Java tools.”

    JavaScript tooling is definitely ramping up, with products like Aptana and Eclipse Web Tools representing a substantial improvement over, say, Textpad. But given the industry emphasis on Ajax, I’m hopeful we’ll someday find ourselves using tools of the breadth and quality that the Java community has taken for granted for a decade.

22. Stephan Westen (December 6, 2008 at 1:46 pm)

    I wonder what the assembler or C guys said about abstractions 10 – 20 years ago.

23. Nicolas (December 6, 2008 at 2:53 pm)

    I particularly am not against using a more suitable language for doing web developement than JavaScript.
    However, I do believe than in most cases, people misunderstands the true potential of JavaScript and believes that their language can solve problems that arise from using JavaScript.

    JavaScript has prototypal inheritance. But it also has parasitical and pseudo classical inheritance, they’re all different patterns of inheritance, and you can change the way you code in order to use those patterns.

    All I want to say with this is that JavaScript is a lot more expressive than most people think. A lot more than Java at least (and Python arguably).

    Finally, the one good reason that perhaps makes the GWT useful, is the same reason that makes us bad developers if we chose to use it: We are changing from a more expressive language to a less expressive one, just because the tools that were made for that language are more useful.
    I simply don’t understand that. Why not invest all that money and work in actually making those tools for JavaScript?
    (A: Java has 6.500,000 developers)

24. Dan Finch (December 6, 2008 at 3:36 pm)

    “A developer who is capable of authoring JavaScript code should naturally gravitate towards authoring as close to the final product as possible. It will give them greater flexibility when developing and allow for the greatest amount of control.”

    I don’t see how you can justify “should”. Code generation, when applied wisely, can dramatically increase the amount of flexibility and control. I remember years ago there were people who insisted on writing code in assembler because it was hardcore or whatever despite the fact that compilers optimized better.

    At this point, you’re effectively right, though – JS is mind-blowingly expressive and none of the current abstractions are a compelling enough alternative to give it up.

25. Brett Morgan (December 6, 2008 at 7:01 pm)

    GWT and co aren’t so much about giving the full power of JavaScript to programmers, they are more enabling tools. They enable people to do stuff on the browser without having to take the JavaScript learning curve first.

    Sure, if people invested the time to become JavaScript gurus, they could get more done in a cleaner and more expressive way in JavaScript. These tools are more for those people, for what ever reason, aren’t interested in investing that time.

26. Josh Powell (December 6, 2008 at 10:46 pm)

    If you are developing an Enterprise Web Application, you should be a guru in what you are working on. That’s my take, anyway.

27. Evan (December 6, 2008 at 10:49 pm)

    HTML, CSS, and DOM are actually quite ugly as abstractions go, but JavaScript is really rather beautiful. To me loosing touch with JavaScript is the big loss of a library like GWT. I already hide a lot of DOM/HTML/CSS stuff with Jquery and I’m better off without them.

28. Tranquiliser (December 7, 2008 at 5:02 am)

    “Why does GWT support the Java programming language instead of language X? In a word, tools. There are lots of good Java tools.”

    I think anybody who has ever had to maintain a web application of over 10,000 lines of JS code should understand how important the tools are. With GWT, I finished up writing 15,000 lines for my first AJAX project within two months. I could not imagine how to achieve, maintain and refactor it if it was written in pure native JS. Part of the project uses JQuery and some other JS libs through JSNI. I don’t see why they can not live together in peace.

29. Olav Junker Kjær (December 7, 2008 at 9:13 am)

    Language abstractions on top of JavaScript can be an enormous powerful tool when implemented right. But I agree that approaches like GWT, Pyjamas, Cappuchino isolates you in a ghetto:

    1) They don’t really *improve* JavaScript, rather they “abstract sideways” to a different language, thereby creating unnecessary leaky abstractions with dubious benefit.

    2) They tightly couple language abstractions with library abstractions. You are forced to use the libraries provided by the framework (eg. GWT, Pyjamas own DOM-wrappers), which will never be as good, or evolve as quickly, as the native JavaScript libraries like JQuery, simply because the native JavaScript community is much larger and more vibrant then the comparatively smaller ghettos of GWT, Cappuchino and so on.

    I believe the only viable way to improve core JavaScript is to use abstractions that *extend* the core language in a backwardly compatible way. This is the approach in Mascara ECMAScript 4 (http://ecmascript4.com/), which provides powerful extension to vanilla JavaScript, but without abandoning compatibility with the large amount of existing JavaScript code and knowledge.

    Also, I happen to actually like JavaScript as a language, so I don’t think there is any reason to hide it behind a different language. (The DOM is a different matter :-) Rather the power and spirit of JavaScript should be *enhanced* by the abstractions.

30. Gavin (December 7, 2008 at 2:34 pm)

    @John If you watch some of the GWT presentations you’ll know exactly why you should use it. It’s way faster than anything out there. In fact when the team ran some of the top javascript libraries by javascript experts through gwt they saw an average increase in speed of 20%. GWT is way simpler and frankly a lot faster and more fireproof than writing javascript by hand.

31. Caligula (December 7, 2008 at 5:07 pm)

    @Ryan: “From (Java programmers’) perspective, web development is so impossibly frustrating and rudimentary, it’s considered beneath them.”

    No, it’s considered *frustrating*–it has absolutely nothing to do with it being “rudimentary” or “beneath” them.

32. Breton (December 7, 2008 at 6:04 pm)

    “Many of the techniques used in Cappuccino are simply not possible in pure JavaScript. ”

    This is a bit disingenuous. Obviously those techniques are possible in “pure” javascript, otherwise you’re basically implying that objective-j/cappucinno run on magic and fairy dust.

    All that stuff is possible in javascript. You just find the syntax distasteful.

33. Tino Zijdel (December 7, 2008 at 7:35 pm)

    Breton: you make a good point; exactly what I was thinking since the Objective-J runtime/interpretor is in javascript after all.

    > “If JavaScript had classical inheritance with dynamic method dispatching, and imports, we could have written Cappuccino in JavaScript”

    Javascript’s flexible nature makes it possible to do all those things if you just try hard enough; there’s plenty of examples out there. As for the first: trying to mimic classical inheritance; it’s feasible, but should you really want to do that? It only makes sence if you don’t (want to) understand javascripts prototypal inheritance structure, but all in all it’s just as powerfull and when used in the right way you shouldn’t need tens-of-thousands lines of code to achieve something substantial, even without a javascript library.

34. richard b (December 7, 2008 at 7:57 pm)

    I see no problem with gwt. For me it’s not about performing the task at either lower level (in Javascript) or at a higher level (Java). It’s the ability to have a mixture of both and working at the right level at the right time.

    Although Java isn’t conceptually a higher level language it’s more productive to write Java because it is better supported in terms of tools and the workflow around building an app in a team etc. Also I believe it’s the fact that Java is a statically typed language that allows them to do all kinds of advanced optimisation stuff that may be out of reach of the intermediate Javascript developer.

    GWT is usually used in conjunction with another js widget library e.g. gwt-ext or smart-gwt. These very mature javascript libraries are wrapped via a thin adapter layer so that the underlying javascript widget library can be scripted in Java. Yes scripted! It’s analogous to calling out to C libraries in a scripting language such as python/ruby etc. Obviously it’s not appropriate when you want a traditional web site with a few ajax effects dropped in. It’s more suitable for web based applications that act as desktop application.

    To conclude I think GWT has it’s place. In a Java enterprise shop producing what were traditionally swing based desktop client apps to interact with ejbs in say a banking app, using GWT may be a more acceptible way to get Javascript into that environment.

35. Sakuraba (December 8, 2008 at 2:51 am)

    GWT is more than just the excellent Java tooling. With the advantages of compiled and therefore massively optimized and inlined code, the user does not need to download the crowss-browser version, yet only the specific one that will perform best under his browser.

    The author of Chronoscope, one of the most amazing charting libraries I have seen (ten thousands of datapoints waiting for your mouse wheel) described it best here: http://www.youtube.com/watch?v=2ScPbu8ga1Q

    It is not about replacing JS, you can write native code using JSNI in GWT. Nothing in GWT prevents you from working with the DOM or anything like that. If this was actually the case, how would all those JS-lib wrappers have been possible (GWT-Ext, GXT, GWTQuery, Tatami (->Dojo) )?

    It is not about replacing, it is about long-term-maintenance and extreme performance.

36. Tom Robinson (December 8, 2008 at 8:14 am)

    @Breton and Tino:

    Claiming that JavaScript is as powerful as Objective-J simply because Objective-J is written in JavaScript is ridiculous. JavaScript is Turing complete, therefore I can implement any language I choose on top of it. Most JavaScript interpreters are written in C, does that mean I can do everything in C that I can do in JavaScript? If not, then JavaScript must run on magic and fairy dust.

    To humor you, in fact it is possible to write plain old JavaScript that uses the Objective-J runtime to give you everything I’m talking about. But it’s ugly. Is adding a little syntax to make things prettier and add a little structure really that reprehensible?

    Take dynamic method dispatching for example. Objective-J’s implementation gives you things like Ruby’s method_missing and Objective-C’s forwardInvocation. This is simply NOT possible in JavaScript without something like the Objective-J runtime (except in Firefox which has noSuchMethod). For this method call:

    
[object methodName:arg];


    Objective-J compiles to the following JavaScript:

    
objj_msgSend(object, "methodName:", arg)


    Even if you aliased objj_msgSend to a method (called “msg” below) on all Objective-J objects the closest you could get without special syntax (like Objective-J) would be:

    
object.msg("methodName:", arg)


    Calling a superclasses’ method is another rather difficult task JavaScript. In Objective-J it’s just:

    
[super methodName];


    Importing would also be problematic. Since we parse the file we know all of the imports ahead of time, so we’re able to asynchronously load multiple imports in parallel (decreases load time, allows cross-site loading via JSONP). A clean set of imports like this:

    
@import "FileA.j"
@import "FileB.j"

    // rest of your code


    would require something like this (not currently implemented, but easy to), with all your code wrapped in a callback:

    
objj_import("FileA.j", "FileB.j", function() {
// rest of your code
}


    Once nice thing about Objective-J is the runtime is separate from the language/syntax. So if someone wants to write an addition to the Objective-J runtime that lets them use plain JavaScript (with the nasty workarounds mentioned above) then go for it.

    Personally I’ll stick with my better syntax.

37. rloaderro (December 8, 2008 at 9:29 am)

    I would love to hear John or someone who has authoritative experience with JS and GWT give their opinion about developing with each. My personal experience with GWT was miserable.

    *disclaimer* I am not a Java developer so my experience may have been highly influenced by the skills of the developer I worked with.

    Perhaps I went about it all wrong – as with other web apps I designed the interface and coded in CSS first, then tried to merge with GWT.

    – I found recreating the templates in GWT next to impossible. The default “building-block” in the framework is the table cell?! From what the developer told me it is not a real MVC framework and the templates that we did not need to create piece-by-piece using DOM elements were stored as text block within the Java classes?!
    – GWT does not have it’s own JS framework ie jQuery, but can act as a wrapper for other frameworks. This is possible via adapters – for example if you want FX in GWT you can use the Prototype wrapper. So, you still need to learn Protoype except you use the Java syntax of the adapter. There are also GWT widgets which are UI elements that have been adapted for the framework – though there are much fewer of these for the popular JS framework and they are not visually cohesive ie jQuery UI, ExtJS, Mocha UI, etc.
    – So you start mixing in these widgets and something goes wrong (possibly from incompatible frameworks extending JS natives ie PT, jQuery, Mootools etc). You cannot debug clientside since the JS is “machine optimized” – in fact we never did figure out how to debug these cases.
    – In the end we found the GWT to be apt for developing Google-like web apps – ie simple visual interfaces, on/off effects for an audience – from what I understand – of Java developers who are afraid of JS/CSS. Supposedly GWT fixes cross-browser development so programmers don’t ever have to learn the details of CSS – but when you make JS a requirement that’s not too hard to do with something like Dean Edward’s IE.js. Non-ubtrusive / degradable JS/AJAX – not an option. Accessibility / indexing – not an option. Machine-optimized JS – OK, I’ll give you that and just stick with HAML, SASS and YUIcompressor myself.

    As I mentioned, it’s most probable that I just didn’t understand the proper way to develop with GWT, but from my personal experience it did not seem like a step in any direction I wanted to go.

38. Wade Harrell (December 8, 2008 at 12:06 pm)

    The abstractions are a hammer, and many of the evangelists seem to think everything is a nail. There are some use cases where they are a good fit, but that is the exception not the rule.

    Too often they are being used as the latest salvo in the resistance to dedicated client-side developers; the same resistance that has been going on since 1998 or so. An excuse for compiled language developers to think they can build out a UI without dealing with all that “messy” HTML, CSS, JavaScript, etc. Building web pages is easy, right? Easy until the people you are building the site for start asking questions! (this is about the point in the project when I typical find myself being called in)

    Templated CMS systems rarely are a perfect fit, and the same thing here. If you do not want to do things exactly the way the abstraction allows then you will spend twice as long working around it than if you built the app with dedicated developers for the UI from the outset. Sure, you can code quick with a toolkit like this, but quickly backing into a corner is not progress.

    This is the danger of code that writes code, your flexibility is lost. Ask any client-side developer that has had to deal with the nightmare of Java generated form validation scripts.

    I consider my creativity an asset in writing code, and am always uneasy when faced with code written for me based on vague assumptions about what I intend to do. It would be impossible to build an abstraction without making the assumptions, and it becomes a language unto itself when you try to account for them all.

39. Martin Pilkington (December 8, 2008 at 2:45 pm)

    @Brenton: “Obviously those techniques are possible in “pure” javascript, otherwise you’re basically implying that objective-j/cappucinno run on magic and fairy dust.”

    By that reasoning, everything possible in Objective-C is just as possible in straight C and that just isn’t the case. Remember, the power in Obj-C and Obj-J isn’t the language, it’s in the runtime. The languages are just a nice syntax to work with the runtime.

    Obj-C is just a small set of syntactic addition to straight C that are then converted to the appropriate C functions to run in the runtime, which is written in C. Similarly Obj-J is just a small set of syntactic additions to straight JavaScript that are then converted to the appropriate Javascript functions to run in the runtime, which is written in Javascript. Obj-J isn’t an abstraction, it’s a new language.

40. Ray Cromwell (December 8, 2008 at 5:33 pm)

    I think there is still a lot of misunderstanding about what GWT does and why you should use it. Most of the people I know using GWT aren’t Javascript newbies, but in fact, very well versed in Javascript. I myself wrote a large Javascript charting library, and then turned around and ported everything to GWT.

    Leaving aside the obvious benefits of using the Java tool chain, there’s a couple of other reasons:

    1) Aggressive compiler optimizations, that happen before code is sent down the wire. This is a problem that no amount of trace-jitting will solve. Far from being bloated, as I demonstrated in my GWT Query presentation at Google I/O, GWT can produce code an order of magnitude smaller than most selector libraries in specific circumstances. GWT can prune dead code far better than any JS optimizer, and can obfuscate code to reduce size in a way that helps maximum GZIP/DEFLATE algorithms.

    2) Built in package/nameaspace system for programming in the large. Together with number 1, this allows building apps that depend on alot of third party libraries written by other people, but have the compile elide all of the unused code, without elaborate build scripts.

    3) Compile time code execution facility (gwt generators) that automate loads of tedious processes — automatic CSS sprite generation, automatic translation of app resources into data URLs and inlined strings, automatic CSS optimization, automated I18N/L10N packaging, etc

    One of the core goals of GWT is to reduce the number of HTTP requests, reduce code size, and increase app startup time. In contradiction to what Jim Marion said, GWT output is extremely cacheable. The compiler names the output file according to a cryptographically strong hash, and it is set to cache forever. In practice, many GWT apps load a small 1K bootstrap file and never perform any other HTTP requests except to interact with RPC/JSON/REST.

    Finally, there’s code reuse between the client and server. Yes, products like Jaxer let you run JS on the server, but code sharing between client and server doesn’t have the 14 year history behind it that the JVM has.

    Here is an example from my library, running the same code that runs highly efficient in the browser as JS, running as Java on Android (http://timepedia.blogspot.com/2008/11/chronoscope-and-gviz-on-android.html). That’s 98% code reuse. To get the same logic to run on Android natively required only 5 classes to be written.

    GWT should be seen as a compiler and build/debugging tool, and not as a “widget library” like ADF or ExtJS. It does provide widgets, but the real value comes from the compiler. And far from ignoring JS, most GWT developers I know write alot of JS and depend heavily on using JSNI for integration. We expect the abstractions to leak, indeed, we depend on them to do so often.

41. Breton (December 8, 2008 at 5:54 pm)

    “@Breton and Tino:

    Claiming that JavaScript is as powerful as Objective-J simply because Objective-J is written in JavaScript is ridiculous. ”

    This is a strawman, I never claimed this. You can read my post again if you like, that wasn’t part of it.

    “JavaScript is Turing complete, therefore I can implement any language I choose on top of it. Most JavaScript interpreters are written in C, does that mean I can do everything in C that I can do in JavaScript? If not, then JavaScript must run on magic and fairy dust.”

    In fact it *is* possible to do everything in C that you can do in javascript. That’s the idea behind the JSAPI. It’s just more verbose. The syntax is “distasteful”, but it would be wrong to say that some things that are possible in javascript are “simply not possible” in c.

    “To humor you, in fact it is possible to write plain old JavaScript that uses the Objective-J runtime to give you everything I’m talking about. But it’s ugly. Is adding a little syntax to make things prettier and add a little structure really that reprehensible?”

    I didn’t say it was reprehensible, I was simply exposing this as your true goal. You are not a magician that is making the impossible possible. You are a syntax decorator.

    “Take dynamic method dispatching for example. Objective-J’s implementation gives you things like Ruby’s method_missing and Objective-C’s forwardInvocation. This is simply NOT possible in JavaScript without something like the Objective-J runtime (except in Firefox which has noSuchMethod). For this method call:

    [object methodName:arg];

    Objective-J compiles to the following JavaScript:

    objj_msgSend(object, “methodName:”, arg)

    Even if you aliased objj_msgSend to a method (called “msg” below) on all Objective-J objects the closest you could get without special syntax (like Objective-J) would be:

    object.msg(“methodName:”, arg)
    ”

    and in what way is doing that “simply impossible” ? You seem to be pretty definatively demonstrating that it is very simply possible. Whilst also demonstrating your distaste for the syntax. Way to prove my point!

    “…Personally I’ll stick with my better syntax.”

    You’re welcome to it. All I ask is that you drop your allusions to godhood. You are not doing things in objective J that are “simply impossible” in javascript.

42. Dmitry Baranovskiy (December 8, 2008 at 6:01 pm)

    John, I am absolutely with you on this issue. By using these abstractions you are entering a danger path, where you still need JS guy in the room. The problem is, nobody wants to be this guy. I quit one company because they switched to GWT.

43. Breton (December 8, 2008 at 6:04 pm)

    “By that reasoning, everything possible in Objective-C is just as possible in straight C and that just isn’t the case. Remember, the power in Obj-C and Obj-J isn’t the language, it’s in the runtime. The languages are just a nice syntax to work with the runtime.

    Obj-C is just a small set of syntactic addition to straight C that are then converted to the appropriate C functions to run in the runtime, which is written in C”

    I kind of feel like I don’t really need to respond to this because you contradict yourself in the same breath. You first claim that it is false to say “everything that is possible in objective-c is possible in straight C”, and then go on to point out that everything that objective-C does is, in fact, written in straight C.

    This isn’t a religious argument. It’s a basic principle that you can create a new language to make many programming tasks simpler, and allow programmers to manage greater complexity. My point is that it is terribly misleading to claim that this then means that you are doing things in the higher level language that are “simply impossible” in the lower level language. You’re using an abstraction to manage complexity, not summoning the spirit of cthulu to violate the laws of physics.

44. Ray Cromwell (December 8, 2008 at 6:38 pm)

    The problem with these arguments is this. Today’s browsers are implementing JIT VMs. Yet, the only way to access these VMs is via Javascript for there is no portable bytecode representation. As such, you have a variety of people inventing languages and tools that compile to Javascript. If the browsers had a portable bytecode, then people could use whatever programming language they want in the browser.

    The people on the other side of the issue seem to be running a classic language religious flamewar. They want only a single programming language for developing client applications, and that language is Javascript. If the OpenWeb is to last us for decades, and if it is truly open and growable platform, then the zealots much be tolerant of people who want to use alternatives. Why shouldn’t people who are heavily invested in Ruby, or Python, Scala, Scheme, or Haskell, be able to carry over their knowledge to develop web applications? There is nothing magical about Javascript syntax that makes it the most efficient language ever for doing client-side work and no reason why going forward 10 years in the future, why it should remain the only way to write client side code.

    There is a big difference between abstractions that abstract the platform (DOM, events, canvas, etc) and an abstraction that provides an alternate programming language that is reasonably isomorphic to JS. The former is a lot more likely to leak abstractions than the latter, especially since in most cases, the compiler can detect abstractions that won’t compile properly to JS, but can’t detect leaky abstractions like trying to treat HTTP requests as synchronous.

45. Ted (December 8, 2008 at 7:29 pm)

    I notice a pattern from the anti-GWT people; they are the kind of people who look at the GWT Google Code page and say “What a horrible idea” without even exploring it in depth.

    I’m no evangelist (heck I don’t even have a blog), but I can tell you that if you want to write clean-code, good SoC, good software development practices (that means unit-test, continuus integration, etc), GWT is by far the best choice.

    If you have no idea how i18n, generators, ImageBundle, etc. works, then don’t complain fellow developers… LEARN to use it before you complain.

46. Tom Robinson (December 8, 2008 at 8:34 pm)

    @Breton

    As I tried to express, whether or not things are “possible” in a programming language under your definition is irrelevant. I’m talking about the real world where productivity matters.

    No one writes applications using JavaScript engines’ C APIs. No one writes applications on the Objective-C runtime using the objc_msgSend() C functions calls. But, yes, those things are “possible”.

    The fact is you *have to implement* the features I mentioned to get them in JavaScript, and then the syntax required to use them is terrible. We could have not added new syntax, but I mentioned three specific things where the JS hackery required to get the desired behavior was too cumbersome.

    “You are a syntax decorator.”

    Well, no, the syntax is a fairly minor piece of whole picture. The runtime is what matters most. And while you *could* write things like object.msg(“methodName:”, args) I don’t think many people would find that acceptable.

47. Tom Robinson (December 8, 2008 at 8:36 pm)

    FYI: Francisco, who wrote Objective-J, wrote a post that I think clarifies a few misconceptions:

    http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/

48. Breton (December 8, 2008 at 9:10 pm)

    “Well, no, the syntax is a fairly minor piece of whole picture. The runtime is what matters most. And while you *could* write things like object.msg(“methodName:”, args) I don’t think many people would find that acceptable. ”

    That is in fact, exactly how I’m coding my latest app. It’s even officially a “gang of four” pattern, called the command pattern. I think I am not alone in coding applications this way, and I find it to be perfectly acceptable.

    “The fact is you *have to implement* the features I mentioned to get them in JavaScript,”

    Well hey, if you want javascript to do *anything at all* you have to implement it. Libraries are useful in implementing many of these things. Whether the syntax is terrible or cumbersome is a matter of taste. Whether something like objective-j improves productivity is a matter of opinion (Since you clearly haven’t done any science on it).

    “As I tried to express, whether or not things are “possible” in a programming language under your definition is irrelevant.”

    I don’t think I have a particularly odd definition for possible. On the other hand I think your definition is overly dramatic. I think the word you’re looking for is more like “feasable” or “practical”. to use the word “Possible” is either lying, misleading, or ignorant. Take your pick.

49. Breton (December 8, 2008 at 9:43 pm)

    Sorry, that last post was harsh. To be perfectly clear, my problem is not so much with the usefulness of objective-j itself persay, but with the use of misleading language by its promoters. I don’t particularly think it’s fair to change the definitions of well understood words like “possible” just to make your particular framework look better. It’s dishonest and frankly leaves a bad taste in my mouth.

    If you wanted to promote your framework, you actually would be much better off selling it to objective-C programmers that want to get into web app development. I noticed that you’re vehemently denying this marketing position, but it’s not such a bad one for such a framework to have.

    Better than the one you currently seem to have, anyway, that is, marketing to programmers that love javascript, and yet somehow simultaneously hate it and wish they were programming in objective-C instead. I think it’s a tough sell, honestly.

50. Jonathan Fine (December 9, 2008 at 9:00 am)

    Here’s my 2 cents worth.

    JSON is a good example of a very useful cross-language tool. (I know that technically it’s a standard rather than a tool.)

    As with JSON I need effectively identical processing on browser and server. Validation checks are a good example of this.

    Java, Python and Ruby all have rich and well-documented standard libraries. JavaScript does not (although it does have Dojo, jQuery, Ext, etc). This is a very big difference between JavaScript and the other languages.

    I’m all in favor of tools that help us create high-quality JavaScript library modules. I don’t know if any of the tools discussed here fall into that category. If they do, they I’ll consider learning another language so that I can use them.

51. Ivan (December 9, 2008 at 10:45 am)

    Go John! I hate working in the JSF frameworks because they hide so much css/html/js. I also feel it’s counter-productive; you end up dealing with the cost of the learning the JSF lib as well as everything under it, since html/css/js bleeds through frequently.

    Ultimately the scope of JS is too wide to simply bury behind any other language or front-end.

52. Bertrand Le Roy (December 9, 2008 at 4:45 pm)

    Script# is a little different from GWT and other similar tools in that the script it generates is by design very close to the code you’re writing. Whereas GWT is a pretty efficient obfuscator because it sees JavaScript as a sort of byte code, Script# only tries to make the authoring of JavaScript easier.
    One of the main reasons why Script# was created was to allow for static analysis of the code at compile time, which is a real time saver on big projects. Several Microsoft products such as the web interface of Messenger have been written using Script#.

53. Ray Cromwell (December 9, 2008 at 5:11 pm)

    GWT was also created for static analysis and optimization of code at compile time, it is not, by design, a code obfuscator. Indeed, you can compile with PRETTY output and get nicely readable Javascript that you can debug in Firebug. However, GWT being a true compiler, as opposed to just a translator of syntax, shuffles code around. It would be trivial to turn this off by disabling compiler passes, but you lose size and speed advantages in the generated code.

    I’m somewhat dubious about the benefits of programming in another language, compiling to Javascript, and expecting that Javascript to match normal code style idioms of human consumers. For example, Javascript developers delight in using functional-style code, closures, prototype-modifications to do mixins and DSLs, and these may or may not be representable in the host language (e.g. Script#) It seems to me if you want to write human readable Javascript, you write Javascript, or a super-set of the Javascript grammar.

    I think a somewhat better approach is to treat generated code as opaque, and have JS-friendly interfaces exported. Somewhat like one does today when interfacing C with other languages via external interfaces.

54. Elijah Insua (December 9, 2008 at 6:53 pm)

    @john This seems like the path that programming has taken from the beginning. As an example, you have C, C++, etc compiling to ASM. You *could* write the ASM, but its generally more productive and consistent when you use a HLL. I’m not rooting for these interpretive pseudo-compiled languages, but I think it is just a natural evolution in software development.

    As per my example.. most C compilers DO allow you to write ASM which is helpful for optimizations and control. Perhaps if these languages implemented a similar system to write ‘raw js’ for workarounds/optimizations there would be nothing to complain about.

    my 2 cents.

55. Ray Cromwell (December 9, 2008 at 7:42 pm)

    @Elijah says “Perhaps if these languages implemented a similar system to write ‘raw js’ for workarounds/optimizations there would be nothing to complain about.”

    In GWT, you simply write

    native void myJsMethod() /*-{
    // inline JS here
    }-*/;

    That is, you simply add “native” to a Java method declaration, and place the implementation in comments. You can also call from Javascript to Java. In fact, writing Javascript in GWT is so easy, you could practically write 100% JS and use GWT only to do package/namespace management, obfuscation, dead code removal, and JavaDoc generation. If you want to control how the API exported via a package JS module convention, or prototype, you can use techniques like my GWT Exporter package teaches the compiler to automatically generate JS glue code around Java types.

56. Joel Webber (December 9, 2008 at 8:34 pm)

    Just to jump on the Francisco’s bandwagon, I just wrote up a post that I hope clarifies the goals and philosophy underlying GWT’s design, and why I think it’s a useful contribution to web development. Ray’s been doing a pretty good job of that here already, but I couldn’t help adding my $0.02:
    http://gwt-unofficial.blogspot.com/2008/12/gwt-javascript-and-correct-level-of.html

57. Ray Cromwell (December 10, 2008 at 1:55 am)

    My 2 cents: “The OpenWeb Programming language for the next 100 years is…” http://timepedia.blogspot.com/2008/12/openweb-language-for-next-100-years-is.html

58. Thomas Hansen (December 10, 2008 at 3:16 am)

    Well I think the comments here pretty much sums it up here for you John. I wasn’t aware of the amount of actual resistance you’ve got going here regarding your “JavaScript abstractions are bad crusade”…

    If I were (as in had read the comments before I replied) then probably I wouldn’t have exploded as much as I did in my reply to this post of yours as I did here;

    http://ra-ajax.org/john-resig-is-wrong-dead-fucking-wrong.blog

    I’ll try to use logic here though and not explode with name-callings and four letter words though. After reading the comments and seeing that also the “rest of the world” has mostly woke up, I guess it’s also easier to not “go emotional”…

    The first “real [computer] abstraction” in this world was actually RAM, did you know that? In fact before Random Access Memory was invented machines used trails of paper with holes in to “execute code”. I know because I still have my father’s Master Thesis in a bucket in the forms of a long trail of paper hanging around here. My father did that in roughly 1976…

    Does that mean that “RAM is a leaky abstraction of paper trails”?

    The second “real abstraction” was the programming language C. A couple of engineers at AT&T invented it since they thought that Assembly programming was too hard. Does that mean that “C is slow and leaks and we should avoid it since Assembly programming is so much faster”…?

    The third really big and mainstream abstraction was Java the programming language. It came with Garbage Collection and brought “Managed Programming Languages” into the picture.

    Should we ditch Java because it “can leak” and just continue where we left C/C++ or maybe even Assembly Programming…?

    Another great abstraction is TCP (which Joel brings up in his blog linked to by one of your first commenters) does that mean we all should be doing IP instead of TCP…?

    In fact Joel in his original “Leaky Abstractions” (which is a timeless masterpiece BTW and you should *all* read) does *NOT* say that “abstractions should be avoided since they can leak”. Quite the contrary in fact.

    He says USE them [read; abstractions] but take care when doing so, because *when* they leak you should know what’s “under the hood” since otherwise you’ll get stuck in a ditch you can’t get out of. But he does NOT say that you should use IP instead of TCP since “TCP can leak”…

    Final note;
    You’re a *great* JavaScript developer. I read your blogs occasionally and I have gotten a lot of ideas and inspiration from you and I really think it would be sad if you were “left in the cold of History” due to rantings about “abstractions are bad” blogs. We ( http://ra-ajax.org ) need you, GWT needs you, the Pyjamas guys needs you. Embrace us instead of perceiving us as a “threat to your existing success”… (read; jQuery)

    jQuery is great as a *temporary-hack* till the world has recovered and found better ways to handle the trouble of Web Applications. Those “alternatives” are beginning to circle you in, and unless you embrace them they will eat you alive! And make you become a bitter and angry man ranting about the “past” as if it was some kind of magical moment where everything was so much better then today where kids of today are using those “bad abstractions”…

    A great start would be for you to look over our JavaScript, or maybe the JavaScript engine to GWT, Cappuccino or Pyjamas and send in patches to improve our stuff. I am 100% sure of that you could seriously optimize Ra-Ajax if you would, which would benefit the world a LOT more then these rantings…

    The stuff you’re doing now is equivalent to saying that the “world is flat”. Get over it, the world has moved and your ideas held greatness for 2 years. That’s more then 99.9% of the world’s people will ever experience.

    If you continue focusing on Client Side development of RIAs, your previous success and greatness will sink with you like Titanic. And that would be bad not only for you, but also for the world. The world needs a *great* John Resig, not some wimp stucked in the past claiming that “the world is wrong and I am right”…

59. Kris Zyp (December 10, 2008 at 10:41 am)

    FWIW, I agree John, compiling from a lower-level language like Java to a higher level language like JavaScript seems strange, kind of like compiling assembly code to C++. And if someone wants to write a really great Java Swing app, they aren’t going to write it in C++ and translate it to Java, they would and should write it in Java.

    Translating a higher level/DSLish language like Processing to JS makes a little more sense, IMO, depending on the level of benefit achieved.

60. Thomas Hansen (December 10, 2008 at 3:49 pm)

    @Kris
    You’re abstracting away to get rid of troubles, and one of the reasons why you don’t want to develop directly in JavaScript is because you get in troubles. You need to create a bridge to the server yourself, you need to verify that your JS works on all different browsers (and your DOM stuff) and you need to do business logic in a language which effectively is not ONE language but more like “16” (one per version of browser and per browser)

    That’s why when you comparing compiling from Java to JS makes absolutely no sense…

    You want to use C instead of ASM because then the compiler can create different executables for different CPUs. And you’re compiling (or not using JavaScript directly at least) because you want the library to take care of all the different browsers versions…

61. TNO (December 11, 2008 at 9:21 am)

    @Thomas:

    Generally when you abstract something you abstract up to a higher level, not the other way around. I think Olav said it best when he stated that people are often times “abstracting sideways”. Which obviously does no good, and just creates more work. The C vs ASM analogy is just plain wrong. Like the example I gave on Ajaxian, how much code in this “HLL” does it take to equate this?

    function acc(n) function(i) n+=i;

    How much code to equate the work accomplished by JQuery? The answer is almost always more code.

    The argument that using the DOM and JavaScript cross browser is the same as having to learn multiple languages is a sad excuse. This is a problem that’s solved with most modern frameworks. I could give the same argument about the .NET framework. God forbid I want to use first class functions (beyond delegates) or LINQ and target a client’s older server. The problem is no different.(VS’s required project upgrades are a bitch, especially if you only want to fix one line in an older project)

    John was mistaken on the details of a couple of the frameworks he listed, but he is hardly “Dead fucking wrong” about the problem. There is a difference between abstracting a problem and hiding yourself from it. WHEN something breaks, your “abstraction” is thrown out the window and you have to resort to learning what you were hiding in the first place. Ever try to debug improper server generated code to see what the server is screwing up? Its more attractive to eat glass.

    The argument here seems to be different than what some think IMO. This looks more like an argument between Thin Server and Thin Clien Architecture.

62. Adam Jorgensen (December 11, 2008 at 9:31 am)

    @Thomas Hansen

    You’re blog post is a little…

    er…

    frenzied…

    Anyway, calm down a bit.

    Personally, my feelings on this matter sit somewhere in the middle. Both jQuery AND Objectice-J are cool to me. GWT, I’m less sure off primarily because I’ve jumped off the Java band-wagon :-)

    Overall, I think there is a middle ground.

    Which is, I believe, what Joel Spolsky was getting at…

63. Wade Harrell (December 11, 2008 at 1:18 pm)

    @Ted (December 8, 2008 at 7:29 pm)
    Being one of the anti-GWT I have to admit truth in what you are saying. I feel it is a frequent occurrence for many in the industry that specialize in client-side dev to hear Java developers grumbling about how GWT will be their answer to dealing with that pesky JavaScript. The next time the Java folk talk to the CS dev they are asking for help cleaning up the mess they made. This has happened to me a couple times. I suspect many that are anti-GWT have had it happen too.

    I never really dug deep into GWT, and these experiences have turned me off to the idea. I get the feeling it is being pitched to Java developers as something they do not need to dig deep in to as well. Any time a technology is marketed as an “easy” solution people do not feel the requirement to learn about it (the “web is easy” attitude still haunts us). Just read the overview of Douglas Crockford’s “A Survey of the JavaScript Programming Language” to see how even some of the best may be unwilling to dig deep at first.

    In my previous experiences dealing with JavaSript written by Java I was confronted with horrible code that was difficult to work with and harder to adjust. Generated JavaScript has historically been something to avoid. I certainly did not want my name associated with a project where generated JavaScript was used.

    I am willing to accept that times have changed. Obviously the people at Google know a thing or two about JS. I still find it hard to swallow that their general purpose widgets are going to meet the use cases I face. If it comes to modify them, then what is gained?

    What I have encouraged in the apps I have worked on is what I call the separation of church and state. As much as is practical we strive to keep the server app focused on delivering, ingesting, modifying data in an agreed upon structure (json or xml). The display and interaction with that data is handled by whatever means required for the task, ajax, flash, another site, iphone app, ect. This also allows for the server technology to be flexible, in one case we did a prototype in php, a POC in ruby, and a final release in Java… the client ajax stayed the same. GWT obvioulsy does not mesh well with this thinking.

64. Ray Cromwell (December 11, 2008 at 4:33 pm)

    @Wade, I think you are confused about what GWT is or even how its pitched. It seems to be a frequent case in online blogging reviews of languages or frameworks that people dismiss technology without getting their hands dirty, based on skimming material and listening to hearsay.

    GWT has never been pitched as technology that abstracts people away from the underlying web and encourages them to not “dig deep” It’s in the GWT docs, the GWT design is to be a leaky abstraction on purpose. It doesn’t try to hide the web. The GWT team has given ample presentations at dev events over the last two years saying precisely this. Many of the GWT presentations dig very deep into the generated Javascript and DOM. Despite constant repetition, despite the fact that JSNI is heavily used in most GWT projects, despite the fact that if you look in the GWT groups, most of the users posting are deeply aware of the browser, people continue to assert that GWT is isolating newbies from web programming.

    There are server-side AJAX and client side JS libraries that do more to hide the browser from the developer than GWT does.

    Secondly, GWT’s Widget library is not the core reason to use GWT. You can indeed use GWT without it (seem my library GwtQuery for example for jQuery-like progressive enhancement development). And Google themselves have multiple GUI toolkit libraries that don’t use the GWT widgets, like TopSpin. There are also wrappers like SmartGWT, gwt-ext, and libraries like ExtGWT.

    Third, it is not true that GWT does not mesh well with JSON or XML. I use JSON for everything in my GWT projects, in fact, I even use funky intra-frame cross-domain hacks like the window.name trick that SitePen came up with. GWT includes multiple ways to interact with the server: RPC, an XML module, a JSON module, and using Overlay Types. RPC is most useful if you’ve got Java on the server and you want to debug, since you can step from client-to-server through the debugger in GWT, something you can’t do in Firebug. I take the position of having the server REST serialization be flexible and support many output types, including Protocol Buffers (useful for Android clients)

    The primary values of GWT are:
    1) aggressive code optimization and obfuscation, far more compact than you can achieve writing maintainable human readable JS
    2) reduction of network latency/HTTP requests by automatic bunding/packaging
    3) reuse existing Java toolchain. IntelliJ/Eclipse, Maven, CheckStyle, FindBugs, Debuggers, Code Inspections, Test frameworks, on and on.

    It is simply not about the “java language”. There is a tendency for language zealots to view everything through that prism. The GWT developers themselves are not in love with Java. I don’t love Java (we use Python and Scala), one of the core GWT devs Lex Spoon formerly worked on the Scala compiler. The reason GWT uses Java is that the optimizer works better with type information available and existing tools were abundant (IDEs, debuggers, etc) It is very probably that future versions of GWT will work more like GCC, and accept a multiple of input languages. Hell, if JavaScript 2 as originally proposed would have come to pass, it would have make a great input language to GWT.

    If you’re really interested in the “why” of using GWT, watch my GWT Extreme presentation (http://www.youtube.com/watch?v=2ScPbu8ga1Q) which shows off lots of GWT stuff without even delving into the widget library.

    Or, for example look at my demo of running identical code on Android and as Javascript in the browser: http://timepedia.blogspot.com/2008/11/chronoscope-and-gviz-on-android.html This is simply unachievable with plain Javascript.

65. Grey (December 11, 2008 at 6:01 pm)

    I agree with you, keep your “JavaScript” in “JavaScript” and your “Java” in “Java” or how to say.

    But I guess that there are times when GWT etc can be nice tools for some people.

    Me being a “hobby developer”

    Prior to this spring I had never written any JavaScripts (only made some small personal or intranet sites using php/java/html/css)

66. Thomas Hansen (December 11, 2008 at 6:05 pm)

    @Wade Harrell
    I realize that you’re really talking about GWT and not Ra-Ajax, still I feel an urge to defend Ra here since I don’t want people to get “mixed up” and believe that what you say is true about Ra-Ajax…

    Most controls in Ra-Ajax builds one single DOM element, like button, checkbox, radiobutton and so on – they all build *ONE* DOM element.

    Label creates a span (and you can in fact change the tag of it if you want to into a P (paragraph) or a div etc if you wish)

    The only real difference is that when you in JS creates an OnClick event handler you’re still on the client while in Ra you’re creating an event handler on the *server*.

    And instead of doing document.createElement you do *on-the-server* Button b = new Button();
    Form.Controls.Add(b);
    etc…

    Sure you can create client-side event handlers but then much of the point is gone.

    This means you can do stuff like class, style and so on with Ra-Controls and you can map those towards CSS or style attributes.

    And when you modify properties of a control from the server, say like changing the background color you do this by e.g.;
    myControl.Style[“background-color”] = “#fed”;

    Then when the page is finished executing the current request all changes are sent back to the browser as JSON and updated on the client-side.

    It’s still 100% web, check it out in e.g. FireBug by visiting this page and you’ll see for yourself…
    http://ra-ajax.org/samples/Viewport-Calendar-Starter-Kit.aspx

    The only real difference is that you go a little bit more often to the server (probably not that much though) and that you get to develop in C#, VB.NET, IronPython, Boo etc instead of JavaScript in addition to…

    (here it comes)

    ALL YOUR LOGIC is on the *SERVER* instead in JavaScript, needless to say that creates a far more secure solution and carries a LOT of other benefits…

67. TNO (December 11, 2008 at 6:16 pm)

    @Thomas:

    Cross posting this from Ajaxian since it looks like you abandoned that thread and it seems a fitting response:

    “I think you may get some enlightenment from this presentation. It sums up decently well some reasons why there is a resistance to your line of thinking with a significant group of people:

    http://docs.google.com/Presentation?id=dfxgjqrf_196fr6ct4f2

    Not that I use Dojo or anything, but the Thin Server Architecture crowd I do subscribe to. Maybe you can see where a few of us are coming from.”

68. Adam Jorgensen (December 12, 2008 at 2:21 am)

    @Ray

    Is it possible to use GWT with other JVM-based languages? Your post seems to indicate this, which is interesting if it’s the case…

69. paulhan (December 12, 2008 at 7:43 am)

    @Thomas
    Ok, so I bit. I’ve been trying to figure out why all the piss and vinegar (ever considered anger management?) any time John Resig’s name is mentioned on Ajaxian, and now I see more of it here.
    So I went on to the Ra-Ajax site and had a look around. I like Treeviews and had a look at yours – looked ok, I click on a node and I wait for about half a second before it opens, then I wait another half a second for it to close. This is with a 2Mb connection. There is no way on God’s green earth I could accept that. Same with a couple of the other widgets. Are you seriously suggesting that users be subjected to that consistent delay on a reasonably complex web-app. I can tell you, it would very quickly wear thin.
    It’s based on the ASP.net platform. Good platform, lots of users. I don’t use it, there’s too many other good platforms, that also happen to be free and are easier to use IMV, should I ever need one.
    The right use case for your framework is a corporate intranet where network latency and server load aren’t such an issue, and where people are more likely to develop for ASP.net, but on the internet, it hasn’t a chance. If it ever got wide adoption, it would set things back five years.
    You’re shouting at the wrong people. You might as well go on an Apple developer’s forum and shout there for all the traction you’ll gain with your framework. Please, share your “passion” on a dotNET forum where it belongs.
    Paul

70. TNO (December 12, 2008 at 9:00 am)

    @paulhan:
    I argued the same point with him a couple times at length on the same subject (http://ajaxian.com/archives/jx-layout-manager-for-jquery), but it does no good it seems.

71. george (December 12, 2008 at 9:57 am)

    i think Thomas is looking ahead and to the future of web development. it is a model that makes sense. maybe not now, but with improvements in network technology and speed of loading things over http, i think it holds a lot of potential. i definitely won’t dismiss his proposal.

72. rloaderro (December 12, 2008 at 5:33 pm)

    I would really like the opportunity to talk to someone who knows a bit about GWT because I still have a lot of questions! Ray, if you have chance, please contact me via the form at the bottom of my page: http://www.electricprism.com/aeron – I tried to find a link to contact you on the web but couldn’t.

    So, assuming GWT handles the technical stuff without a problem – conversion to JS, browser-bugs, debugging, etc – what about workflow. I want clean separation of content from behavior. I want my interface designers – who know nothing of Java/JS to be able to edit all the pages and HTML chunks that are returned from the backend without having to work their way around too much server-side code – how does that work with GWT? What I like about client-side Javascript libraries is they are completely degradable. I realize that is not a goal of GWT, but they benefit is not only that the pages are indexable and accessible – but that interface designers can work on the HTML+CSS almost independantly from the interaction with JS – the Javascript just *adds* behavior to the DOM – it does not create the DOM. Until backend developers suddenly grow an eye for aesthetic the ideal workflow allows for as much separation of concerns as possible.

73. Ray Cromwell (December 12, 2008 at 6:28 pm)

    @rloaderro,
    Excellent question. It is really kind of a misunderstanding in the blogsphere that GWT encourages you to have opaque pages () with almost all of the content generated by JS.

    GWT specifically includes two mechanisms to handle progressive enhancement and separation of content and code:

    1) GWT widgets contain no style, all look and feel must be supplied by a CSS provided by the user. Actually, GWT took flack for this, because in GWT 1.3/1.4, out of the box, the GWT widgets looked like something from 1994, no color, no images, no nothing. Now, GWT 1.5 includes default CSS stylesheets, but you can override them.

    2) RootPanel and wrapping. You can wrap many existing elements with enhanced functionality, or you can use RootPanel.get(“id”).add(…) to inject a GWT widget as a child of an existing DOM element.

    You can also avoid GWT widgets entirely and just attach event listeners to existing elements (see GwtQuery.bind() method), but I would warn people to be careful of memory leaks in doing this. The GWT widget library specifically manages widget attachment/detachment which makes GWT the only widget library that guarantees zero browser memory leaks if used correctly.

    I’ll contact you privately later.

74. Thomas Hansen (December 14, 2008 at 8:32 am)

    @Cromwell
    I need to say this so that others hears this too, and also Ra-Ajax has “destructors” of widgets which cleans up event handlers and such. This means that when a widget is destroyed it will automagically clean up all its event handlers…

75. Thomas Hansen (December 14, 2008 at 8:42 am)

    @TNO and paulhan
    I’ve written a blog about why Ra-Ajax is apparently so “slow”; http://ra-ajax.org/why-is-ra-ajax-so-slow.blog

    I’ll give you the short version, first of all Ra-Ajax *is* slower then client-side DHTML. That’s a fact. Nothing I can do anything about since it’s in the “nature” of going server-side to fetch data.

    Though if you’ve got a jQuery TreeView which fetches data from the server in it’s going to be equally slow! In fact often slower since the jQuery version will often use stuff like “appendNode” where Ra-Ajax uses “innerHTML”.

    But most of the reason why the Ra-Ajax samples “feels slow” are because of that we’re an LGPL project deploying our samples on the cheapest things money can buy, and also it’s in *Norway*…
    Try it out on your own servers before saying it’s “slow”. It’ll probably be between 2 and 5 times as fast on a server which doesn’t need to cross half the world’s routers to get to your computer…

    But I’ll say this out loud for everyone to hear, jQuery is great if all you want to do is create some DHTML effects like the login button at digg or something, though if you want to create complex applications like e.g.; http://stacked.ra-ajax.org/ it’s going to make development far more advanced and time consuming and you risk going to market too late – after your competition (which uses Ra-Ajax) have deployed version 11…!!
    (Which means you’re basically out of business)

76. TNO (December 14, 2008 at 11:51 am)

    @Thomas:
    First off, no one calls it “DHTML” anymore. Its a deprecated term replaced with “DOM Scripting” but anyway…

    In response to your “why ra ajax is so slow” blog:

    “This means that StackOverflow has about *14 times as much JavaScript* as our version of Stacked have. When you put all these facts together you realize that you could probably build a better version of StackOverflow.com using Ra-Ajax.”

    Having a smaller amount of JavaScript does not necessarily equate the ability to build a better application (for example: http://andrew.hedges.name/experiments/innerhtml/)

    “Ra-Ajax is DEADLY FAST! There are *no* performance problems in Ra-Ajax unless there’s a BUG in it that we have managed to overlook or something.”

    This is just plain wrong. You use the location of your server as a caveat to user experience. I argued this point before on Ajaxian that it shouldn’t matter if the server is on Pluto or in my backyard. User experience should not be reliant on geographic location. (http://thenewobjective.com/temp/Ra-Crash.jpg). You then tried to argue that a treeview of 500 nodes will be slow no matter what, to which I provided a proof of concept to the contrary: (http://thenewobjective.com/temp/TreeView/TreeView.html). But to be fair on that point and use another example of a “DEADLY FAST” control you provide: (http://ra-ajax.org/samples/Ajax-Button.aspx). Most of the the time the text does not match the event due to network latency.

    You then later state:
    “So if you think that Ra-Ajax is slow then I encourage you to download it and test it on your *own* servers.”

    So if a client comes to me complaining about interface responsiveness, I should tell them to live closer to my server, or should I tell them to just to install .NET and Ra-Ajax on their own website to look at their own copy if they want a responsive interface?

    In response to “http://ra-ajax.org/killing-the-myths-of-managed-ajax-frameworks.blog”:

    “Everytime the user does an interaction with your application it is highly likely that you *must* go to the server!”

    “interaction” means what exactly? Because I can think of only a handful of cases where you would need or want the server involved.

    “In fact the *only* thing you want to have on the client is DHTML, effects and “bling”.
    Then why is your framework focused around not doing that very thing?

    “But instead of making it easier to create Web Applications, they make it easier to develop in JavaScript!”

    So.. making it easier to use the language and the APIs that run the browser does not equate making it easier to develop things using that API/Language? I don’t follow the logic on that one.

    “…and Ra-Ajax will automagically do a lot of “best practices” for you like adding JavaScript files at the bottom,”
    Placing all of your JavaScript references at the bottom of the page is a debatable “best practice”. What if your user interacts with the page before it loads your UI logic? The answer is nothing happens, or an error occurs. Both of which are unacceptable.

    The pointless bashing of caching:
    Generally when you use a newer version of [ajax library x], it has a different name and has already been tested cross-browser which makes the problem moot.
    As for the renaming of files in multiple places: If your site was based on XSL templates, you would only need to update in one place.

    HTTP requests:
    JavaScript libraries charge a single, flat bandwidth rate upfront. A server centric framework charges a non-client cache-able rate on every page of the domain. The rest is an implementation detail

    You Code comparison between EXT and Ra:
    This can be done with XHTML+XSL so its not a realisitic comparison.

    At this point I’m tired of typing, and everyone else is probably tired of reading so I’ll close with this :

    Stop building Straw Men and open comments on your own blog posts so these discussions can stay relevant.

77. Kippis (December 14, 2008 at 2:37 pm)

    All this arguing over language choice and abstraction is fine, but what about the real world? What is important there?

    I would suggest the following:

    a) time to market and cost
    b) user experience

    As long as it is cost effective (development and in maintenance), hits timelines and the user gets a good experience you should have a winner.

    It would be fascinating to see the results of developing the same web application in:

    i) Javascript
    ii) Javascript plus some library (JQuery for the sake of a name)
    iii) An “abstraction”, e.g. GWT.
    iv) A server side approach.

    The application itself would have to meet a set of criteria – say loosely defined as:

    * developed using multiple developers (to indicate a level of complexity and/or time and cost pressures);
    * be an application that a user would recognise as such, such as a mail application, not just “adding some Javascript to a web page”.
    * require the use of CSS styling from designers to have 2 different “looks” user selectable in the user interface
    * have multiple UI spoken languages (i18n)
    * be as visible as possible to search engines
    * be accessible (e.g. screen readers can be used)
    * have effects (which would appear obligatory for Ajax applications…)
    * use a complex JavaScript library, for example Goolge Maps
    * be developed using the same methodology for each approach (all at once; incremental; whatever…)

    I think that gives a fairly level playing field not favouring one of a, b or c over the other.

    User experience is probably the harder to nail down/measure. I don’t mean how nice are the widgets (or maybe I should?) but rather I would suggest:

    – time for application to “HTTP” load in browser for any one spoken language and one browser (maybe a function of analysing code size)
    – time for application to be available for use after loading (e.g. how long does the UI take to create and be available)
    – time to change spoken language in UI
    – time to change from one CSS view to another
    – responsiveness
    + on screen to actions
    + any server functionality

    (loading strategy must be the same in each approach; i.e. all application loads in one go; or if chunks are loaded the chunks are the same functionality)

    From a cost/time perspective, I would like to know:

    * Development time
    * # Errors found / test cycle
    * Cost of fixing each error
    * Percentage of code coverage testing
    * Percentage of automated testing
    * Measures of mantainability of code

    I’m sure there are many others that could be added and argument taken with most of the above – but until something like that is done, the argument of “my approach is better than yours” will continue with no real answer.

    One thing I will add: the last 40 years of development experience has shown the proper application of tooling substantially benefits this final set of metrics (for applications over a certain (low) complexity level)…..

    //Adam

78. Thomas Hansen (December 14, 2008 at 5:34 pm)

    @Adam
    That is a *great* idea…!
    If we could add something where we’re not potentially “cornered” like for instance a CRM system instead of a POP3 client since in a CRM system you’re only dependent upon being able to serialize towards a database (which is a pretty “general” problem with 100s of libraries in all languages) while in a POP3 client system (email) you’d also be dependent upon having a great POP3 library (or detailed knowledge about the POP3 protocol – which none of are great metrics of “tooling” towards Ajax approaches)

    I’m up, if someone writes the spec I’ll meet any Ajax Framework…

    Though I guess the whole argument and point collapses if no JavaScript Frameworks are present…?

    So assuming someone writes a very detailed and good specification, how should be “prove” things…?

    Screen Recordings of every piece of code written and developed and everything done while developing, like Googling for solutions, install 3rd Party Libraries etc…?

    I’m pretty sure I could write a minimalistic CRM system in less then an hour or two, without using snippets – which I think favors for screen recordings…?

    Then we could host them all on our servers (unless there some really funny configurations which I’ll have to spend weeks configuring to get up running on a Windows 2003 Server)

    Who else is up…?

79. Wukfit (December 18, 2008 at 4:36 am)

    I think someone else (possibly others – I’ve not read all the comments) has hit the nail on the head. Developers use GWT becasue of available tools and productivity gains, perhaps if the same tools existed for (pure) JS development then GWT wouldn’t get used?

    It’s the same story where I work the (java) developers don’t like javascript (and html/css) for app development because it’s (or the browser is) not designed for that – they prefer to write java and don’t want the hassel of having to learn something beneath them.

    I used to counter with the argument “but the mobile phone was never designed to be mobile” (and certainly was never designed to play music or surf the interweb) but because of demand and/or technological developments it became possible to make smaller batteries (e.g. the “mobile” phone used by Riggs and Murtah(?) Lethal Weapon 1). If there is enough drive and demand then browsers will improve, HTML, CSS and Javascript will improve and the development tools will improve… whether this will be quick enough to fend off the GWTs and Echo2s who knows…

    Just my 2p.

80. Thomas Hansen (December 21, 2008 at 7:08 am)

    @Wukfit
    Your arguments makes sense for cell phones, I agree…
    However a more relevant comparison would be;
    “We should keep developing in Assembly code since tools will become better after xxx and Assembly language programming will becomes easier after some yyy company creates a great IDE for it”…

81. gry dla doros?ych (December 22, 2008 at 3:10 am)

    Good work ! Thx for your good job.

82. carlos (December 25, 2008 at 7:51 am)

    dude , waht i see from your speech is that you are always telling “javascript is the best language”, so now your processing abstraction is better than processing itself? at least processing is full cross brownser, javascript will become a decent computer language when it get real classes,for now it’s just a “lets try to do it in javacsript” like language, JS libraries at the end only help for automizing certain processes wich only helps to fullfill the web of patterns.

83. carlos (December 25, 2008 at 1:01 pm)

    @Wukfit , that wont be enough, all mobile games are done with java and will never be done with javascript .

84. carlos (December 26, 2008 at 9:06 am)

    wasnt the blog author used to post stupid stuff like “jquery is faster than prototype”, my god JS kiddos, and btw fuck all the Evangelists (dumbest thing ever)

85. TNO (December 29, 2008 at 8:44 am)

    @Thomas
    I still can’t figure out how automated translation from Language X to a Higher Level Language Y equates “Compiling to Assembly”.

    @carlos:
    Its one thing to have a constructive argument, and another to randomly fling your ignorance around. I’m sorry you had a bad Christmas but don’t take it out on us.

86. carlos (January 2, 2009 at 11:34 am)

    LOL, javascript language abstraction, dude what a waste of time.how about javascript toothbrush?

87. Tim (January 3, 2009 at 1:52 pm)

    I see your point when it comes to non-ECMAScript languages, but what about ActionScript?

    I chose AS3 to implement my “abstraction” called JASPA. ;

    I know many JavaScript evangelists reject ActionScript, (especially due to its recent history with ES4), but it’s like writing an extended version of JavaScript rather than a whole different language.

    The OOP enhancements in ActionScript are intuitive and the syntax for procedural code remains largely the same. I would in fact argue that the OOP enhancements in ActionScript are much more intuitive than constructs like this:

    <code>
    $(document).ready(function(){
    // …
    });
    </code>
    – or sugaring approaches like this:
    <code>
    Class.method(‘example’, function(){
    // …
    });
    </code>

    I appreciate what these kind of constructs achieve, but I cannot agree that they are particularly intuitive or repectful to the natural form of JavaScript. I would go further and suggest that people who aren’t JavaScript experts may not see how these formations really relate to JavaScript syntax, particularly due to the use of whitespace.

    There some libraries that convert functions to strings and overwrite them with altered versions – surely this approach is even less intuitive and has even less respect for JavaScript than an extended form which provides real OOP enhancements such as classes, packages, imports, and super; not to mention strict typing.

    Anyhow, I would ask that anyone looking at JASPA realises that what I am doing is purely out of respect for what JavaScript is and what it isn’t.
    

88. Tim (January 3, 2009 at 1:54 pm)

    I see your point when it comes to non-ECMAScript languages, but what about ActionScript?

    I chose AS3 to implement my “abstraction” called JASPA. jaspa.org.uk.

    I know many JavaScript evangelists reject ActionScript, (especially due to its recent history with ES4), but it’s like writing an extended version of JavaScript rather than a whole different language.

    The OOP enhancements in ActionScript are intuitive and the syntax for procedural code remains largely the same. I would in fact argue that the OOP enhancements in ActionScript are much more intuitive than constructs like this:

    <code>
    $(document).ready(function(){
    // …
    });
    </code>
    – or sugaring approaches like this:
    <code>
    Class.method(‘example’, function(){
    // …
    });
    </code>

    I appreciate what these kind of constructs achieve, but I cannot agree that they are particularly intuitive or repectful to the natural form of JavaScript. I would go further and suggest that people who aren’t JavaScript experts may not see how these formations really relate to JavaScript syntax, particularly due to the use of whitespace.

    There some libraries that convert functions to strings and overwrite them with altered versions – surely this approach is even less intuitive and has even less respect for JavaScript than an extended form which provides real OOP enhancements such as classes, packages, imports, and super; not to mention strict typing.

    Anyhow, I would ask that anyone looking at JASPA realises that what I am doing is purely out of respect for what JavaScript is and what it isn’t.

89. carlos (January 4, 2009 at 1:48 pm)

    theres no real purpose for jaspa(lol jaspa wtf?), a javascript script can be acces with AS in a very easy manner

90. Tim (January 5, 2009 at 5:34 am)

    @carlos
    A charming and useful remark indeed, but you have missed the point completely. Perhaps you should reads John’s article before commenting – We are talking about language abstractions not interoperability between different host environments.

    JavaScript in the browser can of course access ActionScript via the ExternalInterface and vise-versa. Even in the old days this could be done clumsily in a single direction with getURL. JASPA has nothing to do with this scenario at all.

91. carlos (January 5, 2009 at 7:01 am)

    yes so explain me a real use for jaspa?(a practical use)

92. Tim (January 5, 2009 at 8:33 am)

    practical use?
    Strict typing, real classes and packages, overloaded properties, constants, private/protected properties, implicit method closures, real super calls, rest parameters, and a compiler that checks it all for mistakes – All of this genuinely native to the syntax not just sugaring of a syntax that does not support such features.

    I am not looking down on JS libs like Prototype or jQuery, they offer a different approach that has it’s own advantages, but I am arguing that abstracting it into a more advanced syntax has many advantages too, espcially when it comes to larger code bases.

    The main point of my original comment is that as opposed to Java,Python,etc.. – ActionScript really “feels” like you’re writing JavaScript – except on steroids.

93. carlos (January 5, 2009 at 12:32 pm)

    i really like action script , it’s a bit like java and javascript . there is some stuff you can do in java or AS impossible to do with javascript.

94. carlos (January 11, 2009 at 5:58 pm)

    ok ok im an asshole, regards

95. carlos (January 12, 2009 at 5:30 pm)

    anyway no ones going to argue with me that JS is a low level language compared to AS, right?

96. Breton (January 12, 2009 at 6:29 pm)

    Except that they’re the same language. AS just has a few proprietary extensions, but at its core, it’s exactly the same. prototypal inheritence, nice object literals, the same gimpy java-like Date object, etc, etc. There’s nothing higher level about AS.

    Now in my opinion, what most people refer to as AS3 (a sort of style of writing AS that uses more of the proprietary features), you’re actually coding LOWER level for the sake of performance. Everything must be explicitly typed for the sake of the compiler. This is a lower level of abstraction than untyped code- which takes care of that for you at the expense of some performance.

97. carlos (January 12, 2009 at 7:02 pm)

    i mean AS is higher level because it has classes, hard coded classes(like JAVA), the explicit typed is not mandatory in all cases in AS3 but recomended.

98. breton (January 13, 2009 at 7:08 am)

    But the problem is that classes are not a higher level of abstraction.

    They’re a lower level of abstraction, that is more difficult to program in. The reason you use classes in AS3 is for the benefit of the compiler, not the user. This is evidenced by the fact that older versions of AS were much easier for novices to program in, wheras efficient AS3 requires a specialized set of skills.

    When we speak of “levels” in programming languages, we mean levels of abstraction, and in this case, javascript and actionscript are at exactly the same level. Except when you use the proprietary features of AS3, in which case you are deciding to code lower level, and expend greater mental effort, for the benefit of compiler efficiency.

99. breton (January 13, 2009 at 7:11 am)

    They are at exactly the same level that is, because they are the same language- They are both based on the Ecmascript edition 3 standard. They each have different api’s, and different language extensions that give them slightly different characters. But at their heart they are the same core language.

    You can code in Ecmascript 3, and expect the code to work in both a flash movie, and in a browser, unmodified, except for the api calls.

100. Breton (January 13, 2009 at 7:18 pm)

     I think this article here can put this whole discussion right into perspective

     http://queue.acm.org/detail.cfm?id=1039523

     “If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.”

101. Tim (January 17, 2009 at 6:43 am)

     Don’t underestimate the benefit of classes and strict typing for the user. It may be done for efficiency of the compiler/runtime, but these models also aid robust programming, especially when you’re managing large applications. JavaScript was never designed for this purpose. We’ve moved onwards while it has stood still, hence why we have projects like jQuery in the first placeand of course why people like me decide to write abstractions like JASPA, Cappuccino, Jangaroo, etc.. at great risk of offending the JS evangelists it seems.

102. breton (January 17, 2009 at 7:36 am)

     So I have to ask. What “models” exactly do you mean? In precisely what way do these models aid in “robust” programming. How do you define “robust” as it relates to programming? How do you know that classes are really helping you manage large applications, and are not in fact, causing the applications to be large to begin with?

     Would you say Firefox is a large application? How would you rationalize the fact that a large chunk of firefox is written in javascript? How would you explain the Mozilla project’s intention to move as much of the firefox codebase out of C++ (a language based around classes), and into javascript as possible?

     Now why would they do that?

     The last update to javascript was 1.8, which was released with firefox 3.0. Firefox 3 was released quite recently. That is not exactly “Standing still” as you say. As we speak, the Ecmascript 3.1 standardization process is underway, and a standard is nigh. We are on the virge of a new browser war, and right now all the browser vendors are competing for the fastest javascript implementation.

     Google wants to write full on applications in javascript. Not javascript plus classes- No, just regular javascript. They could use their own GWT, and use classes. But they don’t. Why is that?

     Are mozilla and google run by a bunch of masochists? Or are they just idiots? Why would they forsake languages with classes, in favor of javascript for writing large applications? Can you tell me? I’d be very interested to hear your explanation.

103. breton (January 17, 2009 at 7:42 am)

     I apologize if the last post came off as snarky or sarcastic, it’s late at night right now, and I’m tired!

     But please, try to read it without a sarcastic tone if you can, because I’m honestly curious. In relative terms, I’m quite young and stupid and inexperienced as a programmer. I have never seen or heard anyone explain precisely how classes are meant to manage large projects, even though it seems to be taken as fact, or obviousness. It’s not obvious to me. This could either mean I’m just dense, or the industry has drunk a lot of koolaid and hasn’t really thought very carefully about what they’re actually doing. I don’t really know which, and I could easily believe either.

104. breton (January 17, 2009 at 8:37 am)

     that said, as far as javascript language abstractions go, flapjax is pretty damn cool.

105. Tim (January 17, 2009 at 1:09 pm)

     If snarky means aggressive then yes, it did. Perhaps we should leave John’s blog alone. Feel free to post your objections on my blog any time you like.

     I think you may be mistaken into thinking that somehow GWT runs Java in your browser. Abstractions like these generate native JavaScript prototypes, so the code runs as JavaScript intended – I have the utmost respect for that in my work on JASPA. I have not used GWT, because I don’t write Java, but I’d hazard a guess that it works similarly.

     As for explaining the advantages of classes and type annotations, a good answer to that would fill a book.

106. paulhan (January 17, 2009 at 11:09 pm)

     If you look at things from the perspective of a computer, it just wants to know where to put “something” and how much space to allocate it, where to get “something”, and how much of it to get, whether that “something” should be added or subtracted from another, or which way “something” should be bit-shifted. And that’s pretty much it.
     After that, it’s about making it as human-understandable as possible.
     So far, C is the best at doing that, IMV.
     So now we’re talking abstractions, whether it be object-oriented or functional programming, and how fast that abstraction can convert what we say into what we mean. The more abstractions, the slower it has to be, ergo, the less “cool” stuff we can do.
     There’s been a huge amount of work done on Javascript, and given that it is the “lingua franca” of the net, it is likely to prevail. Looking at a JAVA applet versus [pimp alert] my rendition [/pimp alert], there’s still a ways to go, but that just shows what is achievable vs what is now.
     For me, Javascript is the quickest way to get from where I’m starting from, to where I want to go. Libraries like GWT, however, are going to give that assertion a good run for its money, but if the browser vendors continue to support JS the way they have so far, and libraries like JQuery continue to compete on features like they have done, I cannot see how any other abstraction can compete, ultimately, except that they make things even “dumber” for the end user, i.e. more abstraction. Anyway, my 2 cents.
     Paul

107. carlos (January 19, 2009 at 8:53 am)

     we are not discussing if one language suits more a person or not , we are talking about languages in itself. Breton youre pov is quite radical

108. Breton (January 19, 2009 at 7:23 pm)

     What is a language? It’s a user interface to the computer. A level of abstraction is *precisely* how well the language suits a person. This is not a radical point of view, it’s the very definition of “high level language”. A second generation language is more abstracted than a first level language, abstracted in such a way to make it a more suitable interface for a human. For instance, using assembler instead of coding directly in machine language. Third generation languages like C, take assembler from a series of machine instructions (as represented by short words), and abstract it to more free form mathematical expressions, and other abstracted programmatic structures. Fourth level languages with garbage collection, Abstract further from a language like C by making memory management automatic.

     Technically, there’s nothing higher than 4th level languages at the moment, but within that realm, there’s different levels of abstraction. Dynamic typing, for instance, is more abstract than Strict typing, because it places more of the cognitive burden on the computer, to figure out the correct thing to do. Prototypal inheritence, I believe, is more abstract than class based inheritence for the very same reason. With class based inheritence, you must set up the entire structure of your program in advance, and it must be set at compile time.

     With prototypal inheritence, the program has the ability to dynamically create its own new types of objects at runtime, without the programmer’s intervention. If an object needs a new property, it can have a new property, and it doesn’t require modification to a class declaration.

     If any of this is radical, I think it’s because the industry hasn’t really taken enough time to stop and think about exactly what it is they’re doing in real terms, and instead gets caught up in religious wars like this.

     If you want to use classes in AS3. Fine. There are perfectly legitimate reasons for wanting to do so, mainly performance, and perhaps an obsessive desire for organization. But the trade off is that the programmer is doing more work to get essentially the same result. The extra organization may be worth it if you’re working on a large project with many people. But it’s essentially a computer enforced beaurocracy. Writing classes is filling out forms.

109. Breton (January 19, 2009 at 7:28 pm)

     If you dispute my definitions of the different levels, by the way, I invite you to edit the wikipedia articles relating to this to reflect your point of view. Let’s see how far you get.

110. Breton (January 19, 2009 at 7:32 pm)

     err pardon, I got my numbers slightly shifted-
     Assembler = 1gl, c = 2gl, java et. al = 3gl.

111. carlos (January 22, 2009 at 2:42 pm)

     the question could be: compiled language or not compiled language?.
     I’ve grown up, i choose the first option.

112. TNO (January 22, 2009 at 9:54 pm)

     Compiled vs not compiled is not a black and white issue (JIT languages for example, which include Java, .NET languages, ActionScript and JavaScript). Plus, Windows provides two different compilers for JScript with full access to the .NET framework. If you think using a compiled language makes you “grown up”, then you are sorely mistaken.

113. carlos (January 23, 2009 at 1:40 am)

     it is a major distinction

114. TNO (January 23, 2009 at 8:39 am)

     http://en.wikipedia.org/wiki/Black-and-white_fallacy

115. carlos (January 23, 2009 at 11:14 am)

     lol, another wikipedia copy/paster.

116. Breton (January 23, 2009 at 6:22 pm)

     Whether a language is compiled or not has nothing to do with the language itself. There are compilers for lisp and basic, and interpreters for c.

     The “major distinction” you may be thinking of is static vs dynamic languages. However I would point out that it is childish in the extreme to associate any kind of personal qualities to those who choose to program in any of these languages. They’re just different ways to get the job done. Programming languages are not a fashion statement.

117. carlos (January 23, 2009 at 6:54 pm)

     “Whether a language is compiled or not has nothing to do with the language itself”
     oh really, this is a funny statement.this would be like saying:
     “all languages use the assembler as the core connection”,
     you shed a light man.

118. TNO (January 24, 2009 at 12:07 am)

     Aren’t there Three Billy Goats Gruff you should be eating? If you can’t hold an intelligent conversation, people are most assuredly going to stop privileging you with a response.

     At any rate, what is this so called “major distinction” with language x that makes you so “grown up”?

119. carlos (January 24, 2009 at 6:48 am)

     i clearly stated this major distinction,i will make abstraction of your billy goats comment as it seems no intelligent at all

120. fbx (January 24, 2009 at 4:24 pm)

     Bit OT but people never talk(atleast not so vocally like GWT etc) of generating C# from Java or Java from Ruby etc. People pickup a language and code to it ,then why is it so popular in JS world to translate from other languages to JS instead of writing JS itself ? Is it because certain fundamentals are missing from language which make it inc difficult to code or is it people are not comfortable in programming paradigms offered in JS language ?

121. breton (January 25, 2009 at 12:17 am)

     The latter is pretty certainly the case. The reason compiling into JS is popular is that it’s the only language available in the browser, and people want to use the language they’re already used to. Javascript is quite far from any lack of expressive power.

122. breton (January 25, 2009 at 12:17 am)

     though you might get that impression from the browser dom- what you might call the “standard library” is incredibly weak.

123. Jeoff Wilks (February 17, 2009 at 9:19 am)

     I am one of those people who knows Java inside and out and yet loves Javascript, CSS, and HTML. I prefer the simplicity of Javascript over the verbosity of Java. Yet I’m surprised that the word “refactor” comes up only twice in all the prior conversation here.

     When it comes time to refactor, Java + Eclipse wins hands-down. Strong, static typing enables a developer to make huge, sweeping changes across an entire project and have a high degree of confidence that everything will still work.

     It is a bittersweet thing because I love Javascript yet cannot deny the benefits of static typing for large projects.

124. jhuni (April 10, 2009 at 1:32 am)

     I disagree about the processing abstraction I think it can be very useful. I mean why make something and then later say I don’t recommend that others use it.

     What is it with this philosophy that JavaScript is all great? I have used it on very large projects and now I am abstracting away from it as much as possible.

     When writing in image in SVG people can use it as a wallpaper, they can use it in their desktop applications and so on. Why write an image in Canvas instead of abstracting away to SVG when the Canvas image has a very limited usage?

     The same thing applies to using Processing. With processing you can use the animation as a screensaver. With pure Canvas it is mostly useless.

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.