Riding the Polymer wave

Comparative analysis of the developer experience for creating a multi-screen, single page application complete with persistence, animations and rich client data management w/ filtering. 

This piece will describe the development process of the creation of a single page application that harness multiple rest resources to compile a cohesive user application with multiple views, data filtering and persistence using the Polymer library. The process is describes as direct comparison with the process of building very similar application using the closure library and tools collection. The analysis is made as an effort to point out the pros and cons of migration from closure tools and libraries to the modern Polymer project as framework/tool set for building such applications. 

The post is quite lengthy so if you are looking for a quick summary scroll down to the bottom of it.

I will start with some background information: I have been building large scale single page applications for the last 5 years. I have been using many different tools for that purpose for one reason or another (some of those being: project already have been started using a particular framework that is not playing really well with anything else, the project required really small footprint as it would be server many many times without caching, and other). Some of the tools I have been using extensively include: MooTool (archaic, I know), jQuery (ridiculous, I know!), GWT (Java, I know), Closure library and tools (templates, CSS pre-processing, compiler) (really really verbose, I know), TypeScript (just a toy, I know), Dart (not really what it is portrayed to be, I know) and other - on occasion.

From all of those, the most reliable one and most trustworthy thus far at least in my use cases was Closure. Google really put efforts into it. The main problem with Closure is that it was designed with several things in mind, that kind of trip over JavaScript developers coming from any other framework/library:

• designed to look and feel a lot like Java
• designed to be production useful explicitly only with the Closure compiler 
• designed to be compatible with old old old browsers
• designed for internal use primarily and thus lacking the polishing of the other competitors out there

From those probably the biggest obstacle one could have with Closure is the fact that it is designed to actually use types, while JavaScript is designed to not use those. This is also the fact why TypeScript is used mostly as a transpiler these days and much less as compiler - types are not something JavaScript developers want/need to deal with.

Assuming the developer has the time and willpower to learn about the basic ideas inside closure (so types, the fact that you actually have to be able to imagine everything the compiler will do to your code in order to write something that will work after compilation, the fact that you actually need to test both source and compiled versions) - those great ideas and the advantages they bring could become part of your daily coding routine.

However even if you become the master of imaginative compilation and you are able to write code without errors (coming from the compiler) - those will never mitigate the fact that to write closure compatible code you have to always be very very verbose. Actually you have to write so much boilerplate code that even Google attempted to come up with some shorthand versions (mostly I am talking about goog.scope). Those efforts are however nothing compared to the amount of code one need to write to get going. This includes the type information (obligatory - the compiler is still not so smart to infer all types from the code directly and probably will never be), the namespaces and the fact that you need to include all used namespaces in the beginning of your file. Also from my experience it is very much possible to often have slightly overlapping functionality just because the design of a super class does not allow for some particular alternations (a property being important for your subclass but it being private in the parent class etc - no, you cannot alter the source code and no, you cannot just access it - the compiler will scream at you and who knows at which point the compiled code will stop working just because you are accessing something that is marked as private and the compiler can remove it as it sees fit...).

Part I: The good

Polymer is a new library from Google, that attempts to provide opinionated but easy to use abstractions over the new Web Components standard. It promotes declarative syntax for creating and using custom elements that should be compatible with all modern browsers (this includes the last two versions of all 'ever green' browsers).

Polymer itself is consisting of a polyfill for the platform features that are missing in some browsers (actually the only browser that has implementation for all web components specs is Chrome) and then the 'opinion' on top of it (polymer itself) on how to utilize those features to create developer friendly, fast to develop and easy to use custom elements and web applications.

First of all - instead of JavaScript you are writing mostly HTML - tags, attributes and properties. What you would write as new namespace with instance properties now you write as an element (polymer element tag) and attributes on a prototype object.

Here comes the first new thing - in Closure we do not write primitive values (nor object types - like NEVER) on the prototype because it alters the hidden class of the instance if altered after the instantiate phase and thus potentially makes your code run slower. In Polymer it is encourages for readability reasons and to easier understand what is going on. You can still write all properties in the 'ready' method, but the polymer implementation encourages you to use the prototype object of the element to define those and they are used for type conversions (for example the attribute will always be written as string, but you can hint polymer that you actually want to use numbers and thus the string will be automatically converted to number). One can also argue that this saves memory, but unless you are creating thousands of elements this is not really important.

Being able to not really care for the type (i.e. if the correct type will be passed to the property as value etc) and instead hint the type and expect the system to convert it for you is really a great developer experience and removes burden from the developer while in the same time proves usefulness (if one binds the input value to a money conversion element there is no need for the developer to manually convert the string to a number). So +1 for Polymer for not caring about the types and another +1 for managing type conversion for you.

After you define your custom element you need to (for UI components at least) make some templates. In Closure this is done with the soy template language, which is not so bad per see, but is cumbersome to work with - it is not possible to render your template in the browser without a) having a consuming element/component and b) valid model if data is used in the template. More over the template cannot be used directly, you always have to compile it before you can see what it looks like. So basically you end up writing HTML like files, but you cannot preview them and you cannot use them without all the boilerplate code around it. You certainly cannot just visualize that particular template with ease - you need to setup a whole new view with imports and more code just to see what you have done. This forces a certain type of workflow that seem a bit unnatural - first the designers write the view as regular HTML and then you (the JavaScript developer) take that piece of HTML and strip it out and turn it into a template and you hope that you did not broke anything.

In polymer the template is just a regular HTML. Testing it is as simple as including your new element/components in any web page.  +1 for Polymer and easy to use and create templates.

Once you have a basic element (so some template structure and some properties to operate with) you might need some ready to use functionality - you need an import. Unfortunately here polymer and closure, while in totally different in technical perspective ways, operate very similarly from consuming point of view - you have to always include what you need in each and every of your custom elements/components. In closure you do not have to care about file paths so shifting files and directories around is much safer (in Polymer it was a nightmare to have to move some elements to a different directory mid-project - we needed to go and find all the places those were used and update them), but you cannot automatically retrieve needed libraries and elements. In polymer the preferred way to manage dependencies is bower. While it is very nice the installed elements are very volatile to path alterations and once you start it is hard to update those. In both cases however you have a lot to write!

• In closure - the whole namespace for each used element/utility
• In Polymer - the full path of every used component (and writing "bower_components" all the time is not fun!)

Because of that no +1 for Polymer in this area.

After all these steps you can potentially have a self-contained ready to be used, re-used and extended/augmented piece of code. As a whole the closure code will be 50% larger (mostly because of the type comments, but if you put comment on your polymer code it would be the same size). The main difference is that in Polymer you end up with a single file (or 3 files, depending on how you structure the component CSS and Script could be separate files, but I tend to keep everything together for more cohesive experience), in Closure you end up with at least 2 files (for UI components) - one with the scripting and logic and one with the markup. The markup of course can live with the markup of other components in a single file under a namespace which makes it even harder to separate your code and distribute it as a single element.

Polymer also provides utilities for documentation and demos of your work (again elements that automatically extract the code comments and construct html in the browser). To do the same with closure code you need jsdoc and templates and basically you are on your own there because the docs of closure library are generated internally by Google and the ones you can generate look and behave nothing like Google's - they are less usable and uglier.

Because of these not so important but kind of not unimportant reasons Polymer gets one more point.

Part II: The bad

Not all is roses in Polymer land either.

First thing one could notice is that because of component reuse and the ease of instantiation basically you are inclined to use lots and lots of elements that provide utilities and no UI. The most notable example for that being core-ajax. In a single view page you can have several core-ajax elements. In Closure land you usually have one 'Loader' class that takes care of all the communication to specific REST endpoints and when an error occurs you decide what to happen next. In Polymer each core-ajax element lives on its own and you might end up having 30+ such elements in your app. You can define error handlers on each of them or listen for core-error globally (on application level). The problem is that you end up with ajax request originating from pretty much anywhere in your application and it makes it harder to manage. Also it is pretty hard to limit what is happening when because you do not have central control over it. Of course you can write such, but it looks unnatural. As a side effect you can load pretty much all your request except one, but it will take time to notice that you failed in that one request.

Another catch you have to deal with is Shadow DOM's CSS rules. Once all browsers implement Shadow DOM it might be great (and it will be in theory) but today you end up with styling that is very volatile under the polyfil. The first time you start styling you are tempted to write rules that are automatically scoped (for example adding classes like '.padded' in several different elements with different values inside of it). Under native Shadow DOM it works fine, but under the polyfil you will get overlapping rules and definitely not what you expect. The main problem with that is that you actually develop in browser that has native Shadow DOM and you do not notice that there is a problem until much later (and of course you are developing with Chrome, right? If you use anything else for development this whole post is probably not for you anyway). Once you realise what is going on you end up writing all rules as if they were un-scoped (so ':host .padded' which defeats the purpose of Shadow DOM - even with Polymer you still have to think about your styles as global - not cool!

Next come RAF and timeouts: The documentation for polymer states: 'async is bound to animation frame'. Well it is, unless you specify timeout in which case setTimeout is used and you loose the RAF timing. To gain that back you end up with atrocities like this:

this.async(function() { this.async(function() { _doSomethingToTheUI() }), null, 500);

I know, it is not that bad, but still looks a bit unnatural. Also guess what if you need to cancel this delayed work... you need to handle the case where the first async is already executed but the second one is not... this makes async programming fun, doesn't it!

Another async related code - 'job' is working around a common pattern and is designed much better and actually reflects real pattern. The implementation for it (as in polymer dev) is actually a bit different than what is expressed in the docs, but still is a nice enough utility.

Next comes the scroll handling: in Chrome scroll events are synchronized to the RAF, but in all other browsers they are not. However guess how scroll events are handled in Polymer...

Same goes for touch events. I know that it is best to think forward, to innovate and blah blah blah, but when you are pressed to deliver working code for those old phones Polymer is not not your friend.

This is especially true when it comes to the animations: the design and the looks are really really great - for the first time you get a framework that allows you to implement very complex and very impressive transitions and animation with so little effort. They are amazing when demoed and when they work. Now try to run the exactly same code under Firefox... or under iOS safari.. Hero transitions do not work as expected, sliding transitions are braking the view completely in Safari... and in Internet Explorer ... there is a bug that prevents platform polyfil from loading... fun huh?

Basically polymer teams says that they support and want to support all major browsers, but the reality is that once you go beyond the simplest demos it only works reliably in Chrome. This is not so bad if you are targeting Chrome users, Chrome OS users and Android users with sort of new and fancy phones. Unfortunately most paying users are actually using iOS for mobile. In theory if your product is successful you should rewrite in Native for iOS for best user experience, but in reality complex polymer applications work ONLY on most modern phones. For example equal by complexity and code size apps when written with Closure work perfectly on iOS 7 on iPhone 4S and iPad 2, but when written with Polymer the app is completely unusable on iPhone 4s and barely running on iPad 2. On iPhone 5 it works in parity with desktop Firefox for example (i.e. there are delays here and there and some things are broken but most of the app is fine). Now compare this to the Chrome browser on the oldest Nexus 7 (also called original Nexus 7). It works perfectly smooth! Nexus 4 - butter smooth, Nexus 5 and Chrome - again buttery smooth experience, all animations look exactly as they should be, all transitions complete nicely and in sync...

I am sure Polymer team wants to support all major browsers, it is simply the fact that they don't. So does not your application. And this means you can be in big trouble with your manager...

When you debug your application in Chrome everything makes sense, you see the shadow root, you see where elements got inserted and so on. Try the same in Safari debugger... or in Firefox.. what you see is very very different from what you expect. This is again related to the fact that there is no native shadow DOM support. Apart from that other things seem to work just fine. The problem I have with those is that I cannot figure out where the slowness comes from, initially I believed it was a rough code path - someone somewhere was making something that was not really needed. However test after test after test proved to be 'accumulation' problem - if I isolate a component and nest it deep deep into lots of other components it still works fine. But when I start adding siblings on all levels the slowness accumulates progressively and an app with only 3 levels of nested animated pages with 4-10 siblings in each level results in apps that run only in Chrome, crawl on any other browser on Desktop and kill performance on mobile safari and old PCs.... There are some 'offenders' that are worse than others, but one after another they bring their 'slow' and it all results in intolerable application.

Once again - I am NOT sure what is going on there (mainly because debug tools on most other browsers are really years behind what we have in Chrome), also another 'nice' reason is that when you attach iOS device to debug web page on a Mac it auto-magically becomes 20 times slower. I do not kid you - the model observing digest all of a sudden runs for 25-28 milliseconds and the touch events take 50 ms to be processed.... close the debugged window and MAGIC - you again have something that looks like an app and not like still images... this terrible experience proves to me that Apple is strictly inhibiting any and all web advances they could think of and wants you to use their insane languages (I am sorry but Objective C looks like someone killed a dragon and used the body parts to compose a language).

Part III: The ugly

The ugly part is short: the ugly part is the controversion this whole Polymer thing creates: on one hand the managers want things to come into existence fast - the faster the better, and love to talk about things like 'time to market' etc. On the other hand they really really want to be able to tap into the paying market of Apple store. 

And indeed developing with Polymer will make you 10 to 20 times faster (depending on what you have been doing before that, I have been doing Closure and Polymer gave me a lot of speed). It makes so many things easier taking care of many things for you: type hinting, data binding, resource loading (hello, HTML imports) and ready to use components that are beautiful and usable (paper-elements). 

However as the 'bad' part explains there is a price to be payed and it is not really developer's choice to make: once you know what to expect it is not really something you would go and fix even if you are a 'javascript ninja' - it is just the way it works, it utilizes very new things that are simply not there in most browsers. Even if you are a ninja, you could fix this or that, but the amount of work you have to do is much much more than if you have just used something that is known to work already. Polymer is being worked on all the time. But Apple is not showing any interest in developing for those new standards and we know iOS is away from this new goodness. 

Conclusion

If you are lucky enough to be developing a Chrome packaged app or an Android only app - consider yourself really lucky, because you can jump right on top of Polymer and ride it like a champ. You can do crazy things like declarative data processing (yes, you describe the data processing and filtering as nested html elements and it works!!!), ultra cool lively animations and transitions and you can write truly reusable, configurable components that you can reuse from project to project regardless of the used library and/or framework - something we have not been able to do - never, until now. Even with closure components you were still bound to closure tool-chain. With polymer you can include (one day only) polymer and do not care who uses what else to construct custom elements that you might use.

If you are not one of the lucky you better watch out: Polymer is really fast to develop with and very gratifying up until the moment you start to test compatibility: forget about IE < 10, forget about complex apps on older phones, forget about really clean fluid animations on anything else than Chrome... at least for now. Polymer is said to be early preview and alpha and not ready for production. If you are like me, if you want to developer faster and more pleasantly Polymer might lure you in, but then you have to pay the price: days, even weeks after your application development is ready and stable you might still be fighting with Mobile Safari and Firefox and IE... and even if you are not actually fighting bugs in your own code you are still days away from releasing.. you have been warned!

The Dart language

Introduction

I have been using JavaScript for many years now as my primary language and most of the time I have been developing front-end rich applications. Not only applications with lots of data, but also with robust custom widgets/elements that are not native to the web (like scalable design views, video editor times lines etc).

When I first started writing those complex apps it was very very hard to compose such an app and make it run on all browsers. Now days when I have to quick fix something written years ago I see how custom objects have been sprinkled in IE only code and other terrible things.

Then came the libraries. jQuery, Mootools etc. They made it a bit easier.

And then there were the frameworks. Without them a lot of what is possible today would not have existed at all! I will not iterate over the problems of incompatible implementations etc, but the thing is even the best of the best of those frameworks and libraries had issues on their own and most importantly the developer needed to choose one and stick with it for the whole project basically, changing it requires learning a whole new world of class implementation and strategies for building an app.

The last thing to consider was the lack of comprehensive and useful tolling for the language as a whole and in particular for those enormous libraries/frameworks.

Alternative solutions

Meanwhile some of the shortcoming of the language (JavaScript) have been addressed by different organizations differently for a long time now (think GWT, Closure tools,  TypeScript etc). Some are targeted to the JavaScript community, some appeal to the developers community as a whole and try to attract interest from developers not traditionally writing for the web.

One of the earliest was GWT. It was targeted at Java developers who want to write web applications, but are not versed in HTML and JavaScript. Google used it internally and many companies outside of Google are also using it to build data driven apps. However the built-in widgets and utilities tend to be seen as obsolete and not attractive enough for the new markets and the new generation of users that are spoiled by the Apple inspired designs. The promise there is that you can write in the language you already know and you get for free the type safety and the rich tooling typically existing for type safe languages and for Java in particular. On top of that the tools were able to produce optimized code tailored for each target platform. GWT is still an excellent choice today as it continue to evolve and addresses some of the shortcomings raised by the extensive use of the tools and revolves around the evolution of the web as a platform. Mobile is also a big word in the newest history of the project, so if you already know Java and maybe you wish you could target several platforms at once (see keynotes from GTW create conf) this might be the best choice for you.

Closure tools are also a Google conceived product, later on open sourced. It consists of an extensive JavaScript library, a compiler written in Java and a template language that can be compiler to run both on the server and on the client side. The compiler is used to optimize and minify the JavaScript code, supports tree shaking (meaning eliminates dead code paths assuming it is provided with the full code for your application) and does some neat tricks like using the comments in your code to infer types for an abstract type system. Assuming all of your code is sprinkled with the needed comments the whole of your project can be type safe, bringing the benefits of the previous project (GWT) to the JavaScript world. However this comes at a cost - all of the JavaScript in your application must obey a stricter subset of the JavaScript language, mainly the classical pattern for inheritance can only be used and no constructor addressing should be done. Other than that you still write in JavaScript and you get type checking, type inference, safety and because of those - tree shaking and safe advanced rewrite and minification. If you are starting a new project and you expect the code size to be large or you would like to try and see what you can do when you have type safety throughout of your application you can count on this project. Check out the wiki page as well as it links to some helpful third party widgets and libraries that are compatible and highly efficient.

TypeScript came only recently and is produced by Microsoft. It was also open-sources. The approach there is different, inspired by the new features yet to be released for the JavaScript language and mixes it with some optional type information, basically becoming a superset of the JavaScript language. It allows reuse of existing JS code (unlike Closure), however the support for tooling and type safety and inference is only available for Visual Studio on Windows, which limits the usability for the developer community. Unlike Microsoft, Google has always targeted all platforms when providing tools for the developers. Never the less TypeScript, being young has yet to be used in very large scale projects, but in the mean time it is successfully used by several not-so-small ones. If you are looking for ways to reuse your code or a popular library, like jQuery, but get good tooling and you are okay with using Windows, TypeScript might be jut for you.

Dart - batteries included

The latest project, trying to address some of the shortcoming of JavaScript is Dart. Unlike the above mentioned projects it is targeted at all developers regardless of their background. This is because Dart is an entirely new language, mixing features from several other languages and trying to make sense of the web platform.

The language itself is okay, its functional (see functions as a first class citizen), but also has classes, single inheritance, mirroring support, isolates, mixins and some very nice sugar syntax for common use cases. As whole it looks familiar for Java as well as for JavaScript developers, probably for other as well.

Dart VM is a virtual machine for the dart language and can run dart scripts natively. For now it is not available in any stock browser and this tend to be the future at least for non-Chrome browsers. However it has been proven by many project already that it i possible to compile to very high efficiency JavaScript from other languages, so I would not worry if Dart VM will ever be adopted in stock browsers as far as it produces efficient JavaScript.And that turns to be the case as of recently.

The type system in Dart is optional and is really not used in runtime, not in the Dart VM (the virtual machine that runs Dart programs natively) nor in the compiled JavaScript version. The type system is actually there for the developer and for the tools around the language. First of all it is used by the Dart editor which gives you very rich real time information about your code, intelligent code completion, intelligent re-factoring and problem resolution and helpful information. This speeds up my programming at least 3 times compared to the closure tools where I need to look up type information myself while writing the code and only later when I run the compiler I can see if I have a type error. Because the types are optional and because of the excellent type inference you can often omit the type annotations in your code and still get very useful information and help from the editor. As a bonus you also get very efficient JavaScript.

The structure of the language itself is crafted in such a way as to allow high expressive power without sacrificing the safety. Because classes are supported in the language itself the problem with different class implementation that exists in JavaScript land is basically non-existing here. You can be sure that your code is compatible with the rest of the ecosystem and you would never again need to choose inheritance implementation etc.

Because of the type system in the editor and the tools around the language tree shaking is possible and performed every time you deploy, which means that you deploy only the code that you are actually using regardless of the size of the libraries your project utilizes / links to. This puts the constant chase for the smaller code size in a library to its end. Very similar effect you can get with GWT and Closure but not with TypeScript. The later translates directly to JavaScript and will not exclude anything from the compile, so you still need to think how to rectify that after the compile. This is not to say that there are no other method to achieve this (AppCache, server caching, even localStorage and Desktop apps (for Chrome only)), but if you are on a team that likes to make updates and improvements often this might be challenging. On the other hand you get the minimum possible code size for free from your tools if you decide to go that way.

Another interesting option is the ability to run on the server side and while the language is targeted mainly at the front-end developers, it is not impossible even today to share code between the front end and the back end, just like with JavaScript and Java. This seems to be a mandatory feature as of lately.

On top of that Dart has its package management system, similar to npm for JavaScript. There are hundreds of packages there already, but just like with npm the quality varies. One of the nice things still is that the language itself makes the packages compatible with each other, which is a great relief, unlike with NPM where each author decides on the structure and API exposition  to use. With the time, just like with NPM the bad projects will die out and the good once will grow. And as mentioned early growth is not a a problem with Dart as everything not used is excluded from the builds.

So who will be appealed by the language?

For once I can easily see Closure tools guys switching to Dart. They are already disciplined enough to use type safe code and dream of a shorter syntax and more expressive power and the amazing tooling will be an unexpected bonus for them.

I do not see Java developers running toward Dart right away, but with the right packages they might be tempted as well.

There seem to be two types of JavaScript developers: the ninjas will probably not be impressed by the language neither the tools, no matter that arguing on the implementation of the Promises and how we should create our objects is only possible in only two cases: either you are so passionate about the language you tend to be obsessed with the details or you have too much time on your hand. So those "ninja"s will not be impressed at all. Those are also what I call "the low level engineers", the tweakers and the experimenters. We need them in order to move the platform forward and I would say they are doing a great job at that. However they can be of little use in a small company or in a start up as their obsession with the language itself and the detail is often very time consuming.

The rest of the JavaScript developers are the guys like me, who have learned the language to a great deal, but wish there was compatibility at least to some extent in the ecosystem. Those guys write applications, not libraries (thou many of them, me including have written at least one library or a small framework just to get a good grip of the language).For them application level support in the used tools might be something very useful and unexpected considering the state of such support or more precisely the lack of it currently.

There are some great examples out there demonstrating the power of the language - things only a real JS master can do are easy and natural in Dart! Take a look at this for example: extending the regular Array object to count the access to its items. Try to do the same in JavaScript! Operator overriding is cool!

If you have not yet - please go and check out the one hour tutorial. You will be surprised how easy to understand and natural this language flows. If you are coming from Closure tools I bet you can understand and finish the exercise in less than 10 minutes and understand everything crystal clear! If you are coming from TypeScript the same should happen! If you are a regular JavaScript user you might wonder why those types, but fear not - you can add them later!

Of course there is still much to be desired. For example for me it is still unclear with what to replace closure templates for example. I see the community pushing strongly toward polymer and/or angular. Angular for me is just a toy and is more of an obstacle when it comes to very complex highly interactive widgets (image editing, design instrumentation etc - widgets that do not naturally link to a model of a strict JSON representation) and this is indeed what I have been doing a lot lately. Polymer might be better suited because it can encapsulate model handling that is not necessarily observer based and instead, but it is poorly supported in non-Chrome browsers. Even the demos on the dart site are not running on Firefox. Also there are bugs in the Polymer JavaScript implementation (basically styling issues - see my post dedicated to polymer. If and when polymer stabilize it would be a great addition to the dart ecosystem but for now I would really like to build complex apps with it but based on secure and fast templates like the ones used in closure, however I cannot find it.

Regardless of the hiccups and the fact that it is still evolving the goodness it brings is so tempting that I just might use it to build a real app!

You should try it definitely! If nothing else you will at least have a real opinion on it!

A colleague of mine has tried it too early (before 1.0) and was very disappointed. As application developers we should know when to try out a new technology. Let the ninjas handle the demo and beta versions! We want security, stability and robustness. I believe Dart is capable of provided all those and more!

Disclaimer: I am a front-end developer and have been doing this for 8 years. I use mainly JavaScript and HTML/XML/CSS as complementary tools/languages. I have been using in the past several other languages: Python, PHP, C, I have a working knowledge of Bash, TLC and other tools and instruments from Unix/Linux. By no mean is my opinions the ones of my employers nor that of a community, those are only mine.

12 reasons why I still prefer Firefox for my daily browsing

I am a web developer. It is more precise to say that I am a front-end web developer. This means that I need developer console each and every day.

For years now Chrome's development tools have been much much better for me as a developer than what is available in Firefox. So I use Chrome (mostly) for development.

However I also have personal needs when browsing as well as professional, not related to coding. In this case I love what Firefox has to offer.

Here are   reasons why I prefer Firefox over Chrome for my browsing:

Unlimited tabs open without noticeable slow down. This is important for me, especially when I read my news feed, I tend to open all interesting articles and read them after I am done with the list. Often this means 30+ tabs.

Configurable tab opening behavior. Chrome was not able or not willing to implement that for years: I want my tabs to open in the background without me having to use the middle mouse button. Why? Well because most products (apps) use shortcuts there days and I love them. Even in Google Plus you can press "v" to open the linked article and in Firefox it goes to load in the background while in Chrome the browser switches to the newly opened tab and I have to wait and stare first at the blank page and after a while at the half rendered page and after that maybe read the article, but usually switch back to the original opener tab. There are plugins that try to handle that, but none of them works correctly.

Much faster start up. One thing Firefox learned to do is to load only the pinned tabs and the one that is focused when restoring a browsing session. This means that I can close my browser at any time and go back to it as it was without having to wait like 5 minutes for it to become responsive. On top of that even without many tabs Chrome starts much slower, on a few years old computer (core 2 duo with 4 gigs of ram) Chrome starts too slow (mainly because it tries to read so many things from the disk I think). Once it starts it is okay, but this means I have to keep it preloaded all the time for it to be as responsive on start up as Firefox. No thanks.

Omnibox completion. This one suck big time in Chrome. At the beginning Firefox used two inputs - one for the address (address bar) and one for the search (search bar). However for many years now one can just remove the search bar and use the address bar to search Google (or any other set as default search engine address). On top of that it uses your bookmarks, your history and your recent searches and it learns to be much more of help than what Chrome does. Chrome for example almost never uses my bookmarks to help my with the typing, it is limited to only 5 entries and usually most of them are Google suggestions. On top of that there is no easy way (panel or otherwise) to search your bookmarks quickly. Chrome has those "apps" installed that are just links, but they are not configurable. For example I use InoReader, but their 'app' icon uses http. I want to use https for the service, but even if I add it as a bookmark Chrome never completes it for me. I have to navigate my bookmarks and find it. Way to frustrating.

Pinned tabs. In Firefox you cannot accidentally close a pinned tab. In Chrome pinned tabs are not really pinned, they are just visually reduced to be as large as the faveicon.

Expose like functionality for sessions. Okay this is really interesting. With this one Firefox allows me to have several filled with tabs views into the same browser window. I had 3 and kept them there for months before I had the time to read all of them and the browser remembered them. In chrome I am forces to bookmark those and mark them as "read it later". But those should not really be bookmarks. Note that this cannot be simulated with several Chrome windows, because I cannot close all windows at once easily.

Often used web sites: Chrome and Firefox have the ability to display thumbnails of your most often visited web sites. What Firefox allows you to do on top of that is to pin your favorites and thus have quick access to the ones you think are most useful and not the ones you really visit most often. This is to say the tool is versatile and you can use it as you like, not as someone has decided for you.

Superior plugins. At this point I have only one in mind but it works much much much better in Firefox than anything close to functionality in Chrome - ScrapBook. In Firefox the extension uses nice side panel, has search and most importantly - saves your documents at configurable location. For example in your Dropbox folder. Chrome variants use indexedDB and cannot sync between several computer in no usable way. And this tool has proven to be so useful that I simply cannot forgo it.

Better support for themes. You can make Firefox look like Chrome. You cannot make Chrome look like Firefox.

You can force sync. In Firefox the sync button is exposed and you can force the sync. In Chrome if you make a change right before you close the browser it might not be populated to the server. This is especially bad in relation to the fact that a bookmark has to be used to mark a web page for later reading (see above).

Last tab closed behavior: In Firefox when you close a tab and it happen to be your last tab the browser does not exit, instead a new tab replaces it. This is also configurable. The problem is that I am just closing a page, I do not have to pay attention if it is the last one in the window. This is very irritating especially when combined with the slow "fresh" start of the Chrome (see above).

AdBlock(+): This almost never work as intended on Chrome. Maybe it is developers problem, not necessarily a browser problem, but still as an end user it irritates me.


If I think hard enough I can come up with several other reasons, but I think this suffice to say that I am a bit on the 'advanced' user side. Chrome appeals much more to those that do not rely so much on their browser to comfort their browsing for whole days/nights. I know people that use it very happily, do not have even a single bookmark and most often do not even know which browser they are using. This is all fine as well and I know Firefox is not for everyone, neither is Chrome

What I miss from Chrome when using Firefox?

As much as I love Firefox there are aspects of Chrome that I like and miss when using Firefox. A list follows that describes the most missed features.

Open as window app. Using the 'app' icon you can configure a URL to open in a new window as a separate app. It is especially useful for apps that do not use popup windows and are examples of the so called fat clients or rich apps: Gmail, InoReader, Youtube (especially now that it does not reload the page) etc. The window manager picks up the face icon as application icon and you have somewhat more real application on your desktop.

Task manager: Sometimes while browsing I notice that my fan goes on and on at the highest speed. Chrome allows me to see the CPU.Mem usage of each separate tab. Well, this is not entirely true, it shows me tabs grouped by processes, which is not the same as being per tab but never the less it allows me to narrow down the offender. On top of that it can give useful information from developer's point of view.

Offline apps with escalated privileges. I do not use one in particular that cannot be implemented well with IndexedDB and AppCache (that is to require access to hardware outside of the standard web APIs) but still it is good to know that it is there if you need it.

Chrome makes features available faster than Firefox. Such example is Speech synthesis and recognition, File API etc, things Firefox users have to wait for much longer.

Chrome has more horse power when it comes to raw JS performance: For most apps JS runs smooth on both browsers, but computation intensive apps tend to be more responsive in Chrome. One such example is Google spreadsheet. I have spreadsheets with thousands of records and tens of sheets and thousands of formulas and those run around 20% faster on Chrome. I am not sure if it is because off the browser or because they were fine tuned for Chrome but it is the fact.

This is again not all, but what comes at the top of my head, the features I miss the most on my day to day browsing.

I am really pro-Firefox for several ideological reasons as well, but I am not too optimistic for its future. They as a company have dedicated too much effort in Firefox OS, a project that is born dead in my eyes. On the other hand Google uses Chrome to make it possible to create apps that run fully offline on the desktop and on the mobile (packaged apps) and eventually this will make them a leader as a target platform for development while Firefox will remain marginal "proof of concept" platform with no adoption outside the geek community and is essentially waste of time and money. I know that Mozilla is non-profit, but making useful things for the users is IMO more productive than to make a very limited-use OS.