3 ms·
But the big thing missing is the old javascript pain point : if your frontend is in javascript, and your backend in C++ or java or php or python, you will have
by waps 12y ago
But the big thing missing is the old javascript pain point : if your frontend is in javascript, and your backend in C++ or java or php or python, you will have translation issues between the two. Things will go wrong. Server and client don't handle the "RPC" quite the same way. This will bite you again and again.
If you have a real one-page (the only way to go responsive) web-app, once you hit a certain level of complexity GWT is the only way to go. Javascript <> Frontend <> middleware <> backend <> database (using the right framework), all statically typechecked. You NEVER get a fieldname wrong. Checking if a call works ? You don't write tests for that, because static typing means it works. Need the same RPC calls to work for an iOS app, an android app, a desktop app, ... ? They can share all the model code (literally, the same lines of code, same bugs, same everything) and only need custom views and controllers (which you'd have to do differently in any language). Backend is simply identical, and java supports secure RPC to all these platforms, all of whom process data in exactly the same way.
Plus : GWT makes dynamically creating user interfaces tolerable, something I still have nightmares of doing in javascript.
But my main complaint is controlling complexity : in javascript, you can forget about it. 500-1k lines of javascript nicely working together really does mean you have a good programmer. You can effectively not load more than 1 javascript library without unwanted interactions (exception being the many Google libraries that do seem to work together, but combine them with jquery and you'll already see surprises). The point where complexity starts exploding is very low. PHP/Perl/Python/C is a little better : you can generally expect a good programmer to be able to get ~10000 lines to work together nicely without very serious problems. Java/C#/C++ allow you to control complexity on a large scale. 100k, 1 mil, 10 million line codebases are possible and (can be) maintainable in those languages. Now keep in mind that sucky programmers suck in any language, I'm talking about good programmers
Yes, angular is really fast to make a tiny form with "standard" functionality. If you think that's going to do anything more than get you a standard app without armies of programmers (like Google has), you're deluding yourself.
Plus let's state the obvious here : people hate javascript for good reason. Good language, considering it was a weekend hack, but horrible language compared to anything else out there. Java, flawed as it is, is massively better than javascript. Also : once GWT frees you from frontend/backend integration and ridiculous testing you won't want to go back, and of course there's the java library ecosystem that is very extensive indeed.
- nostrademons 12y agoConsidering that most Google Apps (GMail, G+, Docs, Calendar, etc.) are single-page webapps with over a million lines of JS, I'd hardly say "GWT is the only way to go". The programmers I know at Google who worked on complex GWT apps (notably Google Base and Adwords 3) didn't have very many nice things to say about it, besides the Eclipse integration. The Java/JS integration is handled the same way it's handled in any large distributed system: define a protocol for the server and client to communicate. Only evolve the protocol in backwards-compatible ways. You need to do this anyway if you expect user sessions to survive server upgrades, because you may have an old client talking to a new server. I'm curious how GWT handles this case - if it's autogenerating communication responses, it needs to be aware of both old and new versions to safely upgrade them.
- skybrian 12y agoI'm most familiar with GWT-RPC and it doesn't have any backward compatibility built in, so most deploys are a protocol change. (It does at least give you a clear error when there's a protocol mismatch.) So if you want old user sessions to survive, you'll need to keep the old service available until they reload the page. There are protobuf/JSON-based alternatives with a better compatibility story.
- johnyzee 12y agoIt's not true that most deploys are a protocol change - only changes that would also change Java serialization's serial UID will cause GWT-RPC clients to become incompatible. I routinely deploy a new version while hundreds of users are online and nobody is the wiser.
- skybrian 12y agoWell, that's true; it depends on how complex your protocol is and how often you change it. Simplicity is good! But this can be tricky for large, distributed projects, where the author of a class might not even be aware that it's used with GWT.
- 12y ago