Hacker News Reader

Comment by phenylene | Hacker News Reader

Or how about http://code.google.com/webtoolkit

I'm surprised that you're the first person to point this out. That's the first thing I thought of when I read this:

"But then somebody you've never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features."

No, it won't be some bratty Y Combinator startup. It'll be Google (but the Facebook/Twitter integration features won't be there, mainly because they're silly).

Even when GWT matures into the world-dominating SDK Joel speaks of, I still won't use it. To paraphrase jwz: Some people, when confronted with a problem, think, "I know, I'll use Java." Now they have two problems.

I'm waiting for someone to generate Javascript from Java through GWT from Javascript through Rhino. I wonder if that's possible...

Yes, it should be possible. BUT you need to make sure Rhino restricts the Java classes being to those core classes in the GWT JRE Emulation library:

http://code.google.com/webtoolkit/documentation/jre.html

Then you would want to wrap the other GWT classes. Mainly what you would be interested in is the RPC libraries so you can directly send Java data types over the wire to the server using GWTs serialization/deserialization routines. You dont know how nice it is to not have to deal with complex XML parsing until you've actually experienced it. Its heaven on earth compared to manual Ajax programming.

Oh and the debugging... I shouldn't even have to explain the merit of this to an experienced Ajax developer.

Using Rhino for this seems kinda pointless though when you could just write it directly in Java. I find it ridiculous how some hackers have such an aversion to coding Java. I think if people took the time to learn GWT they would quickly discover what kind of competitive advantage it brings when building complex web applications (web applications, not simply web pages). Yes, it is verbose, but once you get the hang of it its very intuitive.

Why cant it be some Y Combinator startup who builds what Joel describes? GWT in the hands of a small team can build web applications that compete with Googles. If you dont believe me, then I challenge you to give it a try and see for yourself. Just dont give up too quickly; the learning curve is a bit steep.

I haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR.

I also worked on SproutIt's Mailroom app, which is about 80% of the functionality of GMail, implemented by 2 dudes (one backend, one part-time front-end) over the course of a year (also in Ruby on Rails). Sprout's since released their toolkit, called SproutCore, but its docs are still a bit sketchy.

My $.02 -- too much of the plumbing for web 2.0 takes place on the server, which is why time to market on the server-side has been so important over the past few years. With Prototype, MooTools, YUI, etc. a lot of the fancy front-end tools can be bolted on after the fact.

Also -- how many apps fit the mold of a 100% full-screen AJAX app? Email, spreadsheet, word processing, calendar... what else? Reading news, surfing blogs (outside of an RSS reader), googling for information, etc. do not fit the mold of a 100% AJAX app.

You will definitely be very slow in building stuff initially, if you have not used GWT before. Much slower than using RoR. Unless maybe you've done lots of SWT/Swing programming, then you will at least have a general understanding on how to layout stuff graphically and use event listeners.

Everything in GWT is treated as AJAX app, in that all RPC's are asynchronous. But all GWT apps dont have to be "100% full screen". You have the freedom to do whatever you want visually, including wrapping JS libraries for animation, drag drop, etc (which I've done with my current project).

In theory, you could write everything in native javascript and then just wrap it using GWT's JSNI functionality. Then you can use GWT for debugging and reliable RPC's. Or if you have your own server side JSON XML parsing for an existing Ajax framework, simply adapt your client side XML parsing to use GWT's XML libraries. Then everything is type safe and can be debugged and unit tested. You can also refactor your JS more easily this way, and everything is more modular. Bottom line is GWT is very flexible. It is designed this way so it can be integrated with existing JS projects.

That being said, I agree with your comment about not everything fits the mold of an Ajax app. Like if you are not building a web application. Rails will be faster and more immediately gratifying in most situations.

"Unless maybe you've done lots of SWT/Swing programming, then you will at least have a general understanding on how to layout stuff graphically and use event listeners."

Now I DEFINITELY don't want to use GWT.

>I haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR.

That is a bit odd, its a bit like saying you couldn't get Dojo to scale so you switched to Postgres. I assume if their startup was happy with ajax idioms in RoR, then they would be mad to build it in anything else, as it does so much for you (but if you stray too far, ouch).

I think it would be interesting to see if the GWT "back end" compiler (which works off its own AST) could be integrated with another language front end. the GWT compiler is indeed impressive - so it would be useful to see it used in general (even if it was from javascript to start with, this sort of compiler would be useful). Although, GWT java code is 100% static, which means they can analise the heck out of it, and compile it tightly. A more dynamic language would not have so much luck unless you forced people to follow certain conventions.

I've had the same curiosity. The GWT compiler essentially parses the Java source code and uses a series of complex rules to convert it to JS. This is why whenever you use any client side libraries you must have the source code itself rather than just the binaries. If the source code cannot be parsed directly, it cannot be converted to JS.

In order for GWT to work for other languages it would need to be totally rewritten, unfortunately. That is unless you could somehow write an adapter for the core GWT JRE emulation library (java.lang & java.util classes). But like you say if the language your adapting to the Java code is not statically typed, you will have a hell of a time b/c the compiler is based on the assumption that the language is still java and therefore static. Like you say, you might end up having to force the programmer to follow certain conventions. Like always naming certain datatypes a unique way, so your adapter could map it back to specific static Java datatypes. But then doing this kind of defeats the purpose of using a dynamically typed language anyway..

Yeah my thoughts. Although I don't know if it impossible - GWT does work of an AST - no reason why other languages couldn't drive it. Perhaps the contenders would be scala (static) and JavaFX markup stuff (which is also static, and designed for UI).

I know its unpopular, but for GUI stuff I prefer statically typed code. It is more verbose, but I find GUI stuff really hard to test (even with friendly tools) and having the compiler do some more work for me I find saves time on silly errors when manually trying stuff out. Yes I type more (or my IDE does really), and I am doing the work for the compiler to some sense, but I find it easier then any other way I have worked for many years doing this.

Its actually ironic (in the alanis sense), I would love a good static typed GUI language, but a dynamic one on the server ;) Maybe my brain is backwards, but I haven't been convinced so far by anyone who has shown me they actually do anything with what they talk about.

I do like JavaScript the language, where its going, when it is removed from the browsers. I wouldn't be unhappy using it more (just less so for the GUI - well I am keeping an eye on where jQuery is going it seems about right as a general tool for front ends for me, but not yet).

JavaScript has first class function (i.e. closures). Java has to simulate them.

Java?

I hear you.

I haven't written any Java code, but I recognize that my opinion was not formed by modern experiences: I was woefully unimpressed with the insanely slow craplets of the late '90s (and Paul Graham's mentions of Java in his essays didn't help improve my opinion of it either ;).

Still, I'd be willing to believe that there are far more skilled Java programmers than there are skilled Javascripters, and something like GWT could only help the move to the web for many applications, especially if it truly helps to bypass the browser compatibility issues, not to mention far simpler testing and debugging.

Reply on news.ycombinator.com