Geeks like to tinker. And we really like our new toys. So when my girlfriend asked me to put together simple tool for her grandfathers business, I thought this was a great opportunity to learn something new: Polymer. The internet seemed full of glee for it; what could go wrong.
Well... Since my last post was well over three month six months ago, it is clear that this strategy went over about as well as a two front war for Germany. Quoting the project at about 80 hours, with the learning curve I was expecting to spend about 120 hours, My baptism by fire wasn't to be the concern of my patron.
150+ hours in, and at a second dead end after a full re-write from scratch. I was beaten, bruised and defeated, and I crawled back to the tried and true Bootstrap.
Was it all bad? Not really, but the technology is too green even now that it has gone production with 1.0.
Layout based on flex-box: amazing
In Chrome only. Mostly
Front end developers like to pretend that HTML/CSS/JavaScript stack creates clean separations of concerns, but where does the layout fit in this scheme?
- Is it the task of the html mark up? Not really, but the markup around the data plays a part.
- Is it the CSS? Largely, but even in combination of CSS and HTML some layouts hunger for more complexity and require JavaScript; resize events for example.
- JavaScript? Kind of, but the JavaScript really just manipulates the other two.
Flex-box, in principle aggregates the functionality of all 3 and moves them into a declarative markup in the HTML. Which is a dream, HTML really should be the layout layer. But even in chrome, some alignments produced unexpected artifacts in line heights and growing containers. And while some of these issues are resolved in 1.0, you can still see the browser struggling to deal with this new technology. And phone scrolling seems to trigger some strange elements shifts.
Then, for the LOLz, there is IE.
But blinded by the shiny new toy, I trudge on.
"Well, that's ok. The project had plans to be consumed on a chromebox, so IE support isn't necessary."
Paper looks amazing on the phone. Bulky on desktop.
Personal BIAS alert. I like paper and with a team of designers, paper can look very professional. But even google projects start to degrade on larger screens; example is Inbox, the new face-lift for Gmail. It is an amazing tool for the phone which has replaced my e-mail client on my android. But when I jump on my desktop with a large screen, the interface feels wasted; whole areas of my screen have no utilization and the larger bubblier look and feel requires more scrolling to cover less information.
Naturally, this is another area where I ran into problems; even with the background of some 8 years of art classes as a child, I am a coder first and a graphics designer never. So while application looked pretty good on my android phone, it didn't scale well to the large display; something was greatly problematic with a TV dashboard feature of the product.
Web components
No review of polymer can be complete without some thoughts on meat and potatoes of Polymer, web components; the new technology fore-casted to drive the future of Internet application.
At its heart, Polymer, is an implementation of web components, with a full abstraction layer for much easier web components creation. Web components, allow the grouping of HTML, CSS and JavaScript as one deliverable package. A package which when imported into the browser runs as any native HTML control. This brings great performance, but again the browser support currently is lacking and polyfils cancel this benefit.
But the theory behind web components, that developers can pick and choose 3rd party components to quickly develop applications makes me question if the Internet has learned anything from Microsoft's ASP.NET WebForms. It isn't completely fair to compare web components to ASP.NET WebForms, as many of the design flaws of WebForms don't effect the domain of front end development. But WebForms created a generation of developers who worked in a medium they didn't understand. The web was not a desktop application, and the abstraction shielded developers from having to understand the web applications workflow. More over, the overcomplicated abstraction made developers fear of what is under the hood. To this day I see this in Enterprise development. So will it be good for developers to drag and drop some web components onto an HTML page? Yes, they will be able to hit the ground running and create solutions but also, no, because it will shield green developers from having to understand the underlaying mechanisms of the medium they are developing on.
Conclusion
There is a lot of promise and room for growth for these combined technologies. But with out better browser support, the usefulness is diminished.
It takes 300ms of waiting before the user starts to get frustrated. Achieving quick load times is a task that is hard enough to do without the bloat-ware of multiple poly-fills. But even after bootstrapping the full poly-fill runtime, the response of loaded elements feel sluggish.
And what about mobile? My dev box is an I7 with 4 hyper-threaded cores with a 750W power supply and more memory then Bill Gates ever expected, but my phone has only a 3200mAh battery and a flimsy ARM processor. So what is the trade-off between visual feedback and battery life? If my computer stutters, my phone must in some real pain.
While for now, I am sticking with bootstrap for any contracted project, but I will continue to play with Polymor and other web component implementations until they mature enough for production.