Philipp Bärfuss (Magnolia)

2011-11-11T15:34:06.215-08:00

This comment has been removed by the author.

I've used SmartGWT about one year in our compa...

2011-11-03T06:28:43.436-07:00

I've used SmartGWT about one year in our company, but finally we decided to migrate on Vaadin, and eventually on ZK because during a proof of concepts phase it shows a more acceptable performance. This was a collective decision (whereas I personally would prefer a Vaadin due to its 'all in Java' approach - feel disgust to JS & markup chaos). As to SmartGWT... it looks & feel very well but work in real word... not so good... I was forced to spend many time in FireBug to determine its bugs or right call semantics/usage.

hi Philipp, can I ask you news about AdminCentra...

2011-10-11T09:05:53.938-07:00

hi Philipp,

can I ask you news about AdminCentral test project based upon Vaddin ? Is it still alive?

2011-10-11T09:04:33.298-07:00

This comment has been removed by the author.

Good post man, you have indeed covered the topic i...

2011-07-19T06:17:10.694-07:00

Good post man, you have indeed covered the topic in great detail. thanks for sharing information.

Thanks
comparator and comparable in java with example

Thanks Philipp, that was interesting! Looks like...

2011-04-15T05:51:43.716-07:00

Thanks Philipp, that was interesting!

Looks like Magnolia 5 is coming along well!

Regards,

Richard Unger

Very interessting, Philippe! Thanks a lot for this...

2011-04-13T10:29:41.133-07:00

Very interessting, Philippe!
Thanks a lot for this post!

Yes the example shows a paragraph combined with it...

2011-03-21T01:30:33.232-07:00

Yes the example shows a paragraph combined with its dialog definition. Doing the same for pages would not differ at all. I just picket the most obvious and simples example.

"pragmatic registration" indeed interesting ;-) please read programatic registration

Hi Philip Your blog post has been discussed @ the...

2011-03-19T04:02:57.582-07:00

Hi Philip

Your blog post has been discussed @ the latest hackergarten. I personally think your idea is great and feasible, but why "only" on paragraphs? I don't know Magnolia enough (yet), but I can imagine that a whole website (pages, paragraphs, dialogs, commands) beeing defined in a DSL. And Groovy is a great language to do so.

Oh and btw: Vaadin is a perfect builder candidate too....

Mark, it sounds like we've each worked on very...

2011-02-22T12:55:31.861-08:00

Mark, it sounds like we've each worked on very different sets of applications.

To explain my perspective, I've either directly implemented, been the managing architect, or been deeply involved in about 80-100 large scale enterprise web applications across the global 2000, many enterprise ISVs, and lots of SMBs and startups.

I can tell you that:
1. custom drag and drop is not at all "fringe" in these types of applications. Companies build custom software because existing off-the-shelf solutions aren't good enough, so it's very common that the UI is advanced and has requirements for client-side interactivity on at least one screen. And it only takes one screen for the overall requirements to be unable to be met by a server-centric technology.

2. yes, it's accurate that client-centric solutions are "always" faster across all of these applications. Please realize that you're referring to latency requirements while I'm talking about the *complete absence* of a trip to the server. Client-centric solutions can provide instant response in many, very common use cases (grid filtering, live input checking, etc) - when you watch expert users ripping through large datasets in a SmartGWT interface, then you'll understand my unqualified statement that a server-centric solution is going to feel sluggish.

1. offline is impossible I write web apps. I'v...

2011-02-22T12:36:45.807-08:00

1. offline is impossible
I write web apps. I've never written an offline app. If you need offline, then you will want to consider this.

2. the application will always feel sluggish relative to a client-centric solution, especially when latency is high or the server is loaded

'always', 'especially when' - I call FUD and plain misinformation! You simply can't say 'always' when talking performance claims, you are never right! The applications I've written with Vaadin are very responsive, an exceed our latency requirements by a significant margin. Sigh...

3. advanced drag and drop scenarios in which logic must run on every mouse move...
I don't care, and most developers won't in this fringe scenario...you make every potential concern sound like a 5 alarm fire.

4. scalability and clustering issues as discussed above
I've already referred to those above.

And yes, I'm the CTO of Isomorphic (not exactly a secret), regardless, what I've said is both accurate & verifiable.

Mark says:
Actually, its clear that you are making statements like 'always' and 'has to' when its verifiably not the case.

Please stop with the hyperbole so a better conversation might be had.

I don't know how good RAP is, but one thing is...

2010-12-28T07:19:02.583-08:00

I don't know how good RAP is, but one thing is sure: it's not as popular as Vaadin recently is.
One of points when choosing a framework is it's popularity: more popularity means more community support more books, more tutorials, more programmers available, etc.
Unfortunately RAP doesn't shine in this area as bright as Vaadin (although Vaadin is also not as popular as let's say JSF, but anyway Vaadin is quite well known).

Why not Eclipse RAP? Did you consider it also?

2010-12-27T15:16:09.200-08:00

Why not Eclipse RAP? Did you consider it also?

Philipp, I like it! Very nice. I'd love to d...

2010-12-10T21:19:26.174-08:00

Philipp,

I like it! Very nice. I'd love to do this for Twigs.

What do you think about a common way of importing groovy packages/classes into the scripts workspace? Sort of like the templating kit does with freemarker scripts for inline templating.

Thanks,
Matt

Interesting idea. I would also consider JSON. Wh...

2010-12-09T01:36:07.796-08:00

Interesting idea. I would also consider JSON. What do you mean by "pragmatic registration of dialogs, paragraph, ..."?

I linked to the example so you could see a further...

2010-11-12T15:28:10.820-08:00

I linked to the example so you could see a further explanation and verify the claim yourself. The Adaptive Filtering & Sorting behavior means that local filtering and sorting kick in automatically when the dataset has been reduced to the point that it's all cached. User very very rarely choose to scroll through a dataset that's too large to cache, so this feature tends to eliminate server contact for the vast majority of sort and filter operations.

This is just *one category* of server request that SmartGWT eliminates, that's why the aggregate benefit is 10-100x.

As far as clustering and sticky sessions:

1. GAE does not support them, and you can expect this to be the case for other global-scale cloud services. It's difficult to support sticky sessions when you have dynamic DNS and sophisticated load balancing scenarios involved.

2. sticky sessions do not avoid replication overhead in many scenarios. Even with stick sessions enabled, clustering solutions often replicate anyway, to at least one other cluster member. And they should, because it's not acceptable in many applications (banking, portfolio management, telecom ops, defense) that a batch of user sessions are lost if a clustered server crashes.

And this is just the scalability aspect. Big picture:

1. offline is impossible

2. the application will always feel sluggish relative to a client-centric solution, especially when latency is high or the server is loaded

3. advanced drag and drop scenarios in which logic must run on every mouse move basically cannot be achieved with acceptable user experience & server load. Likewise anything where you want to run logic per-keystroke.

4. scalability and clustering issues as discussed above

And yes, I'm the CTO of Isomorphic (not exactly a secret), regardless, what I've said is both accurate & verifiable.

"Vaadin and other server-centric applications...

2010-11-12T09:54:38.916-08:00

"Vaadin and other server-centric applications will hit the server for every sort and filter.
SmartGWT will do most operations client-side. These are the critically important requests
since they are requests for data."
This often requires going server side because the client will not have the full data set to sort/filter on anyway.

"While we're on the topic, 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."
Nonsense, that is completely dependent on the type of clustering implemented - sticky sessions commonly used for this.

The 10x and 100x arguments are off base - many different things contribute to performance characteristics. Just making statements like that make me realize that you have an agenda to push. The I saw you were from SmartGWT - surprise, surprise.

Sigh

Nice.. pretty nice.. We needed spell checking and ...

2010-10-21T06:53:22.051-07:00

Nice.. pretty nice.. We needed spell checking and simultaneous editing warning until mgnl 3.5!!! ;-)

Good work, Philipp!
Matteo

Actually, GWT and SmartGWT will typically send far...

2010-09-10T13:07:10.296-07:00

Actually, GWT and SmartGWT will typically send far fewer requests than the corresponding UI
implemented in Vaadin (or other server-centric) technology. This is in fact one of the prime
strengths of client-centric technology. See this SmartGWT sample:

http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category

Vaadin and other server-centric applications will hit the server for every sort and filter.
SmartGWT will do most operations client-side. These are the critically important requests
since they are requests for data.

As far as your dialog example, in SmartGWT this would also be one request, even if parts of the
dialog are dynamic - you would use queuing (see SmartGWT QuickStart Guide, Chapter 8,
"Queuing") and in many cases, queuing is automatic.

http://www.smartclient.com/releases/SmartGWT_Quick_Start_Guide.pdf

Finally, the lack of client-side event handling means it is not possible to handle certain
common RIA use cases in a server-centric model, specifically customized drag and drop, as well
as rapid data entry with interdependent fields - too many server trips.

And you can never have an offline mode.

These may not be requirements in your application today, but requirements change.

While we're on the topic, 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.

Really interessting. We are at the same phase http...

2010-09-06T23:54:48.775-07:00

Really interessting. We are at the same phase http://www.logemann.org/2010/09/ext-js-from-java-programmer-perspective.html. We evaluated Ext GWT and someone point me to Vaddin which i have not known so far. We will do a comparision wrt widgets and overall programming style in the next weeks. Pretty exciting.

Maybe Vaadin demo is written incorrectly, and they...

2010-09-03T13:18:24.877-07:00

Maybe Vaadin demo is written incorrectly, and they use server-side code where GWT code should be used for better interactivity.
Due to bad feelings after clicking Vaading demo I haven't tried it yet, although I know about Vaadin for some time.
Is Vaadin-GWT integration done well, or it requires some tons of boilerplate code?
If it's easy, I think that Vaadin developers should improve their demo to avoid so many server calls. Probably there are other people disappointed with this problem.
Looking at demo examples and trying to implement something own is probably the fastest way of learning a new library, so good demos are very important.

True, ZK has a very similar approach and in my opi...

2010-09-03T12:42:25.836-07:00

True, ZK has a very similar approach and in my opinion it is a matter of taste if you prefer one or the other. We liked the face of Vaadin, the license, the services and the community and we like that the client side part of our application can be written in GWT. We like GWT so we like Vaadin ;-)

In response to the comment of iirekm: I have outl...

2010-09-03T12:26:40.884-07:00

In response to the comment of iirekm:

I have outlined my arguments in my former blog post "line of argument" in details but in short:

1. if you interact with the UI you normally also need data (tree view, dialog)
- it does not make a difference if you request data or send an UI event
- the more data/configuration driven the application, the less difference can be seen

2. in Vaadin you can write client side code using GWT
- if you don't need the server you don't have to ask it (accordion menu, context menu)
- we do that in the page editor where we will write a bunch of client side code

3. we use Vaadin to implement the new Magnolia back-end
- it is not used in the front-end (public pages)
- I share the concerns in regard of high traffic web-sites

4. The GWT and ExtGWT samples are mostly plain client side code
- they are responsive
- but only as long they don't need to load data

We have mainly chosen Vaadin to overcome some limitations with the plain GWT approach. The basics can be looked up in "the Odyssey" and I hope to line out the GWT library linking problem in a future blog post.

There's a problematic thing with Vaadin: most ...

2010-09-03T04:15:49.894-07:00

There's a problematic thing with Vaadin: most GUI code is executed on server side - try for example Vaadin demo (http://demo.vaadin.com/sampler ) and see HTTP requests in for example Firebug. This can make GUI inresponsive with slower internet connections (it's not possible to get ping 500 ms between 2 any places in the world). What's more, many people connect to the Internet via digital TV satellite networks or via cellphone networks - ping is really slow there. I have tested this Vaadin demo with a quite good cellphone network (HSDPA), and I'm not pleased with the speed of Vaadin.
Another problem is that server may be quickly overloaded when many people click at the same time.

Pure GWT or GWT ExtJS don't have such limitations - the demo at http://www.sencha.com/examples works very fast even with my HSDPA.
Of course GWT makes bigger burden related with Java -> JavaScript conversion (you have very restricted Java API), but the only rule to remember is to use it wisely: if some computation can be done at server, do it at the server, don't translate all Java code to JavaScript code.

For me Vaadin can be possibly used for intraned apps (where network is usually fast), GWT for internet apps (where network can often slow down).

Is the code available somewhere?

2010-09-02T05:29:13.498-07:00

Is the code available somewhere?