GWT 2.0: So good it's ridiculous | Hacker News Reader

GWT 2.0: So good it's ridiculous

timepedia.blogspot.com

72 pointsmindaugas46 comments

While, GWT is a very impressive feat of technical accomplishment. It really misses the mark, the problem with it as well as most of the old desktop development (languages, toolkits, frameworks) is that it favored the developer over the designer. This is one of the reasons for the popularity of the web, it allowed the designer (and the want-to-be designer) the ability to design and build interfaces without having to know a turring complete languages.

When I first started looking to do more dynamic web applications, I was convinced that toolkits like GWT and Echo2 where they way to go but I was reasoning from a Java developers perspective. It makes the job of a Java developer easier, while adding complexity to the task of the designer. This is all well and good when you have a 1-5 man team of experienced Java developers.

I now prefer to use Java (Ruby, C, whatever) to write business logic services on the server and use HTML, css and JavaScript on the client. by writing a UI controller in JavaScript that gets embedded into the HTML file via a script tag it gives very clean separation of HTML, CSS and code this allows a large team to work very productively. Designers work in HTML, CSS. UX developers work in pure JavaScript and business domain developers work in their language of choice.

This coupled with a CMS has allowed us to abandon the kludge of a server side document scripting language (asp, jsp, php) entirely and significantly reduced the complexity of delivering a web application.

You should give it another look - GWT2.0 has declarative UI language and HTML can be directly embedded into it.

You should look at UiBinder (part of GWT 2.0). You write HTML and CSS, stick it into a UIBinder template. And in 5 minutes you can take a designed mock and have it bound to a Java class in a very efficient way.

You get things like CSS namespacing and obfuscation for free with this approach too.

Thanks, I will take another look at it.

I believe there's very limited role of "design" when it comes to application development: people want consistent look and feel in all apps, they want to reuse their skills and not having to re-learn how to add an item to a list for every little piece of software.

It doesn't mean that everything needs to look like crap for the sake of consistency: just look at Cocoa-based software: you don't need a designer to build a great looking GUI on a Mac.

Why is web different? Because it stands with one foot in its past: a UI screen is treated like a "page", a magazine cover, hence the false need for a designer. The result? More often than not you get a gypsy blanket instead of a modern user interface.

This reminds me of the DOS era when developing a graphical application felt like building a game: you needed to design buttons, scrollers, etc. Yeah, funny I haven't thought about this before: web-based GUI feels a lot like MS DOS apps: for a developer as well as for the user.

I think it really depends on the app. Sure for some apps all you need is some buttons and some input fields. But even in the not so old days of desktop apps we had Authorware, Macromedia Director and HyperCard because some apps are not just data input apps, and this problem existed back then, it was the reason for the afore mentioned application builders if you will.

You mentioned Cocoa and it is funny that you do, because I think that Apple is one of the ones that got it right (I have only done IPhone development, so forgive me if this does not apply to OSX proper). But with the nib file abstracted away from code it allows a designer to build screens, lay them out and then move them on in a work flow to a developer. Allot of the more modern desktop development languages / frameworks now have this separation but it is relatively new and the web seems doomed to follow every incarnation until it too finds that separation of different technologies is the cleanest way to build a system.

The web is a different beast, while there are pure application many of them are hybrids I think Linked-In or Facebook are a really good example of these hybrid application/documents. They are very interactive but at the end of the day they are a document that sums up either my personal or professional life. With them usability and design is just as important as the code that sits behind them.

GWT always sounds interesting, but I am underwhelmed by the application gallery. Every app looks like a draft version of gmail, google maps or google wave. Any links to impressive interfaces (non google-built)?

blueprint by lombardi is pretty good

https://blueprint.lombardi.com/

"Your current web browser (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9) is not officially supported by Lombardi Blueprint. If you experience any problems using this site please install either Microsoft Internet Explorer 6+ or Mozilla Firefox 3.5+ before contacting Blueprint Support."

I would say speed tracer, but that is google-built.

I suggest looking at the EXT-GWT library for what is possible. I'm using it in a project where its GPLness doesn't matter.

It depends on your needs.

If you don't want to modify the widget appearances or behaviors, Ext-GWT is nice.

If you aren't building a large web-app, Ext-GWT is the way to go.

But if you're one of them people who prefer to do TDD, or unit-test etc, avoid Ext-GWT at all cost.

If you want to personalize your app, avoid Ext-GWT at all cost.

If you want a solid (library) Java code, avoid Ext-GWT at all cost.

I've been using their code since MyGWT 0.4 and right now we're trying to get rid of it so bad.

I was also using it since mygwt. But they did a "bait and switch" when they moved to ext; I lost months of work.

We build TeamPostgreSQL with GWT. It is a PostgreSQL web administration package. Feel free to to take a look:

http://www.teampostgresql.com

The download package comes with a bundled sample database, so you can take it for a spin too. Feedback welcome.

I have some feedback:

- I was totally confused how to launch this - I couldn't discern any benefit of this over phpPgAdmin minus the nicely done interface - I couldn't discern any benefit of this over Aqua Data Studio, NaviCat, et al. sans pricing.

I'm really curious why you chose to do this as a web app. If the benefit is to give "managers" and others access to the database to run reporting, where is the graphing, pivot table, etc support? If it's to give other developers access, your desktop counterparts (specifically Aqua Data Studio) provide tools you are lacking (code completion, diagramming). Granted there is a sizable price difference, which could be a selling point, but again phpPgAdmin does all that you do and is free and extensible because it's OSS.

The screenshots are too few and show too little. I get the impression of a very simple "me too" app that can do very little and provides no benefit over the cmd line. At least a screenshot for every bullet point in the details, and show how you handle corner cases such as columns with 10K text.

Ditto jawngee suggestion about creating "end user" pages with standard reports (e.g. graphs using http://www.simile-widgets.org/timeplot/). Allow me to let users view them without logging in. That is what cmd line can't do.

Thanks for the feedback, it is valuable. I will make sure we take a long hard look at the points you mentioned.

The product is still a few features away from being ready for the public launch, the value proposition should be more apparent when we get there.

MediaBeacon showed off a really cool GWT-based product at Campfire. They've built the equivalent of a desktop application inside the browser (full drag-and-drop, file management, etc). The video is up on their website: http://mediabeacon.com/

I'll also plug our GWT-based product, DotSpots. I'm dogfooding it on my blog at http://grack.com - just select one of the paragraphs or click one of the blue dots to see the UI. It's an example of a non-traditional GWT application: we're running our own GWT code inside of a foreign website. Our website is more of classic GWT application, but we compile both of those targets (as well as Chrome and Firefox extensions) from subsets of the same codebase.

www.kdice.com

Those who like statc-typing will always find it ridiculously great. Those used to dynamic-typing will find the idea of writing JavaScript in Java ridiculous, but not great.

There is wisdom in the middle.

Well put. Thank you.

"Those who like static-typing will always find it ridiculously great."

People who actually like static-typing probably don't like Java, but something more like Haskell.

Let's call Haskell "extremely statically typed"

How could trading the expressiveness of JS for the expressiveness of Java without the commensurate increase in performance be "So good it's ridiculous".

You clearly didn't RTFA.

I'll give you my personal reasons for liking GWT in a few short bullets.

1. Better tooling - IDE refactoring when I need to change things. Red squigglies when I make a typo or reference something thats not there. A real debugger with breakpoints for finding bugs. Auto completion and auto style formatting so I dont have to type so goddamn much.

2. Compiler optimizations - Your code gets faster and smaller. Write maintainable code, have it turned into performant code.

3. API's and libraries - easy client server RPC, discoverable wrappers for the DOM APIs. Reuseable widgets that have predictable structure/side effects!

4. Maintainable code base - If you worked with more than 4 engineers on a non-trivial product, you would understand the appeal of a Java code base. UIBinder lets me not worry about CSS name collisions.

I would go on, but you seem like a TLDR type of person, so it would probably be a waste of my time.

Was the personal attack at the end necessary?

Agreed.

Probably not. I sometimes get annoyed when people, faced with the choice of gaining some domain knowledge before forming an opinion, decide to instead just be loud about things they know little about.

Personal attacks are lame though, even on the internet. Thanks for calling me out on it :).

I apologize.

Good response to the question, which was clearly loaded

1. No reason you couldn't do this in JS (see Smalltalk)

2. The new JS VMs do plenty of optimization

3. C has more libraries than Java. Lets use C for everything

4. Actually, there is a lot of evidence that maintainability is inversely related to the number of lines of code. The more lines, the more bugs. (I don't have time to find the studies. They are there if you Google them.)

I did read the article. I just wasn't interested in writing a treatise on the subject. Just wanted to give a counter point.

The performance that GWT is able to get is impressive. There are all kinds of optimizations they can make because of the assumptions they have, especially that you will run the code through the compiler.

Why ask this forum when the article explores this in detail?

Does it, really? Most of the optimizations mentioned in the article (compression/obfuscation, module system, yslow integration) or in these comments (debugging, refactoring, auto completion) are all available/possible in javascript alone. What tangible benefits require Java's type system?

Guided code splitting and type tightening (with associated devirtualization) are serious optimizations that can't be done today in JS. GWT can guarantee the immutability of JS object shapes - something you can't do with bog-standard JS.

Pardon my ignorance but is there a clean way to run GWT with non-JVM server side languages?

Define clean.

Doesn't require some third-party (which tend to lag behind the latest versions) library to get it working and I can write normal server side code in Python, etc.

You can run a REST server and make your callbacks using JSON. That's what I did a while back. PHP could be used without problems.

I've done the same in the past (Python backend). I'll add one more suggestion on top of that. You can create JSNI bindings for all of the JSON RPC objects with GWT to get compile-time API checks that disappear entirely from the output.

Yes, you can make XMLHTTPRequest backend calls, although it's a bit of a pain to debug due to same-origin policy. If you get to this basically you have to turn off built-in GWT server and use your own to serve both GWT-compiled code and your XML requests.

The problem with GWT is java, which makes it meh.

I've been working on a .NET clone of GWT as a side-project for awhile. It doesn't have a widget library yet, but it does have web-mode and development-mode. It works by decompiling MSIL which means you can use any .NET language you want.

http://github.com/flaub/DotWeb

Not much in terms of demos, but the core technology is all pretty much done. Plugins for FireFox (NPAPI-based) and IE work so that you can set breakpoints in Visual Studio. Web-mode does a decent job of optimizing right now because it does method dependency analysis.

Yo should make a post about it. Make sure to mention how it relates to similar Microsoft's own efforts.

Yes GWT 2.0 is impressive but haven;t we had 3 submissions on that in the last week.

Surely nothing new is being said here.

Yeah, what we really need is more of those late-breaking Erlang articles!

No, we don't and i never said we did - but articles summarising the points that are already present as summaries in the GWT 2.0 release notes definitely do not add anything to the discourse.

Reply on news.ycombinator.com