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...
Related
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 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. ;)
I have been using Dojo and Dijit for more than a year to develop a browser-based IDE. Dojo is a great framework. But creating an IDE-like interface using Dojo is cumbersome and wastes a lot of time unless you are a CSS superman. I have a good understanding of HTML5, JavaScript, and CSS. Building the UI I needed required several CSS hacking that I found by trial and error. There was no systematic way to get from the UI design to the implementation and I am afraid to change the UI layout because any simple change can break the UI, mostly by adding irrelevant scroll-bars to Dijit panes where I do not need them. (the complex UI has 4-5 levels of nested panes including mostly border containers and content panes)
Recently I have come across SproutCore and Cappuccino, which have great demoes and their look and feel is more desktop-based. There has been several discussions comparing these two with each other. But none of them talk about how systematic and quick is it to get from UI design to implementation? Ideally, I should be able to implement the UI I want not more than a couple of days (Assuming that I know the framework), and changing them in the future should be easy.
The other difficulty with Dojo is that I have to work directly with DOM, to append and remove dijit widgets. While I do like to keep this flexibility, I wish I could use a higher level of abstraction to define the application UI. I have read about MVC in SproutCore and Cappuccino, but I am wondering if in practice the provided abstraction layer speeds up the UI development? or the provided layer is a fancy architecture that only increases the readability of the code? Will I lose the direct access to DOM if I build my UI using these abstractions?
Cheers,
Navid
Cappuccino is much higher-level. You write in Objective-J, not HTML/CSS/JavaScript. I personally do not recommend it as Objective-J is a niche language and you'd be stuck with something not widely-understood by everybody. You'll find it more difficult to look for answers to problems, and other people will have more difficulty in maintaining your code.
However, due to it being high level, it does shield you from the drudgery of programming in "standards" (i.e. HTML/CSS/JavaScript). Therefore, you should be able to develop UI's faster and easier, but you'll have to instead learn the ins-and-outs of Objective-J. All-in-all, not much to gain here, I suppose.
SproutCore, on the other hand, is HTML/CSS/JavaScript based, so you don't really have to relearn the basics. It follows the MVC model of separating UI and data concerns, so programming UI's should be easier.
My personal recommendation is to stick with Dojo -- 1.6 has come out, which has change-tracking, state-tracking and bining support. 1.7 is around the corner. The MVC module is improving fast. The next version, 2.0, will be quite awesome. It is being actively developed on, and so you won't be left behind.
Dojo can also be used with the Closure Compiler's Advanced Mode to make highly-compact, highly-optimized, fully-obfuscated builds for deployment. Other JavaScript-based frameworks are not as adaptable.
Cappuccino most definitely goes beyond just improving readability. If you don't want something to have a scrollbar in Cappuccino, don't give it one. That's pretty much the end of the story and one of the great advantages of using such a framework. In my experience, HTML and CSS is just an endless troubleshooting session. With Cappuccino things go where you say they should and stay there. And this is true across browsers as well (most of the time).
Furthermore you can, if you choose to, build your user interface using Interface Builder and Cappuccino's nib2cib utility. This makes it trivial both to initially lay out and to then later shuffle buttons and controls around.
Have you considered jQuery and the jQuery UI?
I'm having trouble deciding if I want a project of mine to be web-based (as in a web-app), desktop-based (a desktop application), or a desktop application that can sync or connect to the cloud.
I don't know if anyone else would have an interest in this application, and it's only going to be for me, so I'm leaning toward desktop application. If, for some reason, I finish it, release it, and people actually like it, I might see about making it sync to the cloud as well (think v2). But I'm not sure how hard it is to make such a radical change, and I don't want to end up with something good that is useless because I made a poor choice before I even started the project.
Is there any sort of guidance for this? Any rules of thumb or best practices? Any personal experiences?
If the language matters, I'm thinking about Java simply because I'm most comfortable with it, and it would easily allow me to share it with my friends for testing and if I get stuck and need help from someone else in person.
I generally ask a few questions:
Can it even be done on the web? Something I did not too long ago involved an image editing component, and had to be a web app. It involved much pain to get this work, and a desktop app would have been a far better way to go.
Will I need to access it from anywhere? Yeah you could load it up on a thumb drive, but the web is far more feasible in this case.
Will there be multiple users? This could go either way, but "long tail" stuff usually means web.
What tech do you want to use? The latest and greatest WPF based UI? Desktop (yeah yeah, silverlight, let's not go there ok?). The brain dead stupid easy user management of Django or others? Web.
If it were a web app, will you need to worry about common attack vectors like SQL Injection, XSS, etc? A desktop app has its own issues here too, but tend to have less exposure.
How resource intensive is it? Will 10 users kill performance of a web server?
Versioning on the desktop can be a pain, whereas with a webapp everyone is on the same version. This can bite you though, see the New Facebook user pushback.
EDIT:
Cost can be a factor too. A web app with a database backend typically means a web server. If you want to stick with, say, the Microsoft Stack, you'll need licenses for SQL Server which can get pricey. Open source is cheaper, but may not be an option in all cases. "Serving" a desktop app is generally cheaper.
If you release as a web-app, you won't have to port it over. You'll also have access to it wherever you go.
I base my choice on the GUI mostly. If the GUI is going to be complex, and (needs to be fast or will have aspects of it that will take a lot of time to process) then I will go with the Desktop. If it is simple, and will always have small data sets to work with at once, the I will go with the Web.
I have worked on an app that was made as a web app, when clearly it was better suited for the desktop. It was a massive failure. I don't know HOW customers put up with it, cause I certainly wouldn't have used it. The desktop version (which took over 6 months to re-write) blew the web version out of the water.
That being said, I have seen some nice web apps.
All I can suggest are several factors that would be relevant. How you determine the answer and weight for the factor is up to you and other circumstances:
What is your audience? Do you have any control over them?
How complex are the interactions you expect to implement?
Do you require near real-time data updates?
How often do you expect to update the application after the first release?
Do you expect a well-defined set of client platforms, or can you not predict that?
Note that your choices also can include a Java WebStart application, which mitigates some of the disadvantages of a typical desktop application.
I'd say that most applications should be desktop-based. The advantages are faster and more fluid apps.
You should only create a web application if there are obvious benefits from it, like access from everywhere. (If that's necessary for your app.)
A downside of web applications can also be that it is dependent on the developer, if you quit supporting it all your users (if you'll have any) can't use it anymore. Furthermore, there is a chance that users are not willing to store their data online.
Ultimately it depends on what kind of an application you want to write. Even if you create it as a desktop-app, you can later on rewrite it for the web. Often a 2.0 version of software needs almost complete rewriting anyway.
Sometime web can be good and sometime not. We are in a new wave that go in the web but do not forget few things:
GUI in web is more complicated because of multiple browser
People who need to work on your system might not like working the whole day in a browser
Web can be slower for some application (image editing, hard job that require a lot of CPU)
Rapid Gui like Visual Studio for winform are faster than for web
But web has many advantage in the deployement and in the portability. If your system is well structured you could make both or change to one to other later with something build with MVC. Just change your visual and you will be fine.
If this were an application to be used my multiple users, with shared data, you're probably going to want a server anyway. In that case I'd lean towards a web application.
Otherwise you've got the complexity of syncing data between the desktop and a server.
Two important questions not on the list so far:
Will the first version have any features that need lowish-level access to hardware?
Will future versions have any featuers that need lowish-level access to hardware?
It's pretty easy to answer the first one, but giving the second one some thought can save you some headache down the road.
My default choice is to go with a web solution, as it's easier to deploy and generally multi-platform. The only time I go with winforms apps is when there are pressing security, performance, or functionality issues that require it.
Previously you'd have written a desktop application, as tool were better for that and you'd have written it faster. People used to want web apps, but always ended up with desktop.
Nowadays things are different, you can write a webservice just as quickly and easily so there's no reason not to go web-based.
The advantages of web-based are flexibility, scalability and ease of deployment. It won't be as responsive as a desktop app could be, but that's not so much of an issue if you think about your design.
I was checking out the TIBCO GI the other day and I was impressed.
Has anyone used it extensively?
What are your thoughts?
What drawbacks did you encounter?
Is it suitable for Internet or only Intranet apps?
I appreciate any input you can shed on this.
Yes, I have used it pretty extensively, here are some of my thoughts. Will add to them as the occur.
I don't rate the approach of implementing the IDE in the framework itself (it runs in a browser window). There are many, many quirks and it can lead to a very frustrating experience. I normally develop all of the JS, XML etc in Intellij Idea using the Javascript debug window to run the IDE itself. After working on a file, it has to be reloaded in the IDE, but its still much more efficient.
Using the IDE, an entire application can be layed out relatively quickly.
There is a pretty steep learning curve. The API is extensive and the community forums aren't great when you do run into problems.
Much of the GUI painting is done using inline style attributes, making them difficult to skin and get the overall application looking exactly how you might want. If is for this reason that I think GI is more suited to intranet apps than publicly available ones.
GI uses a 'dual DOM' approach, holding it's own internal representation of each on-screen element. This can make it difficult to fully integrate other frameworks such as JQuery etc.
As RIAD environments go, I think it is awesome. I find that doing things the GI way is an order of two faster than going down the request/response route.
I really like the enforced separation of presentation and business logic.
The JS extensions they put in, like introspective package, interface and class definitions are quite clever and very useful.
I completely agree with mysomic, but:
Unfortunately Tibco GI has a huge disadvantage of it's weight and how slow it runs.
jQuery is much much faster.
Also I run into issues of different behavior of developed UI under IE and firefox.
Lack of documentation.
I agree with u on some point:
Compare JQuery with GI, I think they are not the same level:
Jquery which implement the CSS searchengine , provide the plugin structure
and some util tools, but it is still like component.
GI , which is the enterprise RIA solution, provide the mapping utility , class interface,extends, implement structure, AMP plugin structure, I10N, I18N etc. it is like the composite level. and also it has the GI IDE, that is every cool.