Mittwoch, 8. September 2010

Ext GWT or SmartGWT or Vaadin

My journey continues. Deciding on a RIA framework is harder than i thought because of the existance of many quite good approaches. First i checked ExtJS but as mentioned in my previous post, we wont want to write 80% of our app in javascript. So i came to Ext GWT which was the more viable option. Then someone pointed me to vaadin, which works by handling events on the server by widget network communication. But after seeing some limitations on the widget part of vaadin (grids are ok but not perfect for example), i also checked SmartGWT, which is definitely the widget monster. You simply get everything you can imagine.

So there i am. Just for the record, i dont want to go with server-side, template based frameworks like Wicket, Struts2, Spring WebMVC or the likes anymore. Because most of them force you to think about getting all the RIA widgets from jQuery or something. This turned out be a nightmare for our current products version. I want a all-in solution with the best widget support possible and even more important, all the widgets should be themeable the same way and should have the programming style. This is something you dont get with jQuery plugins.

Something i dont bother is the pricing questions. For a company earning money with software development, it doesnt matter if a product is free or has a developer license from 0 - 2000$, but something i cant agree on is CPU licensing because we sell a product more than once.

From a technical standpoint Ext GWT and SmartGWT are quite equal apart from the fact that Smart has more to offer on the server side. Vaadin with its complete different apprach (not from the programming style but from runtime behavior) needs to be compared in a different fashion. Things like GUI responsiveness and overall performance must be carefully checked. But on the pro side you have a very small js client with vaadin which results in fast startup in the browser. On the other hand, our product is a business product and we are planing to rewrite the AdminConsole. This is something that will be used in intranets in 95% of the time. It doesnt make much of a differnece if you load 100k or 1Mb from inside the LAN.

Another important issue is the market relevance, industry adoption and backing company structure. At the end you dont win anything if you chose the best designed framework when the company behind it will close its doors anytime soon. From this perspective i dont think any of those 3 players are in danger. Sencha just got many millions from an investor, Vaadins company is also quite successfull and this over years and Isomorphic seems to have enough big customers to get some money out of the product. All three have regular release and enough inovation.

At this point i cant make the decission. I will read any of the documentations of the three players. I even ordered books from amazon because i really need to be sure that i make the best choice possible. Once i decided on one, we would need at least half a year or something to reengineer our application.

One thing to note: Isnt it lovely that java has so many framework options? On the one side its a lot of work to pick the right one for your business but more important is that you have so many good alternatives.

Kommentare:

Anonym hat gesagt…

still not looked into http://www.eclipse.org/rap/

Marc Logemann hat gesagt…

still no interest in RAP. First, i dont use Eclipse (not a killer but ok), second, i dont like SWT and third, i dont like the complete concept.

Anonym hat gesagt…

SmartClient wraps js extensively, which if that's your comfort zone might not be a problem.

Charles Kendrick hat gesagt…

Be sure to read the new SmartGWT QuickStart Guide, very recently released:

http://blog.isomorphic.com/?p=227

Look in particular at the section on the SmartGWT Server Framework - many extremely powerful features.

Then take a look at my summary here of features in SGWT's client side not found in ExtGWT (just for grids).

http://www.coderanch.com/t/486474/GWT/SmartGWT-vs-Vaadin

It's easy to think, from a superficial look at a few demos, that there is similar functionality between the two frameworks. If you dig deeper, the reality is that SmartGWT is a vastly, vastly more capable product.

Anonym hat gesagt…

We chose Vaadin because we liked the server-centric approach to security, control and the lack of DTOs (data transfer objects) needed to define the data used by the client JavaScript and the server Java.

Marc Logemann hat gesagt…

my first prototype demo is with Ext GWT. Its up and running quite nice but i have not reached the data components where i need also a server part.

SmartGWT certainly offers some more server side magic but since i am not that dumb, i am pretty sure that i can do the server (json service part) myself.

To summarize, it seems SmartGWT has a little bit more power (the pro version) but it should have because its about 5 times more expensive.

Will need a lot more days to really speak about those two frameworks from personal experience.

Charles Kendrick hat gesagt…

SmartGWT also solves the DTO problem:

http://www.jroller.com/sjivan/entry/solving_the_dto_dilemma

.. but solves it more thoroughly because it also eliminates duplication between your UI components and your business objects (eg field names, types, titles, other metadata).

SmartGWT also features declarative security, like tying roles to particular operations, and creating variants of operations for different users.

All covered in the QuickStart Guide, which you really, really ought to read. The server-side is not a "json service part", it is a huge range of functionality.

I would go so far as to say that you should just drop everything and read the QuickStart now - it will make you understand the scope of what needs to be done on the server for a typical RIA application, and what the ideal solution looks like. At that point you will no longer regard the technologies as comparable.

Finally, about Vaadin - as a server-centric architecture, it doesn't allow client-side events, so it can't handle common RIA use cases like rapid data entry with interdependent fields or customized drag and drop. And it can never meaningfully handle offline mode (too little client-side intelligence).

So, it can handle certain simple applications, but it wouldn't work for any of our customers. Be very careful about using a technology that only handle simple things in an enterprise context - projects tend to grow and new, surprising requirements.

rperfect hat gesagt…

Be sure to test Vaadin with production mode = true, otherwise the GUI response is a little sluggish.

Anonym hat gesagt…

You may want to check ZK framework as well. It also fell into RIA category.

Richard Capraro hat gesagt…

What i really like with Vaadin is the compilation time (everything is compiled in java, no slow java->javascript compilation), and the fact that it is very easy to extend / customize the widgets.

Anonym hat gesagt…

We started with GXT but found particularly layouting as well as DTO mapping to be annoying. We're now using SmartGWT instead for those reasons.

Peter hat gesagt…

Personally, I prefer Vaadin because of its component base approach and the ability to support domain driven development (upto a point).
At the time I tried SmartGWT I was disappointed by the performance for small applications. An example app and a little follow-up in the comments on my site: http://www.streamhead.com/tutorial-quick-connect-pc-television/
I don't think you'll have to worry about performance for your application, so I'm afraid there is no "better" framework. It's mostly personal preference.

Anonym hat gesagt…

Have you checked out WaveMaker.com? The next version 6.2 will be themeable.

Joonas hat gesagt…

[warning - I am one of the people behind Vaadin - in the same way as Charles is one of the people behind SmartGWT - so please take our comments with a salt of grain :) ]

Couple of points to evaluate:

- Look at how the frameworks are extended and are people publishing extensions. For Vaadin, you can find extensions at http://vaadin.com/directory

- Look for independent evaluations and comparisons. Two of the ones I really like (posivite for Vaadin, 100% independent) include http://wp.me/pApkU-jN and http://goo.gl/6Ssc

- Look for forums and see what people who use or are learning the frameworks say about them. Are they happy?

- Comparing features is always the hardest part. Different frameworks choose to include different features in "core" and in "extensions". It is best to identify the key features you need and look at the demos. If they are not there, ask on forums.

Joonas hat gesagt…

Wanted to correct some incorrect statements about Vaadin:

"Vaadin - as a server-centric architecture, it doesn't allow client-side events, so it can't handle common RIA use cases like rapid data entry with interdependent fields or customized drag and drop."

Server-side RIA handles rapid data entry without a problem. The client-server communication manager automatically queues and clusters server-side calls when needed and sends them asynchronically without blocking input. Because the validation is done on the server without need for double validation (or possibility of leaving security holes by forgetting double validation).

Drag and drop is highly customizable - one can check drop target criteria both in server and in client. Check the

"So, it can handle certain simple applications, but it wouldn't work for any of our customers. Be very careful about using a technology that only handle simple things in an enterprise context - projects tend to grow and new, surprising requirements."

I have seen really large (several hundreds of thousands of lines) enterprise applications done with Vaadin. If one bumps into a requirement that needs to be coded on client-side - it is always an option with Vaadin by simply implementing a custom widget - also in Java (compiled with GWT).

Charles Kendrick hat gesagt…

Sorry Joonas, you're incorrect. Note I said "rapid data entry with interdependent fields" - here, any server-centric architecture blocks user input in order to visit the server to figure out where the user can tab to, what options are valid, etc, which is unacceptable.

Likewise, for drag and drop, you can of course visit the server at the end of a drag and drop interaction, but visiting the server during the drag and drop is not acceptable.

Hence, dynamically determined drop eligibility, or even simple custom drag interactions like implementing hoop selection are not achievable with server-centric event handling.

And then again there's offline support - not possible.

Now, Isomorphic does a lot of work in life sciences, defense, financials, insurance, heavy industry and so forth on advanced RIA applications. These use cases come up all the time, so as I said, Vaadin and other server-centric architectures would not meet our customer's requirements.

If you're not hitting these use cases, it's probably due to self-selection on the part of your clients, but may also be due to how we approach our customers - we say "we can do anything, so spec it how you'd like it".

And no, the ability to write a custom client-side component doesn't solve the problem. Then, you're completely outside the normal Vaadin state management system, essentially implementing a parallel application. If someone already has data in eg a Vaadin grid, and they just want to implement some incremental enhancement involving client-side events, it's not a good answer to say that they can replace the grid with their own grid component and begin handling all data loading, all events, etc, themselves.

Finally, the other very serious problem with server-centric architectures is clustering. Vaadin requires a chunk of server-side session state which is totally unnecessary in SmartGWT and other client-centric architectures, and in a clustered deployment, this state has to be replicated amongst all servers in the cluster.

Between far more server trips and poor clustering performance, large deployments of server-centric architectures will never come within 10x the performance of client-centric systems like SmartGWT. More often, it's 50x or 100x or more.

So in conclusion, be very careful adopting any server-centric architecture. If (more likely when) tougher requirements come up, you're just going to end up abandoning the technology and moving on to a client-centric system.

Charles Kendrick hat gesagt…
Dieser Kommentar wurde vom Autor entfernt.
Charles Kendrick hat gesagt…
Dieser Kommentar wurde vom Autor entfernt.
Javier Tia hat gesagt…

What about to use ZK Direct RIA (http://www.zkoss.org/)?

You can check your demos (http://www.zkoss.org/demo/) with Real World Apps.

Charles Kendrick hat gesagt…

Wherever I've said server-centric, it means not just Vaadin but also ZK, and JSF+Ajax approaches like iceFaces, RichFaces, ADF, etc.

Joonas hat gesagt…

"Likewise, for drag and drop, you can of course visit the server at the end of a drag and drop interaction, but visiting the server during the drag and drop is not acceptable."

Why is that? Here is a live demo and source code example of just that: http://magi.virtuallypreinstalled.com/book-examples/book/#advanced.dragndrop.accept.serverside

Joonas hat gesagt…

Charles, I agree fully with the offline limitation of server-side systems.

Regarding the other claims - you have listed the cases where client-side systems generally have advantage, but it is hard to agree that these thighs would not be doable in a server-side system. When you factor in the faster development and better tooling on server-side, in most cases it is better to select a server-side system.

The claim of 10x performance difference seems quite strange. In systems I have seen, the bottlenecks are not on the UI layer at all - but on storage layer. Thus the client-side and server-side systems share those bottlenecks.

Charles Kendrick hat gesagt…

Yes, go to that demo and open Firebug's "Net" panel and drag back and forth over the nodes. The server is being peppered with requests - approximately 2 per second - and the drop indicator is very sluggish.

This is already unacceptable, but it's not even close to the worst case. Again, consider hoop selection: you've got a visible object that needs to update every mousemove. You'd again have 2+ requests per second and the visual indicator would lag perhaps 0.75 seconds behind the mouse cursor in the best case scenario.

In both of these use cases SmartGWT sends exactly 0 requests.

Now, the server-centric system may fail due to overloading the storage system, but the root cause is too many requests. Each request goes through authentication (typically a database hit), de-serialization and re-serialization of Vaadin's session state, and application logic which is likely to hit the database multiple times.

In SmartGWT, all of that work is unnecessary, and that's where 10x, 50x, 100x performance advantages come from. The more custom logic, the wider the gap in favor of client-centric architectures.

Now, if it were true that Vaadin offered faster development, there would be more of a trade-off here, but the reality is that SmartGWT provides very, very sophisticated client-server databinding systems that make it simpler to connect UI components to data than it is in Vaadin (or so I would argue).

The power and simplicity offered by SmartGWT leaves no reason to accept the inherent limitations and risks of a server-centric architecture. If you disagree, the QuickStart Guide gives you the concrete details of how client-server databinding is handled - see for yourself:

http://blog.isomorphic.com/?p=227

Anonym hat gesagt…

Charles trollin' it up... keep up the good work. You've made a name for yourself.

Joonas hat gesagt…

"Yes, go to that demo and open Firebug's "Net" panel and drag back and forth over the nodes. The server is being peppered with requests - approximately 2 per second - and the drop indicator is very sluggish."

This is only while you are dragging an item. It works and is usable. I would not recommend server-side drop validation for everything, just wanted to point out that the original claim of this being impossible was not true.

In Vaadin you can also use client-side drop validation. In that case there is no server-side calls at all. Just as in SmartGWT. Take a look of the manual: http://vaadin.com/book/-/page/advanced.dragndrop.html

"In both of these use cases SmartGWT sends exactly 0 requests."

How on earth? You asked about server-side drop validation. If the information is not on the client-side, one has to fetch it from the server. Even in SmartGWT.

"Now, the server-centric system may fail due to overloading the storage system, but the root cause is too many requests. Each request goes through authentication (typically a database hit), de-serialization and re-serialization of Vaadin's session state, and application logic which is likely to hit the database multiple times."

This is just FUD. In server-side systems (such as Vaadin) authentication is only done once in the beginning of the application. Not for each request.

If you would design client-side system in a stateless fashion and would hit db for each xhr, you would end up with a slow system.

In real world systems backend is needed - the data you want to view and manipulate resides there. Client-side systems (such as SmartGWT) must make calls to backend to fetch and modify that data. If you are not careful in communication layer design, you might end up with the situation where one user interaction does more than one xhr. This is worse than in server-side ria where the framework guarantees that you do at max one xhr for any user interaction. (and for many internactions no xhr is needed at all).

"Now, if it were true that Vaadin offered faster development, there would be more of a trade-off here, but the reality is that SmartGWT provides very, very sophisticated client-server databinding systems that make it simpler to connect UI components to data than it is in Vaadin (or so I would argue)."

Any fact based arguments for this?

Joonas hat gesagt…

"Yes, go to that demo and open Firebug's "Net" panel and drag back and forth over the nodes. The server is being peppered with requests - approximately 2 per second - and the drop indicator is very sluggish."

This is only while you are dragging an item. It works and is usable. I would not recommend server-side drop validation for everything, just wanted to point out that the original claim of this being impossible was not true.

In Vaadin you can also use client-side drop validation. In that case there is no server-side calls at all. Just as in SmartGWT. Take a look of the manual: http://vaadin.com/book/-/page/advanced.dragndrop.html

"In both of these use cases SmartGWT sends exactly 0 requests."

How on earth? You asked about server-side drop validation. If the information is not on the client-side, one has to fetch it from the server. Even in SmartGWT.

"Now, the server-centric system may fail due to overloading the storage system, but the root cause is too many requests. Each request goes through authentication (typically a database hit), de-serialization and re-serialization of Vaadin's session state, and application logic which is likely to hit the database multiple times."

This is just FUD. In server-side systems (such as Vaadin) authentication is only done once in the beginning of the application. Not for each request.

If you would design client-side system in a stateless fashion and would hit db for each xhr, you would end up with a slow system.

In real world systems backend is needed - the data you want to view and manipulate resides there. Client-side systems (such as SmartGWT) must make calls to backend to fetch and modify that data. If you are not careful in communication layer design, you might end up with the situation where one user interaction does more than one xhr. This is worse than in server-side ria where the framework guarantees that you do at max one xhr for any user interaction. (and for many internactions no xhr is needed at all).

"Now, if it were true that Vaadin offered faster development, there would be more of a trade-off here, but the reality is that SmartGWT provides very, very sophisticated client-server databinding systems that make it simpler to connect UI components to data than it is in Vaadin (or so I would argue)."

Any fact based arguments for this?

Joonas hat gesagt…

"Yes, go to that demo and open Firebug's "Net" panel and drag back and forth over the nodes. The server is being peppered with requests - approximately 2 per second - and the drop indicator is very sluggish."

This is only while you are dragging an item. In any case, it works well enough. I would not recommend server-side drop validation for everything, just wanted to point out that the original claim of this being impossible was not true.

In Vaadin you can also use client-side drop validation. In that case there is no server-side calls at all. Just as in SmartGWT.

"In both of these use cases SmartGWT sends exactly 0 requests."

You asked about server-side drop validation. If the information is not on the client-side, one has to fetch it from the server. Even in SmartGWT.

"Now, the server-centric system may fail due to overloading the storage system, but the root cause is too many requests. Each request goes through authentication (typically a database hit), de-serialization and re-serialization of Vaadin's session state, and application logic which is likely to hit the database multiple times."

Not true. In server-side systems (such as Vaadin) authentication is only done once in the beginning of the application. Not for each request.

If you would design client-side system in a stateless fashion and would hit db for each xhr, you would end up with a slow system.

In real world systems backend is needed - the data you want to view and manipulate resides there. Client-side systems (such as SmartGWT) must make calls to backend to fetch and modify that data. If you are not careful in communication layer design, you might end up with the situation where one user interaction does more than one xhr. This is worse than in server-side ria where the framework guarantees that you do at max one xhr for any user interaction. (and for many internactions no xhr is needed at all).

"reality is that SmartGWT provides very, very sophisticated client-server databinding systems that make it simpler to connect UI components to data than it is in Vaadin (or so I would argue)."

So what are the arguments?

Anonym hat gesagt…

We noted we could integrate CKEditor into Vaadin by building a custom widget in GWT. It is mostly responsive Javascript code, with not too many server interactions needed other than focus/blur and load/save of the HTML for it to use.

We found the various versions of SmartGWT to be confusing and hard to demo, not being sure what features were in which versions since features lists didn't align clearly to the APIs/Javadocs. We couldn't get an eval of just the Pro edition, for example.

And SmartGWT LGPL, while open source, does have answers to DTOs and many other server-centric solutions/capabilities that we like in Vaadin.

So, it's not that we don't like SmartGWT, but we didn't want to pay for licenses for the server-side capabilities with the LGPL client-side, and it confused our licensing since we wanted our code to be AGPL, and this would not be possible with the proprietary server-side SmartGWT code.

Charles Kendrick hat gesagt…

Visiting the server constantly during mouse movement is unacceptable from a performance perspective. This happens in Vaadin and other server-centric architectures when you add any kind of custom Java logic during drag and drop. So it happens with drag and drop eligibility or, a much worse case, drag and drop when there is one visual update per mousemove, like hoop selection, custom drop indicators, and other common use cases.

You also get unacceptable performance if you try to add per-keystroke custom Java logic while the user is typing, such as text masking, rapid data entry with interdependent fields, customized live client-side filtering, and other common use cases.

In SmartGWT, adding custom Java logic does not cause a trip to the server, so all of these use cases can be met with no additional server load and instantaneous response.

Note that it is not an excuse to say that the application only needs to serve a few users, because almost all applications are deployed to shared infrastructure now, so when you use resources inefficiently you degrade performance for multiple apps.

The central point is that in common use cases, you will find that a server-centric architecture has unacceptable performance, and you will also find that it has much poorer performance overall because of a greatly increased number of server trips and poor clustering performance due to a great deal of server-side session state being maintained.

Now, to clarify some places where Joonas' appeared confused by my previous comments:

"You asked about server-side drop validation."

No, I didn't. I talked about custom (Java) logic during drag and drop. This implies a server trip in Vaadin, but not in SmartGWT.

Charles Kendrick hat gesagt…

"In server-side systems (such as Vaadin) authentication is only done once in the beginning of the application. Not for each request.

In any web-based system, authentication is checked on every request. This is a relatively expensive operation that typically involves a database or session load. Further, authorization checks (like whether the user can perform a given action) may also need to be performed. This is one reason why minimizing requests is key.

These authentication and authorization checks, combined with Vaadin's need to deserialize and re-serialize a bunch of session state, impose a basic overhead on all requests, making all these extra requests very expensive.

"If you are not careful in communication layer design, you might end up with the
situation where one user interaction does more than one xhr. This is worse than in server-side ria..."


Except that as previously discussed, we are very careful with the communication layer design. We perform far, far fewer server requests than Vaadin in corresponding use cases, as a run through the SmartGWT vs Vaadin show case demonstrates conclusively. And we are particularly good at avoiding the most expensive types of operations (database queries on large datasets) because of Adaptive Filtering and Adaptive Sorting.

"reality is that SmartGWT provides very, very sophisticated client-server databinding systems
that make it simpler to connect UI components to data than it is in Vaadin (or so I would
argue)."

So what are the arguments?


I've already referred you and others to the SmartGWT QuickStart Guide repeatedly. But to briefly summarize what you will find there:

1. a one-line declaration generates starter versions of all data-aware components (form, grid, tree, cube, calendar, etc) ready to view and edit data from any Java Bean or SQL table. Appropriate controls are automatically generated per property or column, and you can then do fine-grained overrides without losing the automatic generation.

2. the same one-line declaration also provides all 4 CRUD operations if you happen to be using SQL, Hibernate or JPA. Otherwise, the persistence logic you write is similar to Vaadin.

3. many, many common use cases are addressed by trivial XML declarations, such as validation, declarative security, customized SQL queries if using SQL, sending templated mails, transactions, etc

Now, for Vaadin to overcome the severe disadvantages of server-centric architecture, and to therefore be considered for certain applications where it can be guaranteed that the unacceptably poor performance use cases won't come up (even in future versions), it would have to be much, much simpler to bind components to data in Vaadin than in other systems.

But this is clearly not the case.

Charles Kendrick hat gesagt…
Dieser Kommentar wurde vom Autor entfernt.
Charles Kendrick hat gesagt…
Dieser Kommentar wurde vom Autor entfernt.
Charles Kendrick hat gesagt…

Anonymous: if you are in the (rare) situation of needing to ship a GPL or AGPL product, then yes, you can use our LGPL product only.

The license breakdown is straightforward and explained in a simple chart:

http://www.smartclient.com/product/

The properties and methods that only function in Power edition are prominently labeled:

http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/serverds/OperationBinding.html#customSQL

It's true there is no Pro-specific evaluation version yet, but there will be in the future.

Marc Logemann hat gesagt…

Sorry for inconvenience. I think this kind of discussion here is not usual from google perspective and so it marks some posts as spam. I havent done anything special about that...

Joonas hat gesagt…

"In any web-based system, authentication is checked on every request. This is a relatively expensive operation that typically involves a database or session load. Further, authorization checks (like whether the user can perform a given action) may also need to be performed. This is one reason why minimizing requests is key. These authentication and authorization checks, combined with Vaadin's need to deserialize and re-serialize a bunch of session state, impose a basic overhead on all requests, making all these extra requests very expensive."

In most deployment scenarios (anything but Google AppEngine) serialization is not needed - application stays in memory while the session is open. Session identification (with cookie) also is really lightweight operation.

"we are very careful with the communication layer design."

Sorry - I did not mean you as a company - I meant a typical developer using a client side framework. For him it is too easy to trigger multiple rpc operations for a user action.

Charles Kendrick hat gesagt…

Come on Joonas, you know this is not the case, you discussed clustering with your users a number of times.

For a single server, session state can be in memory, but often isn't - it's not the default configuration and it may not be acceptable to change the default if other apps are present.

For multiple servers (GAE or not), typically storage is to a shared database.

There are in-memory solutions like Terracota, but transactionally syncing around 100k of session state between 4 servers twice a second because just one user is doing drag and drop is not exactly a great performance scenario. Especially when the alternative in a client-centric architecture is that these requests are avoided altogether and the user experience is much better (instant response).

And no, it's not easy to inadvertently send server requests in SmartGWT. You've got the data in the client already and it's passed to you in your event handler. The natural thing is just to access it there and that's what everyone does.

Joonas hat gesagt…

"Note that it is not an excuse to say that the application only needs to serve a few users, because almost all applications are deployed to shared infrastructure now, so when you use resources inefficiently you degrade performance for multiple apps."

This is something that I am not saying. For Vaadin apps the number of concurrent users per server depends on three limiting factors: 1) business logic, 2) application state size, 3) server heap size. Most often business logic is the bottleneck. When it is not, a typical server with 16GB memory can serve around 50.000 concurrent users with 200k session per user. For most apps this is plenty. For ones this is not, just add servers :)

I have not tested data bindings generation in smartgwt, so I cannot comment on that. According to your chart, any of the data binding features are not part of the open source version of smartgwt. Is there some data layer for the open source version?

One of the aspects not discussed is JavaScript code size. With client-side systems code size submitted to client grows in relation to the application size. With server side systems it stays constant. Quite a huge difference can be seen in smartgwt and vaadin sampler js code size. This directly affects start up times.

Joonas hat gesagt…

"For a single server, session state can be in memory, but often isn't - it's not the default configuration and it may not be acceptable to change the default if other apps are present."

Care to refer where force serialization for each request is a default (other than GAE). In most clustering scenarios sticky sessions are used and serialization is only used ID the rare case of migrating a session from a server to another (for shutting down a server for example). For example in tomcat serialization is by default only done when shutting down the server - otherwise the session stays in memory and no time consuming serialization is done.

Charles Kendrick hat gesagt…

"a typical server with 16GB memory can serve around 50.000 concurrent users with 200k session per user."

Joonas, you're considering memory only, so these numbers are totally unrelated to real world scalability.

Once again, between far fewer server requests and far less work to be done for each request, client-centric architectures are going to have a 10x to 100x or higher performance advantage. The more servers involved, the more custom logic that requires more server visits, the larger the advantage gets.

"According to your chart, any of the data binding features are not part of the open source version of smartgwt. Is there some data layer for the open source version?"

Actually the chart very clearly say the exact opposite - note "DataSources and Data binding" listed clearly as part of all editions, LGPL included.

"One of the aspects not discussed is JavaScript code size. With client-side systems code size submitted to client grows in relation to the application size. With server side systems it stays constant."

Yes - that JavaScript is what allows all those client-side operations to take place. For business applications which are used more than once or used for any length of time, this is a non-issue: it's cached, so it loads once ever, and provides a huge ongoing advantage in responsiveness and scalability.

However, we would not recommend Smart GWT for a consumer-facing retail site that eg sells shoes and has some light interactivity requirements like flyout menus. Such sites are typically built based on a very intricate HTML and CSS designed, and neither SmartGWT nor Vaadin nor GWT in general is appropriate - you want to use something more like JQuery, which is good at augmenting hand-coded HTML with interactivity.

Charles Kendrick hat gesagt…

As far as "sticky sessions", they can be complex to configure since every tier, from dynamic DNS and location-based routing through the load balancer and web tier needs to cooperate to make it work. So we usually find that it's not enabled for a given cluster.

Nor do sticky sessions remove all replication work - sticky sessions in WebLogic still replicate to a secondary server because it's not acceptable in many applications to drop user sessions just because you are de-pooling a server.

That's part of why they aren't used for GAE, and bigger picture, you can take this as an indication of what future internal and external "cloud" / shared hosting solutions will be embracing.

With the current megatrend toward shared hosting and virtualization, now is a very bad time to be making assumptions about how the server will be configured, whether it's Terracota, sticky sessions, or something else.

Client-centric solutions like SmartGWT do not rely upon any particular clustering behavior for their performance, and again, are far more performant than server-centric solutions even when the ideal clustering scenario is considered.

Joonas hat gesagt…

"Joonas, you're considering memory only, so these numbers are totally unrelated to real world scalability."

Of course you must consider all the potential bottlenecks. Scalability is not a simple topic. Still, saying that "server-side ria does not scale to more that few hundred concurrent users" is just not true.

For one server-side RIA scalability test, see http://vaadin.com/forum/-/message_boards/message/194062
In that test we were able to sustain 1900 sales transactions per minute without a hitch in one Amazon EC2 server. Unfortunately JMeter server was the bottleneck in this case. Each sales transaction requires user to step trough several views in the application (selecting city, movie, theatre, previewing movie trailer, reviewing address on map, selecting seats, entering and validating credit card info, etc.). In this case 1900 translates to around 10000 concurrent user / server. I am sure that we would be able to get to higher numbers with a client-side framework in this kind of application, but if it really matters is another question.

Joonas hat gesagt…

"Joonas, you're considering memory only, so these numbers are totally unrelated to real world scalability."

Of course you must consider all the potential bottlenecks. Scalability is not a simple topic. Still, saying that "server-side ria does not scale to more that few hundred concurrent users" is just not true.

For one server-side RIA scalability test, see (our blog) we were able to sustain 1900 sales transactions per minute without a hitch in one Amazon EC2 server. Unfortunately JMeter server was the bottleneck in this case. Each sales transaction requires user to step trough several views in the application (selecting city, movie, theatre, previewing movie trailer, reviewing address on map, selecting seats, entering and validating credit card info, etc.). In this case 1900 translates to around 10000 concurrent user / server. I am sure that we would be able to get to higher numbers with a client-side framework in this kind of application, but if it really matters is another question.

Joonas hat gesagt…

"Actually the chart very clearly say the exact opposite - note "DataSources and Data binding" listed clearly as part of all editions, LGPL included."

What? The chart clearly states that Server Data Binding are not part of the open source product. To me the description (from your site: "Provides a simple Java API for handling requests for data from SmartClient visual components. Greatly accelerates integration with Java-based servers as compared to building REST or WSDL services for SmartClient components to consume." ) sounds like this is the feature you have been speaking about for making server-side communications easy and generating all the required layers with just one annotation.

Joonas hat gesagt…

"With the current megatrend toward shared hosting and virtualization, now is a very bad time to be making assumptions about how the server will be configured, whether it's Terracota, sticky sessions, or something else."

I hope that you are not confusing "megatrends" with practical reality. In practice it is ok to rely on sessions in memory. Almost all systems (with notable exception of GAE) support sticky sessions and they are the default in most configurations. An of course - if you are not running on a cluster the question does not even arise. Per request serialization is not needed for migrating applications live from one server to another - servers are free to serialize sessions whenever they want to.

Joonas hat gesagt…

"However, we would not recommend Smart GWT for a consumer-facing retail site that eg sells shoes and has some light interactivity requirements like flyout menus."

Quick test for anyone to try. Start up the feature browser demos for both Vaadin and SmartClient (are there SmartGWT demos online somewhere?).

Did all the test with Firefox in OSX. Cold start with caches cleared: Vaadin 3.5sec, SmartClient: 13.8sec. Huge difference in the first impression. Second load with resources in cache already. Vaadin 2.7 sec. SmartClient 3.2 sec.

But I agree with you in that for a simple website one should prefer plain HTML (with some lightweight framework for generating it) and jQuery over GWT, Vaadin or SmartGWT.

Charles Kendrick hat gesagt…

"test we were able to sustain 1900 sales transactions per minute ..."

As I've explained at length, the problem with server-centric frameworks comes up when you add a number of custom event handlers, and especially with drag and drop, fast data entry with interdependent fields, etc. And again, with clustering.

If you dodge all of the bad cases and test a hand-picked scenario on a single non-clustered server, you can demonstrate whatever you like.

Add some of the common use cases I've been discussing and the scalability will drop precipitously.

"Start up the feature browser demos for both Vaadin and SmartClient"

Did you really just compare our much, much larger, more richly skinned, far more media intensive showcase to yours? :)

If you want an apples-to-apples comparison, the downloadable SDK contains just the "Showcase Application" standalone. Run it in the "Simplicity" skin which is more comparable to Vaadin look and feel.

But all you'll show is that SmartGWT/SmartClient is slightly slower on cold start, and much faster on reload.

Of course its mostly irrelevant for business applications. Cold starts happen once ever per user, and reloads are as infrequent as once a day or even once a week.

What matters is interactive performance, and that's where SmartGWT has a huge lead through reduction in server requests.

Charles Kendrick hat gesagt…

"In practice it is ok to rely on sessions in memory."

First of all, even if this were true, it doesn't remove all replication overhead. Even in sticky session mode, high availability servers like Weblogic will transactionally replicate sessions to a slave.

Second, in actual practice, it's our experience with real-world deployments that sticky sessions are usually off.

Bear in mind, in addition to creating the SmartClient and SmartGWT technologies, Isomorphic does development up to and including "turnkey" applications for many Fortune 500 clients. And we support many more beyond that. So we have seen a lot of different deployment scenarios.

The reasons you find sticky sessions off in practice are that:

1. sessions have demonstrable business value (think eg trading desk, what-if analytics) so they don't want to lose them

2. sticky sessions are tricky to maintain when using load balancing and geographically distributed clustering

Basically, when organizations go to implement load balancing and find sticky sessions are a problem, they don't look into what it would take to maintain them, they just turn it off.

Or, the first time someone important loses data, they turn it off.

So again, there is this terrible case of a drag and drop interaction sending 2 requests a section, causing transactional replication of 200k of session state across multiple servers. It is a real case, and not uncommon both from a UI standpoint and from a server configuration standpoint.

This is why it's my perspective that a server-centric architecture can handle certain simple applications, but does not have acceptable performance for high-interactivity business applications.

Charles Kendrick hat gesagt…

"Server Data Binding are not part of the open source product."

SmartGWT and Vaadin are split differently.

SmartGWT has a complete databinding stack client-side, with REST and WSDL connectors that work with any server (including non-Java).

Client-side, multiple components can generate an interface based on a single, shared data definition (called a "DataSource"). Vaadin does not have this, and it's free in SmartGWT.

If you want to connect this UI generation behavior all the way to your Java Beans or SQL tables without writing any code to do so, this does require our lowest end license (Pro, at $745). Vaadin doesn't have this feature at all, anyway, so far as I'm aware.

Different things are free in different products of course. For SmartGWT, deep Selenium integration is free, for Vaadin, there's a $1200 TestBench license to buy.

As Marc very astutely pointed out, none of these costs are a problem at all for enterprise development.

Joonas hat gesagt…

"If you want to connect this UI generation behavior all the way to your Java Beans or SQL tables without writing any code to do so, this does require our lowest end license (Pro, at $745). Vaadin doesn't have this feature at all, anyway, so far as I'm aware."

Server-client communication and data binding to multiple backend systems are part of the free open source Vaadin. Just look at the vaadin directory for data components. 

"none of these costs are a problem at all for enterprise development."

Open source is about more freedoms than just zero licensing cost. With smartgwt enterprises loose the benefits of open source if they are using server data bindings (and this is practically everyone).

"First of all, even if this were true, it doesn't remove all replication overhead. Even in sticky session mode, high availability servers like Weblogic will transactionally replicate sessions to a slave."

Choosing to replicate sessions for all requests is just a bad idea. Saying that it would be needed to being able to maintain application state if a server crashes is besides the point. In client side ria you loose the application state each time you reload the page - this is quite a bit more frequent than crashing the server.

"Second, in actual practice, it's our experience with real-world deployments that sticky sessions are usually off."

I have quite an opposite experience. Maybe everyone considering which architecture to select should consider if there is a good reason for clustering and disabling sticky sessions for their applications.  

"Or, the first time someone important loses data, they turn it off."

This is like saying that first time someone clicks reload on a client-side application and looses data they would move to server-side ria :)

Joonas hat gesagt…

"So again, there is this terrible case of a drag and drop interaction sending 2 requests a section, causing transactional replication of 200k of session state across multiple servers. It is a real case, and not uncommon both from a UI standpoint and from a server configuration standpoint."

As above - no-one should start replicating sessions multiple times a second. If you do not want to enable server-side drop target criterias, use client-side criterias. We can agree on these. Fortunately server-side ria just doesn't require these. There just isn't a use case for the combination you describe above. 

"Did you really just compare our much, much larger, more richly skinned, far more media intensive showcase to yours? :)"

My subjective opinion is quite the opposite, maybe we should stick to facts. Themes are of the same complexity. Number of examples in demos is comparable (have not counted, but smartgwt probably has a bit more). In case of server-side ria number does not even matter - client side doesn't grow when the application grows. In the client side your JavaScript side will be relative to the size of the application.

Also one should note that with (smart)GWT the compilation time will be relative to the size of the application. In server side ria such compilation step is not needed. 

"But all you'll show is that SmartGWT/SmartClient is slightly slower on cold start, and much faster on reload."

Quite an interesting interpretation of the numbers I gave in the previous message ;) (4x cold start time and practically same reload times (vaadin being half a second faster)

Could you post a URL to an online demo that demoes bearable cold startup speed and decent ui complexity at the same time for smartgwt? 

Charles Kendrick hat gesagt…

Joonas, I have to say, you've been pretty straightforward in the prior discussion, but your responses just took a big turn toward the misleading.

"If you want to connect this UI generation behavior all the way to your Java Beans or SQL tables ... Vaadin doesn't have this feature at all, anyway, so far as I'm aware."

Server-client communication and data binding to multiple backend systems are part of the free open source Vaadin.


But what is not part of Vaadin is any built-in feature for generating UI directly from existing metadata, which Smart GWT does have, both in the open source and commercial versions. And that was very, very clearly what I was talking about.

"With smartgwt enterprises loose the benefits of open source if they are using server data bindings (and this is practically everyone).

Completely false.

1. there are many, many Smart GWT LGPL users, it's not "practically everyone" using our server product (what on earth are you doing pretending to comment authoritatively on our user base??)

2. anyone using the commercial version still has source to the client system, which provides huge benefits in terms of fixing bugs themselves, migration options, etc - all the usual OSS benefits.

Vaadin has a *worse* story here, where commercial add-ons like TestBench are needed to complete the typical suite of tools required for enterprise development.

"Saying that it [replication] would be needed to being able to maintain application state if a server crashes is besides the point. In client side ria you loose the application state each time you reload the page - this is quite a bit more frequent than crashing the server."

What a bizarre statement. Server sessions are lost due to hardware, network or power failure, and this kills a Vaadin session, although it does not kill a SmartGWT session.

Reloading is a voluntary action. Users don't do it, so they don't lose anything.

Charles Kendrick hat gesagt…

"So again, there is this terrible case of a drag and drop interaction sending 2 requests a section, causing transactional replication of 200k of session state across multiple servers. It is a real case, and not uncommon both from a UI standpoint and from a server configuration standpoint."

As above - no-one should start replicating sessions multiple times a second. If you do not want to enable server-side drop target criterias, use client-side criterias.


This is a serious issue. Please stop trying to hand-wave it away.

To recap:

1. the worst case is not drop criteria. The worst case is drag and drop with visual updates required per mouse move. This is a common use case in enterprise RIAs.

2. for drop criteria, the bad case comes up when you need to write custom Java logic to check drop eligibility. Vaadin supports some extremely trivial drop eligibility checks that execute on the client (like what the source component is). This does not remove the need to very frequently write Java logic for drop eligibility, which necessarily involves server trips in Vaadin.

These cases, and many other similar, common cases, result in many, very frequent requests to the server - requests that are unnecessary with client-centric architectures like SmartGWT. Even before considering clustering, this is poor user experience and very bad performance.

Then, when you do consider clustering, each request potentially involves serializing and replicating Vaadin's substantial server-side session state across multiple servers. This always happens on GAE. It also always happens with Weblogic and other high-availability servers, because they still replicate sessions even when you set them to "sticky sessions" mode. Joonas and I disagree on how often you'll have replication enabled in other scenarios.

Regardless, when you combined session replication in clusters with Vaadin's behavior in a customized drag and drop, performance is catastrophically bad: 2 requests per second causing 200k of replicated state to be transactionally committed across multiple server, for a single user's drag and drop.

If replication is not enabled, then performance is merely very bad: 2 requests per second for a single user's drag and drop.

None of these bad cases occur for client-centric architectures like Smart GWT, where you can build a custom drag and drop interaction and run custom Java logic every mouse move and there will be zero server requests.

There's really nothing arguable in this recap. Hopefully you will stop trying to claim Vaadin doesn't have a serious weakness here, because it really does.

Charles Kendrick hat gesagt…

"Did you really just compare our much, much larger, more richly skinned, far more media intensive showcase to yours? :)"

My subjective opinion is quite the opposite, maybe we should stick to facts. Themes are of the same complexity. Number of examples in demos is comparable (have not counted, but smartgwt probably has a bit more).


By all means let's stick to the facts. The SmartGWT Showcase has 350 samples and yours appears to have about 90, so our showcase is nearly 4x larger on this metric alone.

Further, your 90 samples correspond roughly to our 90 simplest samples - the additional 260 Smart GWT samples show more sophisticated capabilities.

Further, you have less skinning options - in the high-end skin shown in our Showcase, scrollbars, checkboxes and other controls are skinned that are not skinned in Vaadin. That's why comparing to our "Simplicity" skin is more correct, as I suggested.

(4x cold start time and practically same reload times (vaadin being half a second faster)

Half a second faster with one quarter the samples is not impressive.

Let alone when you consider the less sophisticated samples and lower end skin.

Feel free to set up an apples to apples comparison using our SDK if you like. But it's already clear from comparing the showcases that the numbers will show the exact traits I said: slightly slower one-time-ever startup cost for SmartGWT, faster reload than Vaadin.

"Also one should note that with (smart)GWT the compilation time will be relative to the size of the application. In server side ria such compilation step is not needed."

As you well know, the development cycle for GWT (and SmartGWT) is to write code and reload.

Compilation to JavaScript is a one-time deployment step, irrelevant to the development process - a non-factor.

Joonas hat gesagt…

"But what is not part of Vaadin is any built-in feature for generating UI directly from existing metadata, which Smart GWT does have, both in the open source and commercial versions."

My bad there, sorry. I have been talking about binding components ti backend, not ui code generation. We are currently developing (a free) Spring Roo plugin for generating UIs in a such way that one can even edit those UIs with wysiwyg editor. But it is not ready yet.

Joonas hat gesagt…

joonas: As above - no-one should start replicating sessions multiple times a second. If you do not want to enable server-side drop target criterias, use client-side criterias.

Charles: This is a serious issue. Please stop trying to hand-wave it away.


The discussion is going rounds. You have invented a use case with a set of requirements. I do not believe that such combination of requirements exist, you do. Let's leave it there.

Joonas hat gesagt…

"Compilation to JavaScript is a one-time deployment step, irrelevant to the development process - a non-factor. "

GWT development mode is great! GWT team has done magic with it. Unfortunately it is not so great that it would eliminate all compilations.

Joonas hat gesagt…

"By all means let's stick to the facts. The SmartGWT Showcase has 350 samples and yours appears to have about 90, so our showcase is nearly 4x larger on this metric alone."

You missed the point. In server side ria JavaScript size does not vary with the application size. Adding 10000 more samples to vaadin sampler would not make it any slower.

"Further, you have less skinning options - in the high-end skin shown in our Showcase, scrollbars, checkboxes and other controls are skinned that are not skinned in Vaadin. That's why comparing to our "Simplicity" skin is more correct, as I suggested."

Let everyone judge the looks by themselves. Just click theme examples from vaadin demo page theme section.

If you want some fact based metric, why not compare CSS sizes? I am writing this with an ipad on airplane, so I can not give any figures right now. Anyone with firebug can do the comparison.

Charles Kendrick hat gesagt…

Charles: This is a serious issue. Please stop trying to hand-wave it away.

The discussion is going rounds. You have invented a use case with a set of requirements. I do not believe that such combination of requirements exist, you do. Let's leave it there.


I would be perfectly happy to leave the discussion alone except you had to say "invented" and claim the situation doesn't exist.

Exasperating.

You showed a Vaadin sample of server-side drop eligibility checks - a Vaadin-provided sample. You mentioned GAE requires session serialization. Combine the two and there you have the exact situation described.

So of course you recognize that this situation is real. At most you object to how common or uncommon it is.

As far as the use cases, in case anyone thinks they are "invented" at all, drag and drop hoop selection is what you have used to select icons on your desktop for the last 16 years or so.

This and many other custom drag and drop scenarios come up all the time in enterprise applications. Aside from the common tree and grid-based use cases, there are also Visio-like interfaces connecting processes together, assigning things to slots in various life sciences applications, and even basic things like wanting to implement a range slider (two draggable pieces which may not cross each other).

So Joonas, if you really think these "don't exist", then I submit that this is probably because your organization hasn't been invited to build such applications, because your technology would be spectacularly bad at building them!

Joonas hat gesagt…

"So Joonas, if you really think these "don't exist", then I submit that this is probably because your organization hasn't been invited to build such applications, because your technology would be spectacularly bad at building them! "

I am not going to argue about what kinds of customer projects our organization has been doing for last 10 years with this technology or bash competitors technology. So, let's leave the issue here. I am sure that the brave readers of the thread who got this far already got the pointers for their own research.

Charles Kendrick hat gesagt…

"By all means let's stick to the facts. The SmartGWT Showcase has 350 samples and yours appears to have about 90, so our showcase is nearly 4x larger on this metric alone."

You missed the point. In server side ria JavaScript size does not vary with the application size. Adding 10000 more samples to vaadin sampler would not make it any slower.


Of course it would be slower. It takes a lot longer to load and initialize the many thousands more classes that are involved and it would have far more session state. The only thing that does not get larger with server-centric architectures is an initial one-time JavaScript download, and even that's not true if you add client components.

And we're talking about a one-time ever, cachable download in SmartGWT. How big is it? With 350 samples, many of which are basically mini-applications in their own right, the size of the application code (the only part that grows) is still only 250k.

So, yes, Smart GWT requires a once-ever download of the runtime and application code, and via this one-time download, radically reduces subsequent requests.

But no, there is no meaningful downside to large applications here. Code size grows very very slowly, and GWT application splitting can break up monstrous applications if needed.

Charles Kendrick hat gesagt…

"So Joonas, if you really think these "don't exist", then I submit that this is probably because your organization hasn't been invited to build such applications, because your technology would be spectacularly bad at building them! "

I am not going to argue about what kinds of customer projects our organization has been doing for last 10 years with this technology or bash competitors technology.


OK Joonas, let me rephrase.

Out of the available server-centric technologies, Vaadin is the best in my opinion. It's far better than anything based on the overcomplicated JSF architecture, and has, I think, a slight edge over ZK.

But all server-centric technologies would be spectacularly bad at the common use cases I've covered.

Charles Kendrick hat gesagt…

"Further, you have less skinning options - in the high-end skin shown in our Showcase, scrollbars, checkboxes and other controls are skinned that are not skinned in Vaadin. That's why comparing to our "Simplicity" skin is more correct, as I suggested."

Let everyone judge the looks by themselves. Just click theme examples from vaadin demo page theme section.


Less skinning options, meaning, you can't skin scrollbars in Vaadin. It's not a subjective thing. And the skinned scrollbars means we're loading more media, so the SmartGWT Simplicity skin is closer in media usage, and would be the one to use for comparison of load time.

Note also, SmartGWT has 10 skins. The Showcase shows 3 right now because some new components don't have an appearance in all skins yet.

Joonas hat gesagt…

"Of course it would be slower. It takes a lot longer to load and initialize the many thousands more classes that are involved and it would have far more session state. The only thing that does not get larger with server-centric architectures is an initial one-time JavaScript download, and even that's not true if you add client components."

Actually it would not be any slower. With large or even medium sized apps it is recommended to initialize ui lazily. Parts of the application are only initialized when they are needed.

Charles Kendrick hat gesagt…

"Of course it would be slower. It takes a lot longer to load and initialize the many thousands more classes that are involved and it would have far more session state..."

Actually it would not be any slower. With large or even medium sized apps it is recommended to initialize ui lazily. Parts of the application are only initialized when they are needed.


Everyone recommends lazy initialization, that's not the problem. The problem is that there's more than one user, and in a server-centric architecture, each user has a larger impact on server performance when the application is larger.

Larger applications have more complex screens and more event handling logic. In a server-centric architecture, the additional event handling logic causes more frequent server requests. Also, the more complex logic and larger number of components per-screen cause more processing per request, and session state is larger.

These are all server-side effects, so they impact scalability and responsiveness for all users.

In SmartGWT, the only scalability impact of a larger application is the very small increase in once-ever download of a cached file. This is because in client-centric architecture, when you have 1000 concurrent users, 1000 machines are running the application logic, whereas in a server-centric architecture, the server is doing all of that work itself.

So, let's not pretend that some magical factor causes fixed performance in server-centric architectures regardless of application size. The reality is that larger applications, which cause more frequent requests and have more logic running on the server, favor client-centric architectures even more than smaller applications.

Joonas hat gesagt…

I fully agree that client-side ria is more scalable. The key question is does matter? It surely matters for gmail, but the number of concurrent users is in order of tens of thousands users or less, both architectures are fine from performance perspective.

Charles Kendrick hat gesagt…

Yes, it absolutely matters. A significant part of our business is upgrading failing deployments that are based on server-side architectures.

Again, in a carefully designed test that avoids all of the technology's faults, you can demonstrate what appears to be adequate scalability.

Add a few event handlers and the application becomes sluggish.

Add a custom drag and drop or fast data entry use case and user experience becomes unacceptable and performance is very bad.

Add in clustering that requires replication and performance is catastrophically bad.

It's a bad idea to adopt a technology that has these faults even if you're not hitting them in your immediate project. You risk a future rewrite. So start with something that handles the toughest cases with ease.

Joonas hat gesagt…

This starts to sound like good old "you should use assembler instead of C because the performance might be better and you have more control" - argument. Everyone should do the evaluation by themselves on what are the scalability requirements and which is the best solution within the limits of the requirements. Using assembly language for all programs might not be the best solution even though you could potentially get most control over your application.

Marc Logemann hat gesagt…

dont you think you misuse the "comment" feature? Recently its more or less a private conversation on a public blog.

Anonym hat gesagt…

Fully agree with Marc. Change email addresses and finish the argue as it seems to take a while...
Your points are out already (to simplify your argument a bit):
- if you have thousands and thousands of concurrent users that need a highly responsive drag'n drop on the client-side whatsoever: use SmartGWT
- if you want a Rich UI and don't want to mess with the client-side at all + client-server communications etc and want to have an easy access to your backend with plain Java: use Vaadin

Conclusion: SmartGWT is better in some stuff and Vaadin is better in some stuff. Surprising conclusion isn't it.

Charles Kendrick hat gesagt…

This isn't a private conversation - this post is current the top of page 2 for Google results for "smartgwt vaadin" and can be expected to rise.

Discussions sometimes happen in random places, but get found. Marc, I hope it hasn't been too much of a bother hosting it.

Regardless, I couldn't agree more that this discussion is complete and would love to exit it, if only Joonas could stop dropping bombshells like comparing SmartGWT to assembly language. In I'm more than happy for Joonas to have the last word and have it be a final plug for Vaadin, so long as its not an absurd pretense that SmartGWT is less advanced or out of date.

SmartGWT has a substantially larger feature set than Vaadin (recall 350 vs ~90 samples), but the C vs assembly language would not work even if Vaadin had a more comparable feature set.

C vs assembler is just a linear speedup. Client-centric and server-centric architectures have a sudden radical departure in performance and usability when certain common use cases, such as custom drag and drop, come up - we're talking about a visual indicator lagging ~1 second behind the mouse while the server is fielding 2 requests per second.

So no, it's not really valid to simplify this as each technology being "better at some stuff". If your writing an application where custom drag and drop, fast data entry with interdependent fields, or any similar use case may ever come up in the future, Vaadin is a poor choice.

Marc Logemann hat gesagt…

I really dont bother hosting this battle ;-) I am just wondering if anyone will read all those comments...

But of course i am happy that this will also boost my blog.

I also like people defending their product and trying to convince others. I am developer you know... i really know how it feels...

Marc Logemann hat gesagt…

With Vaadin: Do i still need to write REST services for getting data into a grid or can this be done on the server too?

Joonas hat gesagt…

Marc, no REST services needed in Vaadin. You can do everything server-side on plain Java. (just set datasource).

Charles Kendrick hat gesagt…

Neither technology requires you to implement REST services to load data into a grid.

In SmartGWT you create a .ds.xml file that either directly uses your database or Hibernate (no .Java code required) or calls your existing Java business logic (no new Java code required, or trivial glue).

Hendy Irawan @ Spring vs Java EE Blog hat gesagt…

"This isn't a private conversation - this post is current the top of page 2 for Google results for "smartgwt vaadin" and can be expected to rise."

@Charles Indeed, and I love it!
Charles, please release SmartGWT 2.3 LGPL...

"I really dont bother hosting this battle ;-) I am just wondering if anyone will read all those comments..."

@Marc I do. And I'm sure I'm not the only one. And yes, Google pointed me to this page. :-)

Your article is very useful, and I can say about 70%+ of the usefulness come from the comments between (or may I say "versus") Charles and Joonas. Their explanations are truly educative for me, at least in their respective frameworks.

Hendy Irawan hat gesagt…

@Marc I forgot to ask...

Why did you leave out JSF 2.0 ?
Was it intentional?

JSF 2.0 + PrimeFaces 2.0 would fare quite well to, say, Vaadin.. I would be interested in your (or Joonas's) comments.

moritz hat gesagt…

what i am missing is some thoughts about ext gwt (not from charles and joonas ;-))
i also found this via google and facing the same question - i'll goo client side but what to chose ext gwt or smart gwt (i worry about the "js wrapper thing" in smart gwt and debug features?!)

Mahlatse Makalancheche hat gesagt…

@Marc
I did read through the whole discussion :)

Just found out about vaadin today as i'm in busy thinking of framework i can use, and was impressed, but my typical developer mind told me to check for best competitor and i must say i found most of the arguments from both parties to be quite relevant, i love the whole "only java" idea, but on the same time, i would like to let the end-user's pc/mobile/whatever to share some of the work, so i like the idea of keeping the state on the client side cause that oboviously allows doing a lot (and some unnecessary) download to the client once and sending only what's needed to the server.

Just need to do more reading on SmartGWT to get a better comparison

Anonym hat gesagt…

Flameworks! Stop flaming, FUDing, theoretizing etc. Just improve your documentations instead.

compass2k hat gesagt…

I was comparing ext gwt to smartgwt when I came to this blog. I hadnt considered Vaadin as I thought it perhaps to lightweight.
I am now not considering smartgwt as integrity is an important quality when you want to risk an important clients project on a third party technology and Charles' weird invented scenarios of continuous server cycles drag and drop and every request validation has me doubting Isomorphic's culture.
To be on the wrong end of the like of Charles defensive, irritated and supercilious attitude when seeking support is a nightmare I have previously experienced and from checking other blogs have found Isomorphics clients report.
Good for keeping your cool Joonas and responding with fact to fluff.
I am still looking at extgwt but will also look at vaadin.

Anonym hat gesagt…
Der Kommentar wurde von einem Blog-Administrator entfernt.
Anonym hat gesagt…

If some one wishes expert view about blogging then i suggest
him/her to pay a visit this weblog, Keep up the good work.

Anonym hat gesagt…
Der Kommentar wurde von einem Blog-Administrator entfernt.