My Fun Lately
Angular and Polymer
I am an avid fan of Dart and the modern web. For the past week I have been sinking more and more time into both Angular.dart and Polymer.dart as a sort of duel to see which one serves my everyday needs best. My web apps usually are not huge enough to necessitate the majority of Angular’s features and for this reason, I am simply focused on these libraries’ takes on web components. Specifically I am looking at ease of use and testability. I keep going back and forth on the issue, so here is a summary of my findings so far.
For the most part, my irk with Polymer is that it flat out does not scale. Then again that is more of my bad on trying to get it to do more than it is meant to. My polymer apps always start out simple enough where my only use for Polymer is to easily make web components. These polymer components are often scriptless in fact. Just straight html with lovely CSS encapsulation. I love it. However, I will always decide at some point to do something a little more complex that involves some Dart code to be written. At this point Polymer is still working great, but eventually I add more and more until I start thinking to myself, “this could really use some tests.” It is at that point that it starts losing its flair. First off, Polymer is not compatible with the Karma test runner like Angular is. Moving to a webpage and pressing ctrl+r is not that much of a hassle to rerun the tests, but the sexiness of the tests automatically running themselves is long gone. I mean, there are tutorials for going through the additional setup of using Grunt with the Dartium “content_shell,” but Karma was easy peasy, and I am not a node guy, nor a JS guy, so the more time I spend in that land the more depressed I get. Then, I will find myself in some situation where I start to miss some of the features Angular has like mock objects and dependency injection, and all I want to do is pull my hair out when I want to test something on the UI, but the asynchronous nature of browser rendering makes such a test hit or miss. It is aggravating!
Flip side, there is Angular. I will add that Angular is less Dart-like than Polymer. I think that is partially because the Polymer project had around a 6 month head start on Angular’s porting progress. Anyways, with Angular there are a lot of promises and great ideas, but it just does not follow through. For instance, Angular has dependency injection. This is great for testing purposes because rather than using real objects like a browser api, we can pass in mock objects and emulate the browser without the asynchronous headaches….or so I thought. For instance, the browser window object is injectable as everything is, and here is the mock window class. However, for the life of me, I cannot figure out how in the world I am suppose to use the MockWindow object. Upon construction, all of its relevant properties are null. That is not very usable, and a google search of “MockWindow dart” returns a measly 483 results. Hmmm, time to head to the mailing lists to ask some questions….that is a productivity killer.
Back to the “dartiness” as I like to call it. The problem with Javascript to Dart ports is that a lot of the time they end up looking like Javascript with the “.dart” extension added to the file. Those instances make me laugh at the poor pathetic life form who wasted their time on something that could have easily been used through the JS interop. That is of course a bottom of the barrel implementation, and Polymer and Angular are top notch ports with a lot of change from their Javascript brethren to better leverage Dart’s features. However, there are some things in Angular that leaves me scratching my head. For instance, there is an async method (if that link did not get you perfectly to that method….yeah welcome to my life) that is used primarily for testing purposes and a cool little microLeap function can be called inside for jumping through asynchronous tasks….well it kinda does. It is very picky and error prone. They really just need to use Dart’s native futures api for which I am a huge fan of. Oh yeah, did I mention that the async function has an undocumented return type? That has JS written all over it.
With all that said, and even with the extra boilerplate that Angular requires, I would still use Angular’s web components over Polymer’s. In an ideal world, I would be able to declare Angular components exactly like they are done in Polymer. Polymer’s ability to import things from the html is straight up sexy compared to doing it in code like Angular does, but hey, they are both made by groups within Google, so I feel like the merging of the projects is not too far off. Plus, Angular has a great future ahead of it, and hey it scales! So if that simple site I am making turns into a complex site, as often accidentally happens, the framework will have me covered.
