Comments on Marc Logemann Blog: Ext GWT or SmartGWT or Vaadin

Flameworks! Stop flaming, FUDing, theoretizing etc...

2011-07-20T13:12:13.201+02:00

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

@Marc I did read through the whole discussion :) ...

2011-06-25T17:40:48.239+02:00

@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

what i am missing is some thoughts about ext gwt (...

2011-04-07T15:30:01.766+02:00

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?!)

@Marc I forgot to ask... Why did you leave out JS...

2010-10-14T21:22:14.675+02:00

@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.

"This isn't a private conversation - this...

2010-10-14T21:02:40.991+02:00

"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.

Neither technology requires you to implement REST ...

2010-09-21T18:30:25.804+02:00

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).

Marc, no REST services needed in Vaadin. You can d...

2010-09-21T18:24:32.004+02:00

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

With Vaadin: Do i still need to write REST service...

2010-09-21T14:33:26.803+02:00

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?

I really dont bother hosting this battle ;-) I am ...

2010-09-21T00:27:53.093+02:00

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...

This isn't a private conversation - this post ...

2010-09-20T21:30:03.382+02:00

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.

Fully agree with Marc. Change email addresses and ...

2010-09-20T12:27:35.687+02:00

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.

dont you think you misuse the "comment" ...

2010-09-20T00:48:02.097+02:00

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

This starts to sound like good old "you shoul...

2010-09-19T23:37:10.807+02:00

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.

Yes, it absolutely matters. A significant part of...

2010-09-19T20:52:41.941+02:00

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.

I fully agree that client-side ria is more scalabl...

2010-09-19T16:37:40.603+02:00

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.

"Of course it would be slower. It takes a ...

2010-09-18T14:51:20.040+02:00
"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.

"Of course it would be slower. It takes a ...

2010-09-18T05:42:18.761+02:00
"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.

"Further, you have less skinning options -...

2010-09-18T04:50:03.874+02:00
"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.

"So Joonas, if you really think these &quo...

2010-09-18T04:44:18.153+02:00
"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.

"By all means let's stick to the facts...

2010-09-18T04:40:57.067+02:00
"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.

"So Joonas, if you really think these &quo...

2010-09-18T04:30:08.465+02:00
"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: This is a serious issue. Please stop t...

2010-09-18T04:17:37.715+02:00
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!

"By all means let's stick to the facts...

2010-09-18T04:11:08.947+02:00
"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.

"Compilation to JavaScript is a one-time d...

2010-09-18T04:03:11.205+02:00
"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: As above - no-one should start replicat...

2010-09-18T03:56:51.144+02:00
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.