[billw]

Bill, please realize that SmartClient pre-dates JQuery, that SmartClient contains all the same sorts of DOM manipulation logic as JQuery, that we've worked with several large JQuery codebases while migrating clients away from it, and that we've implemented features for clients that involved JQuery in the rare cases this makes sense.

You may have questions about our assertions, but you can go ahead and assume we've not coming from a position of ignorance.

The expertise and knowledge of the developers at Isomorphic is not in question. Your framework is excellent, and the code, documentation, and samples speak for themselves.

The initial comments made here were not with respect to JQuery, but to Angular and the functionality it provides. You comments just seemed overly dismissive, and this is why the comments were made. Your expertise is granted, but other well known developers, consultants, and bloggers that explore current frameworks and work day to day on real world applications, from a tactical perspective, have recognized the positive aspects provided by Angular. If nothing else, it is worth investigating.

The level of abstraction provided by a framework corresponds to the number and type of browser bugs it can save you from. When you are using a ListGrid component through it's API, we can ultimately save you from just about anything. [...] This is why you shouldn't be using an Element-oriented API unless you absolutely have to.

Browser bugs, IE leaks, and other nasty stuff are no fun to deal with. Frameworks should centralize the handling of such issues. But it should be possible without completely removing developers and designers ability to work with HTML and CSS markup. Perspectives vary. Here is one discussion from developers of high-end Web apps that are against both component framweworks and the approach taken by Angular:

http://britesnow.com/blog/choosing-t...ml5-technology

Our initial evaluation of Angular in terms of a clean MVC model, testability, access to HTML/CSS markup, and many other factors, including support from other useful tools (Yeoman, Grunt, Jasmine, Karma, etc.) suggest that it is worth evaluating. Ideally, it would be great if it could be incorporated with individual UI components, as needed (e.g. Isomorphic Grid), but if those include an all or nothing approch, that might not be feasible.

As noted, we will report back with the results of an in-depth evaluation. If we find this approach is not useful, and the component architecture provided by Isomorphic overall wins out, we will certainly be happy to say so.

Thank you for your comments.

Cheers,
Bill W.

[Isomorphic]

To sum up what we've said about Angular (or any similar tech): as a working definition of a sophisticated enterprise application, let's assume the end users would be able to make use of sophisticated features like frozen columns, grouping, advanced filtering etc. Then:

1. if you deliver anything less than the capabilities of SmartClient or similar high-end frameworks, you're shorting your end users by delivering an underpowered app.

2. for a technology with lesser features to be considered, it would need magic-wand-like productivity benefits - this just doesn't exist given how productive you can be with the frameworks that deliver high-end features

3. combining any two technologies in an attempt to leverage a powerful grid mixed with widgets or templates from some other technology generally leads to either failure or very low productivity

This is why, when someone brings up Angular or another technology that just isn't even in the realm of the same functionality, we would ask "why?".

It's a fair question. It is not being dismissive, it's just that the situation above implies that the most likely reason people are looking at Angular for enterprise apps is just they have some misconception. And this has been turned out to be the case dozens of times.

Browser bugs, IE leaks, and other nasty stuff are no fun to deal with. Frameworks should centralize the handling of such issues. But it should be possible without completely removing developers and designers ability to work with HTML and CSS markup.

You need to re-read the discussion from the previous post - if you expose Element-level access to the DOM, there are bugs you cannot address while providing that API. It doesn't matter how well written the framework is or how meticulously centralized it is. If there is an Element-level API, that's game over as far as addressing one major category of bugs.

Here is one discussion from developers of high-end Web apps that are against both component frameworks and the approach taken by Angular:

http://britesnow.com/blog/choosing-t...ml5-technology

A perfect closer to the discussion :) This article doesn't mention what kinds of apps are being built, then hand-waves away a feature gulf the size of the Grand Canyon based on vague philosophical principals alone.

Why would someone write something like this? Because you're reading marketing materials for a services company. There are dozens of little shops like this, and they generally won't recommend any of the leading technologies, because the companies behind each of those sells their own services.

We also don't see anything that suggests they've ever built a high-end web app (at least nothing we'd consider high-end!).

There's good discussions to be had out there, just always consider the source (including when talking to us, of course!).

[billw]

A perfect closer to the discussion :)

The discussion in the development community will be ongoing, you can count on that. Looking forward to seeing your implementation on TodoMVC, if that's not beneath you.

Cheers,
Bill

[Isomorphic]

If one can count on anything on the internet, it's that the discussion continues regardless :)

We won't be participating in TodoMVC, not because it's beneath us, but because the spec insists upon a close match to specific HTML.

As we've covered, frameworks that focus on direct manipulation of HTML cannot protect developers from a broad class of serious bugs, so requiring a certain HTML markup is asking us to throw away one of our core benefits and hack something in a way we would never recommend.

But you can look at this sample for a similar, but much more sophisticated UI, in far less code. Add canRemoveRecords:true if you want the ability to remove records.

[billw]

If one can count on anything on the internet, it's that the discussion continues regardless :)

We won't be participating in TodoMVC, not because it's beneath us, but because the spec insists upon a close match to specific HTML.

As we've covered, frameworks that focus on direct manipulation of HTML cannot protect developers from a broad class of serious bugs, so requiring a certain HTML markup is asking us to throw away one of our core benefits and hack something in a way we would never recommend.

But you can look at this sample for a similar, but much more sophisticated UI, in far less code. Add canRemoveRecords:true if you want the ability to remove records.

I have commended your samples in a previous post, but now I am laughing. There is no way you can claim that sample is more sophistocated and with less code--it is neither, as anyone can tell by a) looking at all the other the TodoMVC examples, and b) by projecting an estimate of all the code required to use your framework to act, look, and feel like the other samples. Just because your grid has the sophistication of "frozen colums," don't expect the merits to be based solely on saving developers from the perils of HTML5/CSS by not allowing them to access them.

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.

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

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]

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.

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

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.

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

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]

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]

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.