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

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]

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]

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]

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]

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

When you are manipulating sets of Elements, even if you are using a wrapper object over each element, there are lots of bugs you cannot be saved from, because the bug is not related to a single Element but its context. These include various kinds of memory leaks, layout and size reporting bugs that arise from the combined placement of Elements, event handling and keyboard focus issues that are sometimes related to the entire DOM at once.

This is why you shouldn't be using an Element-oriented API unless you absolutely have to. This is what we mean by raw JQuery / Angular usage, and/or direct-to-DOM coding. You are exposed directly to the structure of the DOM. The fact that you access DOM elements mostly through a thin wrapper API can save you from certain kind of bugs, but not from the subtlest and most pernicious bugs.

As we've covered, there are some component frameworks implemented on top of Angular and JQuery. These *could* save you from the worst of the browser bugs - if you stuck only to the component-level API and never used direct Element manipulation. But then:

the nearest competitors for enterprise use aren't based on Angular (or JQuery), and any plans to deeply extend such frameworks run right back into the problems of direct-to-DOM coding.

[billw]

Using a component framework rather than raw Angular/JQuery is smarter

This statement makes absolutely no sense. We all understand what a component framework is, SmartClient and ExtJS are two great examples. But what is the derogatory term "raw Angular/JQuery" supposed to imply? This, plus the comment "why bother with Angular at all" leads one to believe that you really do not understand what Angular provides. If you were to compare a component framework over JQuery alone, I might agree that there are advantages to the former. But a combination of Angular and JQuery (or even Angular with its jqLite implementation) provide a full featured MVC framework. This is where the comparison must be made--not to "raw" anything. Such a statement is the exact kind of thing that you warned people "should not be listened to" in your earlier post. And a framework that provides direct control over the very elements that make up a Web UI should not be mistaken for the pitfalls of raw DOM programming. This is not the case at all.

Cheers,
Bill W.

[Isomorphic]

Using a component framework rather than raw Angular/JQuery is smarter, but in that case the comparison is rightly between SmartClient and the component framework. In this case, the nearest competitors for enterprise use aren't based on Angular (or JQuery), and any plans to deeply extend such frameworks run right back into the problems of direct-to-DOM coding.

You're not saying that SmartClient is all or nothing, are you? If someone really needs these grid functions, can't they be used with other frameworks?

Obviously not, as we extensively document how best to integrate with other components.

However, this is another commonly taken dead-end trip, since combining any two component frameworks makes it nearly intractable to meet basic enterprise needs around accessibility & modality handling, makes other basics much harder (branding, i18n), and in any case, forces you to deal with the reconciling the internals of two component frameworks, lowering productivity.

[billw]

The fact that all browsers are now passing CSS layout tests like Acid3 has created a trend where people think it's now safe to code directly to the metal. It'll be a short trend.

Where do you get the idea that Angular projects need to program the DOM to the metal? Angular projects use JQuery, Bootstrap, and other widely used and proven technologies. The Kendo UI team even did a complete refactoring of their UI components to fit into the Angular framework:

Announcing Angular Kendo UI

2. have your users say "where did all the features go?". This is a reaction we've seen a number of times from the severe downgrade to grids, export capabilities, charts and other components that comes from switching away from SmartClient. Developers don't realize that uber-powerful grid features like formula columns, grouping, highlights, Excel export etc were actually being used, and they are flooded with complaints about the need for features they had gotten for free with SmartClient.

You're not saying that SmartClient is all or nothing, are you? If someone really needs these grid functions, can't they be used with other frameworks?

Cheers,
Bill

[Isomorphic]

Excellent. We'll be happy to report back in a couple of months with a comparison of version 1.0 of our enterprise application written in SmartClient compared to version 2.0 written in Angular.js. And we will give a point for point comparison, and an unbiased assessment.

May you fare better than the other projects we've seen go down in flames from similar switches.

If you're going to report back, please report back at an appropriate phase, that is, after you've actually deployed the app to end users and gotten the reaction.

This will give you time to:

1. find out that there are just as many cross-browser issues as ever these days, such as IE leaking memory whenever <img> tags are added and removed from the DOM, or border-radius+background gradients not working in IE9 without special tricks. That's the tip of the iceberg; you'd be amazed how many bugs we file.

The fact that all browsers are now passing CSS layout tests like Acid3 has created a trend where people think it's now safe to code directly to the metal. It'll be a short trend.

2. have your users say "where did all the features go?". This is a reaction we've seen a number of times from the severe downgrade to grids, export capabilities, charts and other components that comes from switching away from SmartClient. Developers don't realize that uber-powerful grid features like formula columns, grouping, highlights, Excel export etc were actually being used, and they are flooded with complaints about the need for features they had gotten for free with SmartClient.

But that's just our experience from watching this happen a dozen times or so. Maybe you'll be different!

Also, to provide a real comparison, be sure to give an idea of the overall scope of functionality in your app, and what functionality the most complex screens provide.

This is critical information because of another silly trend we see a lot: building a trivial app that could have been built easily with absolutely any technology, declaring a brilliant success with many terrific benefits realized from the technology, then running into the wall on the next revision when requirements are non-trivial.

[billw]

Hilarious :)

Glad you are amused. :-)

If we can make an analogy: you can find many sites and pages out there where someone has asked "what's the best web framework" and there are hundreds of responses.

Exactly, which is why it's always good to do your own research, and experiment with some of the top contenders on your own.

We don't know of any enterprise application UI where angular.js applies.

Now I am laughing. :-)

If you can point out a use case in the enterprise application space where angular actually provides a better approach than our technology, that would be interesting information (although the result will most likely be a small feature that covers the use case better :)

Excellent. We'll be happy to report back in a couple of months with a comparison of version 1.0 of our enterprise application written in SmartClient compared to version 2.0 written in Angular.js. And we will give a point for point comparison, and an unbiased assessment.

Cheers,
Bill W.

[Isomorphic]

Hilarious :)

If we can make an analogy: you can find many sites and pages out there where someone has asked "what's the best web framework" and there are hundreds of responses.

Anyone who answers this question should not be listened to, because the only correct response is: "for what purpose?"

We don't know of any enterprise application UI where angular.js applies. It does seem to have use cases in certain lightweight websites where JQuery also applies.

If you can point out a use case in the enterprise application space where angular actually provides a better approach than our technology, that would be interesting information (although the result will most likely be a small feature that covers the use case better :)

[billw]

We're not sure why you would bother with angular.js at all, but if you have a reason to use ...

Because it has a lot of merit, works with standard HTML and CSS, is highly testable, and saves a lot of development time.

Cheers,
Bill W.

[Isomorphic]

Adding it at the top of your bootstrap .html file would be considered the normal way.

We would also recommend not putting any inline script in the HTML you load via HTMLFlow.

At that point you'll just have ordinary HTML in the DOM and ordinary script loading, and SmartGWT is not involved - anything going wrong at that point is something to do with angular.

[esmith]

How to load normally

Hello

I am not clear on what the normal way is.

How. Where do i load the scripts? I tried both the url i am setting. And my main html file.

Evan