Have you all seen this? http://www.smartclient.com/product/competition.jsp
Vaadin comparison seems inaccurate and misleading.
Thanks for pointing this out. I’ll send a message to SmartClient team and ask if they could correct the situation.
The Vaadin column should be as follows:
Client Features
- Basic UI Components: check
- Calendar: commercial add-on http://vaadin.com/directory/#addon/vaadin-calendar
- Client-side Events: -
- Adaptive Filtering: -
- Pluggable Data Model: check
- REST support: -
- WSDL/XML Schema support: -
- Skinning / Branding: check
- Printing Support: check
- Advanced Filtering: -
Server Features
- Server Data Binding: check
- Server-side Validation: check
- UI Auto-mapping: -
- SQL & Hibernate Connectors: check (SQL connector included in core, several JPA/Hibernate connectors available as free or commercial add-ons from http://vaadin.com/directory/)
- Queuing: check
- HTTP Proxying: - (not needed because with server-side Vaadin there is no same origin policy restriction)
- Excel Export: -
- Advanced SQL & Hibernate binding: -
- Batch DataSource Generator: -
- Batch Uploader: -
- Visual Builder Team License: check (a free visual builder is included with Vaadin Eclipse Plugin)
- Network Performance Module: check (fully configurable slicing and background transfer of javascripts, gwt complier compresses js and resources automatically)
- OLAP / Datacube support: -
- Real-time Messaging Module: check (free add-on component http://vaadin.com/directory/#addon/icepush )
Pricing: Free (Apache 2.0 license)
Sent a message to Charles Kendrick (CTO) of isomorphic about the errors. He is a nice guy, so I expect them to correct the situation shortly.
cool wanted to make sure Vaadin gets the credit it deserves.
Hello,
We can now expect them to correct the situation NOT shortly 
as it often happens on most comparison tables, generally not fair. In order to inform actual and potential future Vaadin developers, it could be useful to have the corrected same page on the Vaadin web site
I have another one more “neutral” : http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks in which some information may miss and should be easier to correct if needed :
- MVC framework : nothing fullfilled
- DB migration framework(s) : nothing fullfilled
- Security Framework(s) : nothing fullfilled
- Caching Framework(s) : nothing fullfilled
- MVC Push/Pull : push is coming in release 7, is that right ?
Personaly and as a newscomer, i’m especially interested to know more about the security, MVC and Push/Pull parts of Vaadin.
Coming back on the smartclient comparison table which mentions : Automated Testing => is available for Vaadin as a commercial add-on priced at $1199 per developer. Is that right ? as it represent more than the smargwt pro licence.
Client-side Events : can’t we espect something with the GWT adequation ?
What is wrong or incomplete in their talks regarding :
- Skinning / Branding : : required advanced css and browser quirks knowledge
- Server Data Binding : Partial support
What are the actual unchecked which may eventually be planned on the Vaadin roadmap ?
Finally, one of the thing i’m most interested [with widgets:)]
we find in smartgwt and apparently wicket soon is : “Scalable Clustering Support. All Wicket applications will work on a cluster automatically and without additional work. Once bottlenecks are understood, Wicket enables tuning of page state replication. The next version of Wicket will support client-side models for zero-state scalability.” This is an incredibly huge advantage. Is it a thing we could see in Vaadin perhaps by using gwt capabilities in this area ?
I feel deeply sorry for every one of these UI framework comparisons (ours included), because pretty much all of them fail to compare the thing that matters to the end user the most: the actual usability of the widgets and applications that you create with them.
I opened the Vaadin, ZK, SmartClient and Dojo showcases, and tried to navigate around using the keyboard only. I failed – or more precisely, the frameworks failed. Each one demanded me to use the keyboard in some step. Still, I’m quite sure you can create apps with each one of these frameworks that work with keyboard only, but the demos are lacking in this case.
I guess I’m asking too much (that someone would take a bit more time and compare the end usability of the apps), and the regular Java developer doesn’t care that much for actual usability. What seems to matter the most, are the number of features, and the ease of development. I’m not saying those wouldn’t matter – I’m saying that one crucial thing is missing from that list, and that the priorities are backwards.
There is already two push add-ons to vaadin at
http://vaadin.com/directory
that you can use today.
Push will be in product core at Vaadin 7.
There is no browser level testing tool included in SmartGWT, or am I mistaken?
There might be some progress on this front with Vaadin 7, but all in all the focus of Vaadin is to keep programming model simple. That implies server-side.
Is there any ticket or wiki where Vaadin team has already started discussing the details of the push API or how push might be implemented in V7? It will be greatly helpful for us and possibly others to follow that thread.
Thanks
If we speak in terms of comparison tables for example, they’re nearly by “nature” unfair because authors have to quickly communicate the advantages of their product over the others.
Now if the goal were to bring more “details” or to be fair, then should be added the rows of comparison tables competitors. Based on this, that’s one of the things that would give the end user a better idea of what really matters to him.
It seems you’re decided trying to impress me :lol:
Well it looks like it is, but there is no status on the note, is this document a proposition or something already implemented (as i see version 6.5.0) ? Along the description, it seems not implemented as there are still opened questions.
In case i misunderstood something, let’s verify if we’re talking about the same thing. Except application state, the researched extremely huge benefit is to avoid an heavy infrastructure on the server side when a project is deployed on a cluster. My concern here is avoiding session clustering but still let a user login again transparently on server B if server A on which he were connected finally crash. I’m searching a way to avoid this session clustering whatever managed “handmade” (clustered db storing sessions and sticky sessions) or with the help of products like Terracota and so on.
The problem coming in mind, at least mine, is security as it’s totally misterious to me how that can be achieved. The author of the lift framework told me once i rely on the client, security is compromised but as Isomorphic answered me that i must have misunderstood him and claims it’s not a problem with smartgwt, i asked them how can it be possible without comprising the security. By now, the answer is “we will explain you this in formation”. Obviously, i reach my knowledge limits, i’m waiting to see how wicket will manage this.
Application state as exposed in your document interest me a lot but i don’t know if it also includes the credentials i’m talking about. I have some kind of a hope 
as i’m currently thinking of using Vaadin for a first project but the second one especially needs this kind of stuff, so i were already planning to use smartgwt for it, now if Vaadin is also beginning to play with this kind of stuff it may become a one-stop shop for my pleasure
Yes, these add-ons are a solution but as explained in the thread “Comparison: ZK vs Vaadin”, if we have choice, i prefer to not rely on add-on for everything. Vaadin 7 roadmap is here great news.
I guess you’re right but it’s not always easy to obtain information from Isomorphic on some subjects so at the end that does not give me envy to ask them much things :wacko:
If the developer can choose the balance of the mix server-side/client-side and the related complexities, i would see this as flexibility and it’s up to him to assume the consequences -_-
This is still a proposition. Not in the roadmap yet. I feel that the feature would be important - especially in connection to features like this one:
http://vaadin.com/addon/vaadin-xs
.
All in all - if there is demand for the feature, we’ll add it to Vaadin.
At the moment Vaadin supports clustering just as well as any other servlet/jsp/jsf/… that uses HttpSession: If your application state is serializable, then you can move application state freely among the servers in the cluster. If you application state is not serializable, then you must use sticky sessions.
The above proposal of “stateless” mode would remove server state altogether. Thus there would be no need for server side session any more. Each request could go to any server for processing. No need for sticky session. Downside is of course the extra processing time (as estimated in the ticket) as well as requirement for always implementing serialization in your application state.
Lift guys are correct. In principle - anything in the client can be changed by the end user. This is avoided in the above proposal by strongly encrypting the client-side state and keeping the keys in the servers. Thus from the security point-of-view it is almost as secure as the pure server-side framework, but from the deployment point of view - it is a stateless client-side application. Win-win. Almost. A real client-side approach (like GWT or SmartClient) is still quite a bit lighter. In fact from the server processing and bandwidth point of view the you could order the architectural approaches from the lightest to heaviest in the following way: client-side ria, server-side ria, stateless server-side ria, page oriented “web 1.0”.
Here is a conference presentation about security aspects of client-side ria vs. server-side ria I have given in couple of conferences:
http://vaadin.com/web/joonas/wiki/-/wiki/Main/RIA%20Security
. I’ll update the presentation shortly and will present it again at
GeeCON
.
Application state as exposed in your document interest me a lot but i don’t know if it also includes the credentials i’m talking about. I have some kind of a hope as i’m currently thinking of using Vaadin for a first project but the second one especially needs this kind of stuff, so i were already planning to use smartgwt for it, now if Vaadin is also beginning to play with this kind of stuff it may become a one-stop shop for my pleasure
[/quote]
In that case it is quite pointless to compare price of a commercial testing tool (Vaadin TestBench) to a commercial UI framework without a testing tool.
For both frameworks, you could try to live with free version of Selenium and work around all the limitations by yourself.
I fully agree with you.
At the moment the situation in Vaadin is: If you want to do interactions in client-side, you must create a custom widget with GWT. Creating composites from Vaadin widgets on the client-side is challenging.
With Vaadin 7 this will probably be a bit better as we plan to make client-side widgets to be more easily usable without the server-side. Thus could more easily do composites in client side and package the result as a Vaadin widget.
If anyone has ideas on how to make adding client-side logic even easier, it would be great to hear them.
How would you (or anyone else reading the this!) compare Vaadin in this regard with the companies behind alternate technologies, eg. Isomorphic?
As committing to a technology is not a small decision I’d say this could be a pretty important factor for someone considering which UI technology to use.
I fully agree this you. I hope there’s a future for these two approachs for which i would vote and even be a subscriber for a recurring vote
Even with this, it’s not so far from a benediction :), at my level, i see more advantages than drawbacks and serialization is often required in other clustering scenarios anyway
And by “end user”, it also includes “someone between (end user and server)” but here too, i’m a lost as if there is someone between the end user and server, then for me security is quite compromised whatever client-side or server-side management. I mention this because i have been told by the same people that even if i use encrypted cookies as one example and in a sensible context like banking or sport betting and so on, there will always be a motivated people than will be able to break my client-side security levels.
Thanks for the explanation and informations. Is stateless server-side ria so much heavy than server-side ria ?
I mean in a clustering environment and depending on choices, some clustering solutions for server-side ria are quite not light and imply some common “heavy” things with stateless server-side ria so all in all, i’m not so sure stateless server-side ria is always the bad kid here. Perhaps more clearly, i mean here that i’m aware stateless server-side brings extra cost in terms of processing and bandwith but also brings some added valued vs server-side ria. If we want some of these added valued in server-side ria, then the things to be implemented will also brings extra cost in terms of processing and bandwith.
Because it’s involved as a part of the comparison and afaik by now, Vaadin position is a way better on this point
From my point of view, Smartgwt has quite a list of advantages (Vaadin has also its own, as ZK and so on) and SmartGwt guys know how to use their strong arguments but it also have very important drawbacks, some are related to communication whatever on the product itself as well as with people, ie smartgwt staff work hard, but they also speak hard with people :), this along with a relative absence of documentation, tutorials, small talks and so on, it seems that this is the kind of contexts where Vaadin “useers” can be much more confortable with in a pleasant way
Of course it is, that’s obvious but some others are also important like server-side and client-side differences approach. If you need client-side and don’t have much framework choices, then maybe you have to assume the communication and attitude drawbacks :). Now, Vaadin seems to bring soon some more friendly client-side capabilities, good news to see one more choice in the client-side possibilities:)
I added informations there in case you might be interested
I’m too new in the java stack so i’m a little bee with no impact taking the risk to mention inadapted talk, sorry for that, but would you see useful in that “integration” the use of Google “tools” like uibinder, gwt designer… does that make any sense ?