Comment by vlad | Hacker News Reader

Comment by vlad | Hacker News Reader

Parent Full thread

I disagree. I believe the opposite: GWT is a bad choice, mainly because GWT has to be compiled every time. It's much better to use a framework, including ones for PHP, since PHP is faster than Ruby and most popular frameworks have memcached support, and a great community.

Also, most frameworks are evolving FAR quicker than GWT is.

Thirdly, GWT will still require server-side coding. You might as well use a framework with an Ajax library or just plain html output, and then add-in GWT or Adobe Flex later, if at all.

Fourth, GWT does not have anywhere near the community or IRC users that most frameworks do.

But, mainly, GWT is a bad idea because it loses the advantage that web frameworks give to web startups over desktop development. That's because using GWT can be even slower than using traditional desktop development tools like Visual Studio because you not only have to compile, but also upload the files to get a real idea of what you're doing.

Why not just use a console with a web framework, or something with both in one like Seaside? As soon as you save the file, the change exists.

There are a few misconceptions about GWT in the above comment:

"most frameworks are evolving FAR quicker than GWT is."

GWT is only a year old and has had 4 major releases. It just went open-source recently, so it's too early to tell how fast it will evolve.

"GWT does not have anywhere near the community or IRC users that most frameworks do."

GWT community is huge - there are over 600 posts a week on its Google Group. I'm not aware of an IRC channel for it though.

"using GWT can be even slower than using traditional desktop development tools like Visual Studio because you not only have to compile, but also upload the files to get a real idea of what you're doing."

No, you only need to upload files when you're actually doing a release.

You used the word misconceptions, but I don't think I was wrong about anything I said if you read what I wrote carefully.

I'm not sure where you disagree since you are defensive about GWT, when I never said it was bad, just that using a web framework is a much better idea, especially at first.

How can you predict how many users GWT might have in the future when Adobe Flex and Apollo are around the corner?

On the other hand, the server-side coding won't change from PHP, Python, or Ruby for most startups over the next year, however, and their web frameworks are much easier to use and integrate than GWT.

I like GWT, but I think it requires at least one or two additional orders of magnitude of time to get something going. Plus, you'd still have to write server-side code to handle the ajax calls, so you may as well need to start with a web framework anyway!

And remember, you don't have to compile all the time with web frameworks.

Finally, the "major" releases you mention have been very minor. For example, One of the VERY few releases GWT has had in the past 8 months involved Google changing their source to be open source, without making any improvements that I can remember.

If you started with a toolset, you should stay with it. But if you're starting a new project, use a web framework.

What would be great is if this prediction comes true:

http://getahead.org/blog/joe/2007/05/11/googles_next_open_so...

Adobe Flex a very different approach to the rich client model. GWT will be on the same side as Prototype, Dojo, etc. if there is a showdown with Flex. Flex is not an alternative to GWT but rather an alternative to AJAX. I suspect both sides will continue to coexist peacefully.

Keep in mind that GWT is not a full web framework. So it's pointless to argue which is better, web framework or GWT, just like apples and oranges. You can use GWT with whichever back end framework (e.g. Rails) you want if you choose to go that route. Like I said earlier, GWT is an alternative to JS frameworks like Prototype, not server frameworks like Rails. What GWT does allow you to do is not use a web framework at all since its server-side calls are very easy to implement. But if you require a DB, etc, you can still use Rails and GWT.

If you get your eclipse and ant build scripts setup right on your development box, deployment takes a single mouse click. It takes me ~10 seconds to sftp changes to pre-prod, stop tomcat, build, compile, and restart tomcat if you change your java class files on my W2K3 production server also running a stripped down version of eclipse (even less if just working with web files or jsps)

Reply on news.ycombinator.com