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

[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]

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]

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]

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, we realize your team has just spent a lot of time and work rewriting an application

But it was surprisingly little time, and not that hard, and paid off for us, as I clearly stated. I give credit where it is due to the Angular team for that one.

and when we point out that...

No, you actually misrepresented the facts that we stated.

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

2. you made at least parts of it slower

Not any parts we measured--especially the app 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.


Cheers,
Bill W.

[Isomorphic]

Bill, we realize your team has just spent a lot of time and work rewriting an application, and when we point out that:

1. you regressed on features
2. you made at least parts of it slower
3. you made yourself vulnerable to various new categories of browser bugs
4. SmartClient moved further ahead in the meantime
5, 6, 7, 8...

- that's got to be hard to hear, and we understand that. But it's no cause to reach for straw man arguments and attribute ludicrous statements to others.

What we actually said that was that SmartClient delivers features that are not captured in your requirements, but are nevertheless very valuable. This isn't arrogant, and it isn't a critique of your requirements process - it's just self-evident.

Nor did we say, or would we ever say, that every HTML table should be replaced by a SmartClient grid. When the use case doesn't fit SmartClient, we recommend JQuery or other tools. We even touched on this in the current thread.

Hopefully you will understand that if you post something to our forums claiming that you built an application which uses grids, charts and other enterprise components but "has the same features" as a SmartClient application, we have to correct this false claim. We don't want people to be mislead.

[billw]

I see. Anyone that has an HTML table in appearing in their application needs to use Isomorphic SmartClient, or their poor grid-feature deprived users will suffer. Apparently, an honest assesment is not appreciated here, otherwiese you would not be as arrogant to assume that we know nothing about our application requirements, after years of work, and deploying multiple releases. Wow. Maybe we should reconsider. And maybe this time, rather than SmartClient, we should try SmartGWT again which we abandoned 2 years ago--thinking that Java developers would be better suited learning how to program in JavaScript rather than continuing to use the wrong tool for the job.

Cheers,
Bill W.

[Isomorphic]

.. which has the same features as the initial version which used SmartClient, plus ..
We did not need any of the more advanced grid capabilities, ..

Here is the flaw in your analysis, which we did warn you about: if there is even one grid in your application, then your new application has nothing even close to the capabilities of the SmartClient application.

You say you "did not need" the advanced grid capabilities, but what this actually means is that it wasn't in your requirements document. The fact is the capabilities of SmartClient's grids are extremely useful to end users in all but the most trivial applications.

So you've got "feature parity" in the sense of checking off items in your requirements document, but not feature parity in reality.

This applies not just to grids, but pervasively throughout the system. We have yet to see a requirements document that says that charts should be able to swap axis and switch type on the fly, yet as we've learned from watching many end users, this has *huge* value.

There are lots of other examples of missing features, as well as performance benefits of built-ins like adaptive filtering, and this is before considering whether a different and better design could have been used in various places by taking advantage of other advanced features.

So in sum, as we said from the start, yes you can build a simplified version of a SmartClient enterprise application in Angular (or any number of technologies), but you can't build something that has actual parity with the same application built with SmartClient. You can't even get particularly close.

[billw]

Since Isomorphic spent a good amount of time “clearing up misconceptions” I wanted to post back the results of our evaluation. We have completed the initial development of version 2 of our application, which has the same features as the initial version which used SmartClient, plus the new version 2 features.

Our application is the user interface for a Smart-Grid energy management system. Managing and configuring endpoints, monitoring endpoint online status, creating and sending scheduled automated demand response signals and events, and monitoring endpoint responses to events. It also collects meter data telemetry and provides basic usage graphs, so they can observe real-time decreased usage as endpoints curtail energy in response to events. Basically, a lot of forms, CRUD operations, HTTP/REST server communication. When network monitoring, tables list endpoint properties and status, and dynamically update.

As Isomorphic has stated, the pluses and minuses of using newer frameworks like AngularJS compared to existing component frameworks must be weighed. We did not need any of the more advanced grid capabilities, and we are only required to supporting only IE 10 and other modern browsers. Overall, for our purposes, we are very happy with the resulting code structure, testability, end-to-end server communication, form handling and validation, data binding, and many other features offered by AngularJS. We also have a greater control over the look and feel of the application, and are using Bootstrap 3.0 to support both desktop and mobile layouts with the same codebase. For more advanced user interface components, our needs were easily met by integrating components such as JQuery UI and other components that already have Angular JS directives written for them. Kendo UI for example, has natively written Angular directives for every one of their components. We suspect that over time, more will be available. The downside of having to integrate some components from different vendors was for us outweighed the features mentioned here.

SmartClient is an excellent framework, and this is not to say otherwise. Some applications may be better suited for it. In our particular case, we just happen to prefer the MVC model and features provided by Angular.

Regards,
Bill W.

[amcculley]

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.

[billw]

Bill, we provided pointers to all the needed properties, taking all the guesswork out. If you want to actually contribute an implementation, that might be a good match to all the time we've spent clearing up misconceptions in this thread.

No thanks, but as noted, I shall report back in a few months with an evaluation/comparison.

Cheers,
Bill W.

[Isomorphic]

Bill, we provided pointers to all the needed properties, taking all the guesswork out. If you want to actually contribute an implementation, that might be a good match to all the time we've spent clearing up misconceptions in this thread.

But we frankly don't care to be on TodoMVC. We don't want to appear to validate, by our participation, yet another wrong way of evaluating a framework like SmartClient.

The spec'd interface isn't an enterprise app, so SmartClient and other powerful technologies are literally *prevented* from showing what they can really do. Consider that with the amount of code necessary to dumb down SmartClient components to produce a lowest common denominator interface like the TodoMVC app, you could build a much much better todo app; for one, all you need is a "deadline" field of type "date" and you have date range filtering, group by upcoming, the ability to show a Calendar or Timeline of the same data...

You have to evaluate technologies by how well they can achieve your actual requirements, period. We're confident that none of these newer frameworks come anywhere close to matching SmartClient when it comes to actual implementation of a real enterprise app, and we feel our samples and documentation make this clear, whereas the TodoMVC exercise only muddies the water.

[billw]

It's apparent that your estimate must be off by 5x or more. Each of the details of behavior and appearance in the TodoMVC sample is very straightforward to achieve, with very little code:

A checkbox column can be added with just a field of type:"boolean" with canToggle:true.

formItem.showHintInField can replicate the inline hint behavior, but actually works in older browsers that don't support the HTML5 'placeholder' attribute.

Counter/footer at bottom - cellChanged() event that calls grid.data.find(checked/unchecked).length() to get a count, and updates a Label under the ListGrid / shows or hides a button. Check All is similarly just data.setProperty().

Routing / showing subsets - just take the anchor portion of the URL, or whichever tag is clicked on, and provide it as ListGrid's criteria - client-side filtering is a built-in feature.

Persistence to localStorage - we do something much better, our Offline subsystem provides essentially localStorage, but with support back to IE6.

Styling - turn off the ListGrid header via showHeader:false. Generally just take the CSS style names from the template and apply them via grid.baseStyle, label.styleName, etc, we do this kind of thing all the time to replicate a requested look & feel.

Of course in a real application you would not downgrade the SmartClient grid this way; SmartClient is being penalized a few lines of code in various places turning features *off* that you would normally leave on.

Even so, with SmartClient placed at a severe disadvantage by setting the functionality bar unrealistically low, and requiring an appearance that wouldn't be found in the type of applications SmartClient targets, the resulting SmartClient code is smaller, and has far more capability and extensibility - the same UI code would work with remote asynchronous storage, large partially loaded datasets, etc. It supports things like keyboard navigation and ARIA screenReader support. It would also work in IE6, where all the existing samples we've looked at crash in IE8.

So post your implementation. ExtJS did.

Cheers,
bill W.

[Isomorphic]

projecting an estimate of all the code required to use your framework to act, look, and feel like the other samples

It's apparent that your estimate must be off by 5x or more. Each of the details of behavior and appearance in the TodoMVC sample is very straightforward to achieve, with very little code:

A checkbox column can be added with just a field of type:"boolean" with canToggle:true.

formItem.showHintInField can replicate the inline hint behavior, but actually works in older browsers that don't support the HTML5 'placeholder' attribute.

Counter/footer at bottom - cellChanged() event that calls grid.data.find(checked/unchecked).length() to get a count, and updates a Label under the ListGrid / shows or hides a button. Check All is similarly just data.setProperty().

Routing / showing subsets - just take the anchor portion of the URL, or whichever tag is clicked on, and provide it as ListGrid's criteria - client-side filtering is a built-in feature.

Persistence to localStorage - we do something much better, our Offline subsystem provides essentially localStorage, but with support back to IE6.

Styling - turn off the ListGrid header via showHeader:false. Generally just take the CSS style names from the template and apply them via grid.baseStyle, label.styleName, etc, we do this kind of thing all the time to replicate a requested look & feel.

Of course in a real application you would not downgrade the SmartClient grid this way; SmartClient is being penalized a few lines of code in various places turning features *off* that you would normally leave on.

Even so, with SmartClient placed at a severe disadvantage by setting the functionality bar unrealistically low, and requiring an appearance that wouldn't be found in the type of applications SmartClient targets, the resulting SmartClient code is smaller, and has far more capability and extensibility - the same UI code would work with remote asynchronous storage, large partially loaded datasets, etc. It supports things like keyboard navigation and ARIA screenReader support. It would also work in IE6, where all the existing samples we've looked at crash in IE8.