I've heard the Google Web Toolkit isn't that good for web sites with more than 5 pages and a common layout. Is that true? We have at least a 100 subpages and a common layout defined in CSSes. Today were using PHP but we will move to a Java front either Spring MVC or GWT. We're using som jQuery AJAX and other jQuery components like a jqGrid. We also have some .swf-films and fusion charts. Will opting for Spring combined with GWT be a good choice or is Spring MVC with a jQuery library a better choice for us?
It's not true now. Earlier GWT versions really had some issues with scalability (e.g. problems with JS code size in IE - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440), but since GWT 2.0 you have no limitations here.
Moreover, latest GWT versions support functionality for splitting projects to the parts that may be loaded dynamically when they're needed. Please refer to https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting to learn how it works.
Take into account also that since Spring is Java, you have possibility to share classes between server- and client-side. Plus Java has very good support in IDE - all kind of refactoring will be available for you (it is not so convenient in case you use jQuery).
So Spring+GWT looks more preferable choice.
GWT is not a universal framework for building just a any webapp from scratch. It is very useful when you have a lot of complicated logic on client side, (image editing, real time collaboration, diagram drawing, games , complex reports building and etc etc). But all of this can be done without GWT.
GWT can be used when:
your team hates/dislikes JS (and is unable to build nothing complex with JS, just because they hate JS)
your team is quite experienced with Java
your team understand how all this browser related stuff works (HTTP, JS, DOM , CSS and etc)
in this project there are will be a lot of logic running on client side
I've seen quite a few big projects built completely with GWT. Some of them should never used GWT, because the were no reason for them to use it in such way. For most projects it is enough to use GWT only for some part of application.
The choice depends on your team and the project you are doing. If your team can't really see what benefits GWT will bring to the project, then you shouldn't use GWT.
Our enterprise-level application utilizes both and we're quite happy with the results. GWT is a powerful toolkit which lowers development time by orders of magnitude. That said, there are still things that GWT either doesn't handle all too well or just plain isn't suited for (and that's ok... that's why Spring MVC lives nearby). We have GWT-RPC hitting Spring services directly and it works incredibly well.
Our project though is a true webapp, not a website. We use a unified design which spans all "pages" (using a DockLayoutPanel and swapping out just the center makes this super easy).
IMO, whoever told you that GWT isn't good for consistent design across numerous "pages" is nuts...
I think any assertion that GWT (or any other method) lowers development time by an order of magnitude has already been debunked by Frederic Brooks in a time when shoulder pads and Jan Hammer's synthesizer were fashionable: http://en.wikipedia.org/wiki/No_Silver_Bullet.
But seriously, if you're a PHP shop, moving to 100% Java would be a huge investment, and not to be taken lightly.
On my experience of GWT, my only bad experience was with GWT compilation slowness due to lot's of permutations. Our application had more than 20 languages to support, which multiplied by 6 for browsers specific result in 120 permutations, which proved to get horrible performance.
But this is not a real bug issue, because you'll mainly use the dev mode, with instant code update, and you can have special compilation unit with reduced set of browser and language (even one language and one browser => one permutation if you wish).
So in my case, using Jenkins we made the big prod target full build nightly, deploying on a QA platform so that the QA team test every browser language combination. And on every commit a reduced build (1 browser and 2 languages in our case) was deployed on a dev validation platform.
GWT is definitively a great tool for large app. ;)
Related
I have an old web application (in asp.net) of almost 100 pages which is compatible to IE 6 so I want to revamp it's UI because it gives browser compatibility issues and doesn't look cool either. Now I am confused what things should I use and in what order to save time and avoid any error/flaw. Here are some questions:
1) I am thinking of using HTML 5 and make it responsive
2) I also heard of Angular JS, should I use it, if yes then where ?In my project java script and jquery both are used.
3) Should I use MVC ? But I am afraid it will require change of code which will lead to wastage of time. But it will make website faster.
Using MVC would surely speed up UI changes in future - all UI-related code would be separated in view part of code. If you can afford redesigning your code (it's gonna take some time), it's probably worth that, considering future maintenance.
If you want to create a good, responsive UI, according to modern standards - maybe have a look at Bootstrap (http://getbootstrap.com/) framework, or similar solutions (such as Foundation - http://foundation.zurb.com/)
The question is quite simple:
Can we use JavaFX as a thin client running on a browser while a java server does most of the work?
IE: cretate the UI and it's controllers with JavaFX and have the bussiness/database connection/etc part run on a server?
Even if possible, would it be a complicated turnaround?
Based on the information you've provided, I wouldn't necessarily say that JavaFX is a good fit, but on the other hand I would not worry about the load times. My rationale is: The bad thing about JavaFX is that you have an additional tech requirement for your clients (JVM) and require some form of installation (even if it is just an applet). Those won't be a factor for HTML5. JavaFX has benefits over HTML5 if one of these cases is true:
1) You have complex controls and/or a lot of user interaction with the UI
2) You need your application to be really flashy, e.g. by incorporating animations
3) You have a complex business logic that you would like to execute on the client (e.g. because you had a previous implementation as a rich client)
'Some tables and simple controls' don't really fit here.
The reason why I wouldn't worry too much about the download time is that most users of an enterprise application will be using your app a lot from few different machines, thus caching should deal with that problem (plus an FX app is not going to be that large).
There is an interesting article on the topic to be found here: http://www.oracle.com/technetwork/articles/java/casa-1919152.html . Since it is coming directly from Oracle, you should of course take it with a pinch of salt, but I for one do agree with the general notion. The article also outlines some (subjective) experiences when switching to JavaFX.
If it's an enterprise app, and you already know that your users will have java installed on their clients, javafx is a good solution. If not, the downloading of the javafx jar can be quite a buzz kill the first time an app is run, as it's quite (understandably) large. I'm using it for enterprise apps, and the web start functionality works well.
And don't forget, if you're using jdk 7, there is a javafx packager which will create a single file installer/run-time for your app. I can't provide a lot of detail for that as I haven't bothered with it yet.
I've played a great many MMORTS games such as Evony, Dragons of Atlantis and Kingdoms of Camelot. They all have some great features and a great many not so great problems. Simply for my own interest I wanted to try my hand at writing something similar. I don't intend to even try to compete with the big boys but I wanted to write it in a professional and scalable manner as if it was intended for eventual commercial release.
So that's the background that leads into the question. I have been looking at various frameworks and libraries that would be suited to this style of game. However there is such a plethora of options that my head is now spinning. I would like to get some input as to what other people think are the best options. I want to try and write this as a cross-platform / cross-browser webapp that can later be converted to a "Native" app using something like MoSync. I want to stick with HTML5, CSS3 and JavaScript technology.
Some of the things I am sure I want are:
It must be scalable (ie able to handle a significant number of simultaneous users)
I prefer to work with some sort of MVC framework (I am used to working with Joomla MVC and have been considering backbone.js for this aspect)
I am no JavaScript guru but will most likely want to work with jQuery (mostly in relation to client side views)
I like templates but am completely lost which template system to go with (ie mustache, handlebars, dust etc). I think my choice in this area will ultimately come down to which framework I end up with.
Chat is an important aspect of MMORTS games and I am thinking of using Node.JS and Socket.io (or NowJS) for this.
I have also been looking at Redis for key-value store.
At this stage I have abandoned the idea of using jQuery Mobile as initial tests have caused more headaches than they have solved.
So my front runners are Node.JS for server side JavaScript (possibly with NowJS to implement chat), Redis for key-value store, backbone.js for the MVC framework, mustache (or maybe LinkedIns fork of dust) for templating and Jquery of course.
I would greatly appreciate any input to help me make my final decision on what frameworks and libraries to use.
This is not a framework, but you may find Mozilla's Browser Quest implementation interesting. The whole thing is open source and they use HTML5 Canvas and Node.js (socket.io is a big player here) and it is entirely cross-platform
I'm working with a team on exactly this. Our research and experience suggests that a Node.js backend is definitely a good idea. What to use with Node.js? We've come up with two good possibilities:
Use websockets for communication and a front-end engine like Phaser for your rendering.
Use Isogenic Game Engine for everything.
(http://html5gameengine.com/ may help you to compare the feature-sets of the top HTML5 game engines including the ones I've just mentioned.)
I'm going to develop a web application using SmartGWT. I've heard about Vaadin framework. I wonder what is the best to use?
My application will be used by ~500 users at the same time. And I need high response performance and high security control. I won't need dozen of pretty widget just enough to be able to use pretty tabbed pane and table. So what is the best choice regarding my needs?
Edit :
I'll also need a tool to export table content to Excel format (like in Google Doc SpreadSheet).
ps : already check this one Should I use Vaadin Framework
I looked into both these frameworks, and others, and decided to go with the core GWT widgets. You desire to have high response performance will be difficult with Vaadin since it sends almost everything back to the server. And if you don't need super fancy widgets then the core widgets (plus some incubator/3rd party ones as needed) should be fine. I didn't get deep into testing SmartGWT, but it seemed to really tie you into their framework (making it difficult to use core widgets as well) and I read about difficulties when starting to do things different than the showcase examples.
Good luck!
If you write your Vaadin application properly, it will be performing perfectly well (check this one: https://vaadin.com/wiki/-/wiki/Main/Optimizing%20Sluggish%20UI).
If you know SmartGWT, use it. Also, if you have no experience with Vaadin, use SmartGWT. It might take you a lot of time to learn Vaadin (it requires some practice after one is able to create well performing application). The biggest problem of Vaadin that it is very easy to write slow application - because everything seems to be so easy and one tends to use many components and so on...
Web based systems (Client Side GUI only) are known to be platform independent, But, are they development-platform independent too??
To the best i know, Client Side GUI will always be built using HTML and JavaScript/VBScript or Java or etc which are supported by all OSs and Browsers to make it independent. I am concerned about the change in GUI-code if the server side platform is switched e.g. from ASP.NET to PHP or Java or from x to y?
If it depends upon the way the GUI is designed/developed then What should not be used to make this impact as minimal as possible?
Regards
Atti
You would need to use frameworks that are platform agnostic or write your views in plain html + javascript + css yourself.
Platform agnostic frameworks would help to seamlessy deploy your UI layer, or views, onto different operating systems.
If you also plan to change the development language, you will probably have to write the html, javascript and css for your views yourself because to my knowledge there are no popular frameworks that can be used on different languages.
Most frameworks are designed to work with a specific language/runtime and provide you with a level of abstraction that hides the gory html, javascript, ... details for you for a more natural development experience.
The code is then transformed by the framework into pure html, javascript, css, ...
But in case you want truly agnostic views, you will have to give up that abstraction and write the html yourself.
Not an easy task, not because of the fact that html and javascript are difficult per se, but cross browser compatibility is a bitch, plus you lose the benefit of well tested components.
The end product, on the client side, is always platform independent because it is nothing more then html, javascript and css, which is supported by all operating systems
If the client GUI is written in JavaScript and does all communication with ajax and json, you can swap out whatever back end you want as long as it provides the same api.
It also depends on how you build the site. If you are using, for example, java based html widgets, it will be harder to replace with the equivalent in say cold fusion.
But changing the back end is usually an exercise in futility since you aren't really giving the end users anything different. Often it's overzealous programmers that want to rewrite the back-end for no good reason. Don't do that.
I thought it worthy
The Web is Not Platform Independent
Typically the server side of an HTML application should not impact the client side. Meaning that if you stick to JavaScript only components on the client, you will be able to change the server side any time you want.
The problem with JS programming is however deeper than just browsers compatibility (which is already a huge problem). The following are not well considered problems:
Performance - JS is the slowest language on earth.
Inside the box - JS offers interop only with the browser DOM, and a few other things. This means that any application that wants to be "native" for a specific OS must not be implemented in JS.
So maybe you need to investigate approaches that have a "native" client UI. Such as Java for example.