[ilaksh]

As far as the particular issue he picks on, he is making a big deal about something that's not, at least if you accept the general premises of Angular, and trying to pin the core of his whole argument on that. Which is dumb.

Anyway, I have used many, many different UI frameworks on different platforms over the years. Including different .NET systems, Backbone, Angular and to some degree web components. And many other lightweight and heavyweight systems.

I am actually amazed that developers are not immediately seeing the obvious advantages of Web Components (with Polymer for now).

I am amazed that people are still trying to master AngularJS when we have Polymer. (At least the people who can tell their users to use a new version of Firefox or Safari, which is actually quite a lot of web apps these days, although obviously not all).

Angular is very obviously more complex than necessary.

Very few people are going to be with me on this, but this whole idea of separating out scope and avoiding global variables at all cost has got to the point where it is just ludicrous. And the only explanation is that this stigma about global variables has a religious and un-questioned association with incompetence. Unfortunately that particular cargo cult can lead to things like Angular DI.

Why aren't more web developers excited about Polymer and Web Components? Because many web developers, despite experience with Angular, get distracted by DI and other over-complex topics and somehow fail to completely grasp the basic concepts and advantages of what a user interface component is and does.

[acjohnson55]

I disagree with you that the hacky DI scheme is something that should be ignored. It's brittle and really has no place in the core of a library like this. It's not an end of the world thing, but it's definitely worth addressing.

I totally agree with you that Angular is overly complex. I feel like they somehow either overshot or undershot the correct layer of abstraction, and I'm not sure how. It can produce really elegant projects for sure, but when you need to actually understand what's going on...prepare to navigate a whole new world of linkers, compilers, injectors, scopes, directive options. The spiral just keeps on going.

I don't get the defense of global variables. I feel like it's been proven time and time again that the trouble of encapsulating code and explicitly coupling parts of an app through clear interfaces pays dividends. I think class and module patterns have been a major turning point in the maturation of Javascript. I'm hoping that when we finally get native opinions of these concepts in ES6, we won't need so many reinventions of the same thing.

[ilaksh]

Hm. Forget I mentioned the term "global variable" since it is a religious term.

I am not trying to argue against proper encapsulation and coupling/decoupling. Those things are great. Classes and modules and great. Not sure how you see me as attacking those things.

Say I am working on a web application and I want to use AJAX. I should not have to keep saying in every place that I want to use it "oh by the way I am using AJAX".

If you agree with this then exactly what sort of encapsulation and coupling would you recommend for the overall application to achieve not having to keep saying that it wants to use AJAX?

[acjohnson55]

I think you should basically say "oh by the way I am using AJAX", whether that means using Angular-style DI or require or a mixin some other means. In a language with a built-in concept of modules, you'd have to import or include something like that, wouldn't you?

There are some practical benefits, aside from the general happiness provided by namespacing. Not that every single app needs this, but it's pretty handy for example to be able to substitute a mock AJAX service for testing and offline development purposes.

[grumblestumble]

Web developers are excited about Polymer and Web Components. However, using a product still on release 0.2 for building real-world, production apps is generally frowned upon by anybody over 16.

[STRML]

I've built a few projects with Polymer, including this public-facing one (http://securesha.re), which is a poster child for why you shouldn't use pre-alpha software (see the blown stack in the console; this was working just fine a few browser releases ago). Thankfully, it's not a critical app and it's more of a proof-of-concept than anything else. The source is available below [1].

It was a joy to build Secureshare with Polymer and it really made me rethink what an HTML element can be and what it can do. You have to unlearn years or decades of assuming that an HTML element has almost no useful API; with Polymer, you're likely to define many core application functions directly on DOM elements themselves. It's a lot of fun once you get used to it. <polymer-localstorage> and <polymer-media-query> really opened my eyes to what was possible with this new paradigm, and it is unquestionably cleaner than what has come before.

More than anything, I'm excited for the inevitable deluge of web components; finally, UI libraries that can that be mixed and matched in any web application without regard for what other JS and CSS is on the page. True isolation allows us to create truly fantastic projects.

[1] https://github.com/STRML/securesha.re-client

[AdrianRossouw]

Did you read my preface or the other 2 articles in the series?

My argument was just 'this is wrong. dont do that', not that angular was bad because it did that.

I am excited about web components and I'm dying to find the right project to build something with polymer, but they just aren't mature enough for this yet.