Ext JS 3.0 questions

[dimitar71]

Hey guys,

Before starting I need to emphasize that all opinions and conclusions mentioned below are just my own and they might be different from the mass. I respect any others but don’t want to fall into long discussions so I would appreciate if the answers are straight to the point.

More over, we are hardcore Flex 3 shop with strictly enforced OOP and every single project here steps entirely on PureMVC. But since Javascript code execution becomes faster in the oncoming browser versions, it is relevant to investigate and see are there Ajax frameworks which might have similar points to a casual Flex dev cycle.

We had a chance to investigate plenty of Ajax frameworks including JQuery, YUI, GWT/SmartGWT/Ext GWT/GWTPHP, Javeline, ExtJS, Dojo, SmartClient, ZK, BackBase, Bindows and many others. After a long rundown we chose to dig into two – ExtJS and SmartClient. Many reasons why others fail short for us, but mainly lack of clean OOP framework structure, bad support, different than Javascript language, slow and diminish updates, etc. Of these two left there are some questions we can’t fight clear answers and would like to share here.

Questions are based on expected ExtJS 3.0 Beta and SmartClient 7.0 Beta.

1. Skinning – real applications need strong skinning support. And I don’t mean theme updates like changing colors and shadows. Anything else is just excuses.
We do like the SmartClient way where separate folders for skins and separate images named clearly for our designers (like button_Down_start.png, button_Down_end.png) and the CSS styling – [.buttonOver, .buttonFocused) – it is great, and most important “the Flex” way.
As for ExtJS 2.2 – themes are there but I don’t see any clean skinning support and this might be the same in 3.0 (correct me if I am wrong).
And the question: What level of skinning do you plan to implement into your oncoming version?

2. Declarative development – I don’t know about others, but for Views declarative development is supreme. Is it so hard to implement client-side only tag support? Because Javeline guys already did it, and same with BackBase.
To SmartClient – why on Earth do I need a server to generate and process declarative code? Hitting a server is pointless (my opinion) and there is no value but problems. Ajax === client-side and any “server” ideas add issues (especially for web apps which need to be uploaded on shared hosting where no access to server resources are allowed).
So do you guys plan to add client-base declarative support and if yes, when?

3. Editors – editor support is a must, especially with built-in debugging. ExtJS did a good job – Aptana, Komodo, Visual Studio, Spket. But… Aptana debugging sucks (there is a bug in their db for not supporting Firefox 3.x), Komodo is OK but expensive, don’t want even to mention about Visual Studio, SPKet is great for editing and no debugging. I read there is Ext JS Builder in the 3.0 trunk, but since we don’t have such account to access it we should wait till March-April when official 3.0 pops out (if not delayed).
Hm… SmartClient has nothing. Well, the Aptana plugin for 6.5.1 is there but still buggy in standalone Aptana. I do like SmartClient Visual Builder to throw some quick mockups but it’s bound to commercial support and we have to switch between the builder and external editor so often.
And the question: What level of editor support do you plan for the oncoming version and do you have some links to take a look at and test eventually?

4. Reusable component development – Could you add more real-world tutorials and rundowns how to create new components or extend existing ones?

5. Documentation and books – One book for Ext JS (basicl) and none for SmartClient. Ext JS documentation and online resources are growing, SmarClient docs and resources are very limited.
To SmartClient guys: Any chance of a book and thorough documentation/resources?

[Isomorphic]

One overall point: be sure to leave room in your evaluation for ways in which SmartClient provides advantages over Flex not just comparisons of Ajax frameworks. SmartClient's largest advantages over Ext are also advantages over Flex and you don't seem to have discovered these. More on that below.

1. Skinning: You didn't mention the most important aspect of skinning: insulation from browser quirks. SmartClient allows you to do skinning in an object-oriented way where you don't have to deal with browser-specific idiosyncrasies, or differences between different browser modes (eg quirks mode vs standards mode). I think we're the only platform that really does this. If you're coming from Flex this is extremely important unless you are willing to take a deep dive into browser CSS and layout quirks.

As you say, in most Ajax frameworks "skinning" means color changes. If you look at SmartClient's different skins you'll notice that essentially everything can change, including the use of completely different widgets in different places (eg switching ListGrid headers between pure CSS, 1 image, or triple image representations). All Ext apps look very similar but many of our customers have created a highly distinctive look and feel. We have fully implemented designs from high-end shops like Frog & Cooper, with no compromises. For detailed information, see the Skinning Guide.

As far as improvement we think what we mostly need is tools that can generate the appropriate skin settings from media sets and give you previews.

2. Declarative development: We have support for client-side use of XML tags, and the framework uses it internally for various purposes, but it isn't documented for external use and we don't recommend that you use client-side XML tags for UI. It doesn't make sense to introduce the extra overhead of a client-side XML to JS transform at runtime, we view this as a major flaw in Backbase. It's true that it may eventually become a negligible impact even on the worst-case browser + hardware scenario - at that time, we'll recommend it :)

In reality, declarative development has more to do with architecture and features than syntax (XML or JS). We would assert that aspects of the SmartClient architecture, especially the DataSource pattern, make SmartClient far more declarative than other frameworks.

3. Editors: as a sanity check, if IDE features like hopping to a method's definition are extremely important to you, you might evaluate SmartGWT vs ExtGWT instead. JavaScript IDE support isn't as strong as Java support and won't be for some time. Aptana's early support of ScriptDoc, an OpenAjax standards initiative, is about as good as it gets so far.

As far as IDE support for JavaScript, we believe we have general parity on editor features that people would actually use, correct us if that's not true. eg, what's "buggy" as compared to support you've found elsewhere? Regardless, as IDE features for JavaScript get better, we'll keep pace with those improvements by updating our plugins.

On Visual Builder, a lot is happening as part of 7.0, including the ability to directly edit the code and round-trip it, as well as DataSource wizards that allow you to instantly create full CRUD bindings to Hibernate entities and SQL databases (which you can of course customize with business logic). It's hard to overstate the importance of this last feature - it gives you a dynamic connection from visual components directly to your evolving and changing data model, with override points in all the right places. If you are used to PureMVC, this is going to eliminate a lot of repetitive code.

4. Reusable component development: have you already found:

a. QuickStart Guide Chapter 9

b. all of the examples linked from the QuickStart, including especially these two?

c. (7.0 beta only) the extensive chapter on AutoChildren?

5. Documentation and books: We can only assume you haven't actually found what's already there since we are often told that our documentation is better than Ext's:

a. the novella-length QuickStart Guide

b. approximately 1.5 bibles worth of reference and conceptual information in the SmartClient Reference searchable documentation browser.

c. approximately 450 runnable samples, not counting inline samples in docs. Many of these demonstrate end-to-end server integration, not just UI features.

d. these forums. Read them in depth and you'll discover they are chock full of actual solutions that use forwards-compatible APIs. Many other forums have a great deal of chatter, unanswered questions, and one-off hacks that don't provide a way forward for future versions.

Some major areas you didn't raise:

1. Feature parity. Between SmartClient and Flex it's close (many people have said SmartClient wins). Between Ext and SmartClient it's not close. Take a look at this list of features which are either rare among Ajax frameworks or unique to SmartClient, many of which you won't find in Ext.

2. Be sure you really take the time to understand the SmartClient architecture, particularly the use of DataSources to provide a standardized CRUD pattern and centralize metadata to avoid duplication. Sanjiv Jivan provides a good summary in this blog post (it's about SmartGWT but the architecture in the same). This is a major advantage over *Flex*, not just over Ext.

3. Be sure also to understand the scope of the Enterprise edition. If you're coming from the Flex world, compare it to LiveCycle Data Services, only better integrated with visual components and at a tiny fraction of the cost. There is no comparable Ext offering at all.

[edit: fixed bad link]

[dimitar71]

Great summary!

Thanks a lot for the detail answers, they add very strong value!

[Isomorphic]

Hi dimitar,

Please do keep us posted as your evaluation proceeds.

By the way, we noticed you posted the same series of questions on the Ext forums. Someone from Ext replied with some factual inaccuracies about SmartClient:

SmartClient embeds styles/image names in the code, which in general is considered bad practice.

In reality, SmartClient has only default style names in the code (all of which are configurable), and Ext is identical in this respect.

As far as image paths, as you pointed out, both Flex and SmartClient components have default image paths, which are configurable, and to which suffixes are appended to indicate piece names and interactive states. Far from generally considered bad practice, as you have probably realized, this makes it a lot easier to make changes to media.

We attempted to make this factual correction on the Ext forums but the post was deleted.

[dimitar71]

Please do keep us posted as your evaluation proceeds.

It will take some time.
Until something pops out for the rest of us concerning Ext JS 3.0 code (March/April as Ext JS guys state), I will try to rip apart SmartClient 7.0 and test it under heavy load in Chrome and FF 3.1 since we need to see does JS app with plenty of styles, rendering, nested layout objects, etc. executes faster than similar optimized Flex 3 one (and eventually Flex 4 with Flash Player 10 only code).
But yes, will try to post some details in time.

We attempted to make this factual correction on the Ext forums but the post was deleted.

Saw that... weird. Anyway.

[Isomorphic]

Is your to goal to implement enterprise applications that are responsive for the user, and are scalable? If so, tests that focus on raw rendering speed aren't particularly relevant. Real-world performance for the majority of enterprise apps is dictated by the number of trips to the server and especially to the database, which is a shared resource which slows down under user load. In this area SmartClient has a very dominant lead because of it's sophisticated data management, and features like adaptive sorting and filtering.

If you focus on raw rendering speed you could very easily end up picking a framework that shows a context menu in 45ms over a framework that shows a context menu in 75ms, even though the second framework has features that cause 1/5 the server requests. Both 45ms and 75ms are perceived by humans as instant (HCI research has established that the threshold for this is about 100-150ms), but those saved trips to the server will avoid delays that are very unlikely to be less that 500ms, and may expand to multiple seconds under heavy load - and heavy load is reached sooner by a framework that makes more requests.

So, be sure to use the right metrics, or you may expend a great deal of effort on "performance" and yet leave your end users wanting to throw their monitor out the window because the application is so slow :) We've seen it before, many times.

[dimitar71]

Well, like I said, don't want to fall into long discussions... but here is what I think.
A team can use a super-duper enterprise level framework with everything your imagination could ask and still the app scalability could suck big time. I mentioned on front-end dev we step entirely on PureMVC and even if we decide somewhere in future to implement a real project in JS, PureMVC has already a JS port. I might say that on the client side scalability is solved quite handy for mid and fairly big and complex apps just because of this. As for the server side and db... long story. So we want to emphasize for our tests mostly on raw rendering and front-end UI.

Now... measuring and testing round trip calls is approximate. Plus there are some good examples of others who decided to compare JS against Flex remote calls. A hundred lines of code which does a remote call and return data can be optimized in many ways and squeezing 300-400 ms of a 2000 returned items call is not that important (for us).

We have an app which do tons of calls from different providers, massive search through the database, front end is under heavy load of nonstop audio and video streams, high quality skins and many (heavyweight) UI reusable components. And although there was a point Flex 3 started to chock, after the optimization cycle I might say Flex 3 did a brilliant job.

Our clear interest is JS in the upcoming browser versions. Google and their test page with crazy results, Mozilla stating FF 3.1 will be comparable in speed to Chrome, and even IE 8 trying to speed things up. Plus seeing some articles/discussions where people say JS code execution will be 2-3 times slower than native-code execution in the next 2-3 years, this is insane.

All this indicates JS might be ready to handle heavy UI and still flying calling remote services, parsing big XML objects, etc. But all this is on theory (my opinion). So what we want is put JS in real tests. We have apps (done in Flex) where we know how they handle and what the expected values are), we need to choose one of them and rewrite it slowly using SmartClient 7.0 and Ext JS 3.0 (both of them using PMVC JS port) and test the results.

Since we are not JS gurus, seeing slow rendering and execution (say of max 10-12% slower than similar in Flex) will not be important. But that's the level of compromise.

Again, we are not interested to do full-cycle tests since they will never give right results. In any modern app everything starts with front-end. The first impression is quite important. And client-code is raw rendering. So the server-side will be identical remote calls through a web service which will return same xml objects. No JSON, no RTMP, no wonders. Old, plain web service calls and seeing how front-end handles lots of skinning, styling, deeply nested layout objects, event handling, data binding, etc.

[Isomorphic]

Interesting data but you misunderstood what we were pointing out: it's not how fast you can do a server turnaround. It's avoiding making some calls to the server at all because the client-side framework does a better job of re-using already loaded data. The best single example of this is the Adaptive Filter sample - if you have the 7.0 beta SDK installed and running on your machine it would be here:

http://localhost:8080/isomorphic/sys...adaptiveFilter

On PureMVC - we've seen this system before and would highly, highly recommend comparing the code for the same interaction using SmartClient's own MVC patterns (based on DataSources) vs using a PureMVC pattern with SmartClient's widgets or any other widgets. Pick a non-trivial interaction such as that shown in the SmartClient showcase application (a tree, searchable grid and form for editing, with automatic cache updates).

You should quickly convince yourself of the following: PureMVC gives you a clear way to organize code that you wouldn't need to write at all using SmartClient's MVC :) No need for a long discussion, just try it and see.

[dimitar71]

On PureMVC - we've seen this system before and would highly, highly recommend comparing the code for the same interaction using SmartClient's own MVC patterns (based on DataSources) vs using a PureMVC pattern with SmartClient's widgets or any other widgets.

Mm... this will need quite a time to play around and clear things in my head :-)
Thanks for the ideas and advices though, will take them into account.