As you know we have recently release the PicNet Mouse Eye Tracking service. This project
We were restricted to having a .Net backend as that is what our existing infrastructure supports and its the technology where we live most comfortably. So the
decision for the backend was simple, ASP.Net Mvc (w/ Spark View Engine) + NHibernate.
own bootstrapping js framework to easily allow OO in js? Do we leverage other such frameworks?
We ended up investigating a lot of different options but this article focuses on one of these which is GWT.
- The language is very flexible and it gives you all the rope in the world to …
- At the heart of the language is the function. This is a concept that is difficult for most OO devs to wrap their heads around
- Performance is such a huge issue, compared to server languages
- Code size (and design) is a big issue
The last item is huge. I mean with Java you use Eclipse or IntelliJ to manage your projects, builds, deployments, code analysis, error reporting, debugging, syntax highlighting, unit testing,
code completion, refactoring, etc, etc, etc. For .Net you have Visual Studio giving the same support. Now try this as an experiment. Write a simple app in Java or .Net using notepad!
(but thats a secondary benefit in my opinion). Now for .Net developers learning to use Eclipse, etc is a bit of a pain but
written in GWT / .Net has huge drawbacks. It is actually so painful that we finally decided to abandon the attempt.
How do you do it
This lets us modularise the html into nice little controls that are easy to work with. This is where we encounter our first GWT hurdle. To use GWT you have to have the html in the hosted server,
What does this mean? Well, basically it means that you have to view the source of your html and copy into your GWT environment. Thats correct, change html you need to remember to copy paste into
GWT env every time. We tried doing crazy things like having iframes pointing to the ASP.Net app from GWT environment with cross domain policies, etc but this always failed.
Ok, this is a huge maintenance issue, however if this were the only issue I think we still would have used GWT given its previously described benefits.
Second issue!! Talking to the server. This issue actually has a few parts, the first is serialisation. GWT offers a few optimised serialisation mechanisms such as XML and JSON (and a custom one).
Since our application used plain strings for its communications, rolling up our own XmlHttpRequests from GWT was no problem (we do this for performance reasons). So this was no big issue at all. The second issue is
authentication. To use our application you must be logged in so in development mode we had to add a hack that would recognise GWT development requests and simulate a user, Ughh!! Still not a huge issue
but getting bigger. And finally the last issue is the fact that to use GWT with a .Net backlend in development you have to use a proxy server. No problem here
is a great article describing how to set this up. Now it is difficult to describe the development process here but I will try.
- Start the hosted mode server
- Oh forgot to copy the new html
- Copy the html
- Restart hosted mode
- Oh, a crash on the .net side
- Done, try again
- Hmmm yes it does look better with that border
So you get my pain?
So my conclusions. GWT is awesome!! Enough cannot be said about how good this toolkit is but it is still too painful to be a real alternative in a .net application.