[Isomorphic]

1. you regressed on features

We did no such thing, you just suggested we could have used features that our application and users did not need

This is very simple: the features of the grid *were* there for your users, now they aren't. Presumably you would not make the silly claim that you know they've never been used and never would.

So this is a clear regression on features.

2. you made at least parts of it slower

Not any parts we measured--especially the app load time!

Then your QA team did not measure or compare the speed/scalability of filtering data in grids and grid-derived components that make automatic use of Adaptive Filtering. Record and playback a user interacting with a grid with this feature present or absent and you see far fewer requests.

Unless you just don't have a filterable grid at all, there's really no room to deny a performance regression in this area.

And, as we've covered, in almost all enterprise applications, just this one feature is far more important than first-ever load time.

3. you made yourself vulnerable to various new categories of browser bugs

None that our QA department has found, and again we clearly stated that we are using IE 10 and other modern browsers.

It seems unlikely that you've tested memory leaks (we pointed out earlier that IE9+ leaks memory whenever <img> tags are added to the DOM and later removed, also, eval() leaks). Perhaps leakless performance isn't required; that's a non-requirement in some applications.

As far as the other really really nasty bugs, they mostly come up if you are trying to achieve *true feature parity* with SmartClient. This is why we said you were now *vulnerable* to such bugs - they may not actually manifest yet in a simpler app. However, if in the future you need to deliver things like robust, keyboard-accessible, customizable grid editing with ARIA support, you need to work around a plethora of focus-related bugs and keyboard event inconsistencies, different in every browser; to implement the advanced auto-sizing behaviors found throughout SmartClient, you need to work around a nasty thicket of size reporting bugs and performance pitfalls, different in every browser, etc. It's a long list.

Big picture: it's nice that you enjoy Angular; we're not telling you that you aren't allowed to :) We wouldn't even disagree with your sentiment that moving from Java to JavaScript can be a better fit for some teams (it's just too bad you didn't try SmartClient..).

But when you claim your new application "has the same features" as a SmartClient application, that's not just true. You've previously acknowledged the power and robustness of our technology, and we are simply pointing out that in your new application, how ever much you like it, you have indisputably lost access to that power. This should not be a contentious point.

[billw]

Bill,
I can save you some trouble.

On my 5th Fortune 500 company. My 2nd one specifically in the realm of building RIA / Enterprise Apps for them.

If you end up discovering that Angular / Node / Backbone / Underscore / any other trendy JS library ends up working better for you then its probably because you aren't building RIA / Enterprise Apps or aren't in an Enterprise environment.

I'm definitely keeping my eye on Angular... but I just feel for what I do, it isn't a good fit for many of the reasons already mentioned.

I build large / complicated enterprise level web applications for mostly internal-facing users. They spend hours a day in our app. They have to find data, manipulate it, put it on BI-type dashboards, export it, tweak it externally, re-import it, chart it and send the PDF to leadership, execute business-critical decisions (changing data), have templated emails auto-sent to stakeholders and so much more. And then I have to use offshore development as well.... good luck managing that.

If you are talking about a simple ToDo App.... that can be done in SmartClient very easily but it will be bloated and then all the JS purists will complain about the JS file size.

But yea - Angular has caught my interest and I'd be interested in seeing your findings. But if you need anything close to what I have needed.... it just won't work.

Amcculley,

Reporting back on our findings. You are correct with respect to the types of enterprise features (exactly as Isomorphic has pointed out many times in this thread), Angular.js alone definitely will not suffice. Our initial application did not need these features, so Angular worked well. The application we are currently working does require many of those features, and we were easily able to integrate them thanks to Kendo's Angular directives. They support their full set of UI widgets (tree, grid, ... data visualization) and integrate seemlessly with Angular scopes. Without something like this, we would definitely be moving back to SmartClient (we used SmartClient JS, not SmartGWT). The only other option would be to write your own directives and pull in widgets from things like JQuery UI, but we would not recommend that approach. And Angular-UI comes no where close. The Kendo widgets nicely work with responsive frameworks like Bootstrap, so dropping a grid in the middle a page otherwise generated with an HTML/CSS template fits in and is mobile friendly. Without giving up the enterprise features, or writing your own directives.

Cheers,
Bill W.

[Isomorphic]

It stands to reason that amcculley has seen Kendo as well bill :)

Enterprise features doesn't mean "has a grid component". There is a huge, HUGE feature gap between SmartClient / SmartGWT components and Kendo's much less capable components, and Kendo components don't really cover any of the features amculley just listed above.

Where there is some kind of rudimentary support, the corresponding SmartClient feature is much more powerful. For example, Kendo grids, like any grids these days, can do some rudimentary filtering of data; in SmartClient, a savable, share-able, editable and exportable BI dashboard is now so simple it's a product sample with very little code.

[billw]

Kendo grids, like any grids these days, can do some rudimentary filtering of data; in SmartClient, a savable, share-able, editable and exportable BI dashboard is now so simple it's a product sample with very little code.

Not sure what rudimentary filtering is, but filtering and sorting on any column or combination of columns is pretty standard and simple. We're using it now. Are saving, sharing and exporting something that an enterprise application would rely on a browser client grid to do, or would that feature be implemented by the server-side store? Just making sure I'm not missing anything.

Cheers,
Bill

[Isomorphic]

We've covered this multiple times with you already in this thread, but again, Adaptive Filtering, as well as the advanced capabilities of AdvancedCriteria and the FilterBuilder, are just two of the more obvious aspects of why the filtering capability of other grids is rightly called "rudimentary" when compared to SmartClient.

If you have a sincere wish to understand all the feature advantages in filtering, elsewhere in grids, and elsewhere in the framework, just go through SmartClient's samples and try to find corresponding functionality in your framework of choice.

As far as your technical questions:

Saving and sharing information such as user-modified column or portal layout is a combination of client and server capabilities, mostly client. The server principally just provides a generic persistence mechanism in this case.

Export is more mixed. We have both client-centric (exportClientData) and server-centric (exportData) export capabilities which are used for different purposes, and there are key features that span the client-server boundary (such as
FormatString used in dataSourceField.format/exportFormat).

Then there's PDF export, which requires the client to be capable of producing reasonable print HTML for all components, and then has a server aspect (iText / Batik integration).