The post which will bring some very very interesting discussions/debates/fights. Here it is. (Before starting flames on this post, do read the last line note.) When I co-founded this company and decided to work with early stage startups, I was faced with technology choices. Ruby was (is) getting mainstream momentum. Many startups were using it. PHP, no matter how much I dislike it, was still used widely. Python with Django was also started getting some ground. .Net and Java being as important as ever. Choices were there, all looking good on surface. Features were all there. We decided to evaluate all these technologies. We both come from deep roots in Java and object oriented technologies and do have some bias towards it. But still we tried to do our best. We listed down all pros and cons for all these technologies. Investigated all of them. Build sample projects/apps in all of them. Talked to experts, technology mentors. Also while making the choices we had some limitations on ourselves and this choice should be evaluated against these limitations. Limitations - 

• We are not building one single product. We will be building many products, for diversified set of applications. For mobile, for web, for enterprises, for embedded devices and may be even for space crafts.
• Talent acquisition, training and retaining costs. Though we build cutting edge products, we still are a services company.
• We use our services arm to groom engineers. So finding projects on same/similar technology which can be executed by services division was also essentially, but this was more of an nice to have feature rather than limitation.
• We will be working for many startups in next few years. We want technology to support creation of off-shelf components and using them with multiple startups where ever possible.
• Knowledge transfer for code/design and technology should be minimal. Again nice to have but not exactly a limitation.

Okay, so once you know the background, here is our clear choice.

Java all the way.

We decided Java provides the best technology choice we can make. True, for web applications Java is not exactly a suitable choice. So, we started thinking which is the technology that can provide UI features and sit comfortably on a Java backend? You can use any technology for that. But again doing lot of investigation, search (we dont call everything as research) and came to conclusion that Google Web Toolkit is the best technology available.

If you refer to previous post, I have outlined majority of things we consider or should consider while making choices. So how does Google Web Toolkit (GWT) ranks on all this. If you dont know what GWT is, I will suggest going through some basics before continuing.

Feature set -

• Provides cool Ajax stuff like fading pop-overs, drag and drop and many such things in built.
• Though most of the features are available with other technologies too.
• Templating is one of the most important feature for UI side technology. Is there any better templating engine than a class? I dont think so.
• Why one should learn weird things like % % terminated tags? Weird UI side syntaxs? With GWT all you are doing is writing classes and implementing methods.
• Already many UI design tools are available for GWT. Writing your own is not a big problem. All you will be doing is churning out classes from the design tool. Hence performance and usability of such tools is much better for GWT than for other things.

Performance - 

• On UI side it is just HTML and Javascript code. Java code cross compiled into HTML + Javascript + CSS.
• This Javascript code is maintained by Google and open source communities. This gives it chance of getting better and better with every release. Hence more optimized.
• GWT is not much of code generation, but more of code replacement, hence limitations that code generation techniques have are not completely applicable to GWT from performance perspective.
• Browser specifics etc are handled much better.
• No need to write Javascript on your own, unless you want to write your own plugins. Even then, you write the Javascript, write a simple module to cross compile Java code to that Javascript and you never have to use Javascript directly again. Release that plugin into wild ie open source communities and it will keep evolving if its good enough.
• So performance not an issue with GWT on UI side.
• On backend its Java, so performance can not been an issue there. Java is proven for that.
• Also lot of performance improvement tools are available for Java. Caching systems, search engines and many such goodies are there well performing, which can be easily integrated.

Maintainability - 

• GWT code is essentially classes. We know that classes are more maintainable than PHP/JSP or other text files.
• Since code is just classes, you will be drawing class diagram, sequence diagram instead of screen mocks and screen flow. Now UML digram are backed up with specification and hence more maintainable.
• Two programmers can work on same class (but not on same plain text file) without giving too many check in conflicts. Great thing to have when quick fixing is required and you are fire fighting.
• Classes are structured, governed by OOD and OOP concepts. Its very easy to understand code written by some one else in the format of class than in a text file, even if we assume zero or 100% documentation. Also this helps in code-reviews, peer reviews and other audit processes.
• Using UML design philosophy and OOD/P concepts, code written is much cleaner, well organized and in fact much lesser than others. So much easier to maintain.
• I can not stop raving about how maintainable GWT+Java code is!

Talent acquisition -

• There are thousands of Java programmers out there who are good in Java and understand HTML/CSS basics fairly well.
• No need to have Javascript wizards in the team, if you are working with GWT.
• Java is backed by Sun certification, if you believe in certifications which I dont much. Always good to know that some one is making money by certifying talent. You need not have to rely on them, but its a nice to have thing.
• So in short, talent acquisition is fairly straight forward, plenty of choices.

Distributed team work -

• I have covered these things in maintainability but to make sure one understands the importance of the same from distributed team work perspective too, I am reiterating in next points. If you know how they apply for this, then skip to next bold point :-).
• Class diagram, sequence diagram help in communicating thought process in more concise and clear way. With UML specs in place, you are sure that what you are saying is not misunderstood on the other side on internet pipe.
• Lots of tools, techniques available for Java to help in minimising issues related to distributed team structures. 

Eco-system - 

• Java has a very very vibrant community. A little too vibrant for my taste actually.
• Lot of open source communities and products have made millions of dollars. JBoss, Hibernate, Apache are only few examples to note.
• Java is backed by Sun which is a multi billion dollar company. There revenues, not all but part, are dependent on Java and its success.
• Though Google, does not make money out GWT, at least for now, it cant just let GWT hanging. Google brand name is associated with it.
• Already there are tonns of communities which are creating wealth by GWT plugin development, support, tools are there.
• This can only grow from here.
• Many outsourcing vendors are available for GWT development, as it is nothing more than plain JEE development, a little easier in fact.

Time to market - 

• As I have mentioned already in last post, that time to market is not counted from development day zero to release. But it is counted from inception of the concept to release. This include time for team building, trainings and everything.
• Considering all that time to market is much lower or at least same.
• Also lot of people who say Java is slow in development, never used any code generation tools. Never have actually seen a world class product being developed using Java. There are many things one can do to speed up the process.
• With GWT tool support is even more rich than for Java. Hence using excellent tools infrastructure and good design principles GWT+Java app is much faster developed or at least with the speed as a python app is developed.
• Also dont compare time to release first screen as a measurement. Yes, I agree for Java or Java based apps, getting first use case running smoothly gets some more time than others. That too if you are very rigid about following processes. But once you have that one use case flowing, rest of the things become very mechanical, apart from the algorithms. We generally generate the code using custom annotations etc once we have that first use case. So all we need to implement is the backend logics.

Open for discussions.

Note, I am not saying other technologies (apart from PHP :D) does not have these features, but they are not as evolved as Java. And this is not a polical statement!