515 karma · joined March 21, 2012
Proud Dad, Londoner.
https://www.moystard.com
[ my public key: https://keybase.io/moystard; my proof: https://keybase.io/moystard/sigs/LWyuLFYEKFo90vBjYIh9couQkb3-ZH0QCROfX-0Fqew ]
We just have to accept that developers expect a lot of their environment, more than traditional users want, and more than what should be available by default in an OS. I am okay with installing plugins/tools/etc. to make me more productive.
I have done the move a few weeks back, and I don't regret my decision. The toolbar and my add-ons located there still work very well, also the new menu gives a quick access to useful features.
For the rest of the users, there are three cases:
- the user has accessed the application in the past (or any other webpage that uses the cdn): a cached version of the library is served by her browser. - the user has never accessed the page, the cdn is unavailable:
* either the Internet connection has failed, and our application won't be available anyway * the cdn is indeed down, the user has to wait for the timeout before her browser fetches the local fallback.
The third case sounds extremely rare (look at the statistics of major cdns out there, they often have better uptime and response time than your own servers). And the advantages provided by the first case do more than compensate in my opinion.
For the large libraries we use that are hosted on a cdn, with a local fallback, we use the :empty value for the optimiser and they are exclude from our modules.
If my server is not available, my web application will ultimately fail anyway.
I regularly submit new libraries and update the current ones through their Github repository.
The multiple files per request is nice however, but contributing to cdnjs might have been a better way of proposing it.
Regarding the fact that it might not be what's written on the box, I cannot agree more, you have to trust the shop on this one.
Using the r.js optimiser, we are able to create several modules for our SPA that include logic and templates, and load them at runtime only when required. By default, we load the most used bits of our application, and load the rest when the user accesses the more rarely used views.
Both were beautifully designed phones, with a unique and powerful operating system: swipe-based interaction, social feed screen, multitask, beautiful applications, good development environment (Qt).. This was the direction Nokia should have gone toward..
Edit: typos.
When matchbook will become a reality (ie. more editors will join the program, and more recents books will be added), I will happily use it.