Is Google Dart Death ?

Update actually it's now an ECMA Standard after SDK 1.0 release

---

This year more than ever, the Chrome Dev Summit event has been full of freaking interesting talks ... except one ... you guess which one ...
Despite the sensationalism of the chosen title, and just to be clear this is about my personal thoughts on such language (or better the way it keeps being introduced) so the trophy for the less interesting talk today goes to the ... drumroll ... Dart one.
Please note that in this post I am not judging speakers ability to either give a talk or their amazing programming skills, I am judging the content and the message to all developers like me.

Update on day 2 there is a Dart interview that eventually tells us more about what Dart is and how it can make web development better. Now this is what I'd like to know/see/hear and thank for, way better than how it has been re-introduced on day one. Back to the post, this was day 1

Where Are Real Achievements ?

I honestly wasn't expecting to hear again all JavaScript problems we learned and we know. At release 1.0 of the Dart language, I was expecting a talk about all the amazing things that Dart can do these days or improved 'till now ... instead, the whole talk was something like:

Dart does not have undefined as JavaScript does ... how cool is that?
Dart has classes, with scriptish syntax, much better than JavaScript ... how cool is that?
Dart has no coercion (aka easy casting through explicit + or ==) ... how cool is that? (n.d. is it?)
Dart has operators overload ... how cool is that? (n.d. so Dart has an extra problem JavaScript hadn't ...)

So now that the everyone got how shitty looks JavaScript, let's go to how Dart works ...

Dart Desugars To JavaScript

So please cut all this crap and start respecting the language able to show all your features because I'm really fed up of all these battles against JavaScript, when once again this language has demonstrated, with all its undefined "problems" thanks gosh no real developer has anymore since 2004, to be very flexible for the modern Web, coming from 14 years ago ... do you get it?
It does not matter how cool is your new language if everything it does can be done as well with JavaScript in all platforms that do not have a native Dart VM ... so just Respect The JavaScirpt and get over it: Dart lost before even trying!

Even Google Seems To Know It

The last talk of today, probably the one with less audience being late in the afternoon (but there were still many developers in that room), was about bringing native performance to the browser through Google Native Client.
Bear in mind, we are talking about native, not yet another VM that won't be able to do the impressive work that Emscripten did and asm.js is doing as well, both based on JavaScript as the target (so go home Dart, you are late to the party!)
The worst part of this post is that I don't even know anything about Dart and how great this could be on my daily basis job because all I know is that JavaScript, the language that I know the most, has coercion and an apparently infamous undefined value I can forget through the undefined == null coercion (problem solved Dart)

Be Polite And Respect JS Or Leave The House

I know I've historically been not so keen about Dart, but waiting a year to see progresses, waiting the final 1.0 release, and hear what I've heard today and from people that worked on V8 too, really got me thinking people are still wondering what the hell is all this about.
When you go at Ruby, Python, even PHP conferences, you hear about how great is any of these programming languages.
You don't need to tell everyone that JavaScript in IE8 is crap, if you are attending a scala conference, you know what I mean?
Even more disturbing, You cannot logically blame the language that makes your language work cross platform ... it's like blaming Assembler for making programming possible ... are you out of your mind?
I think if this is all I can learn about Dart V1.0, specially with ES6 and new Class syntax behind the corner already possible with transpilers, I rather would like to know it's gone ... they tried, but Google Native Client was a better possibility (and I have thoughts about that too ... a talk full of "we were in a plugin era" that talks about yet another browser plugin, even if integrated as Flash has always been in Chrome).
These are fun times Google, I think you are doing great stuff since ever ... but Dart .. show its real muscles or stop wasting ultra skilled developers on something nobody wants and nobody needs, thank you!

The Untold Awful Truth Behind Retina

I put in place a very simple test page made out of circles

• first one is in svg without touching its ratio
• second one is a canvas with anti aliases, if any, and with same svg size multiplied its ratio
• third one, an image out of the previous canvas
• forth one is just same canvas without anti alias, if any

At the end, little one in the left corner, the current used ratio the moment you see the page, out of my display script logic.
Discarding basically second and third circle, here the untold story about retina.


Above is the difference within SVG and same image with 2X ratio on a Nexus 5.

2X Images Aren't Enough

The fact Apple keeps telling developers "just use 2X images and you gonna be OK" does not mean it's OK. The iPad mini retina, together with the iPod retina, and I expect all others, are actually trapped behind this mythologic 2X.
That's correct, the border of both svg and aliased canvas circles in iPad retina look the same. What's the issue in here? That in 326 pixels per inches the quality cannot be that 2X same of 264 ppi or just 220 in case of MBP so basically the display is capable of more, but the software (or trapped hardware?) won't show you any difference.
How can I tell? If you check circle borders you can tell it too!

Nexus 5 3X Isn't Enough

If you check the border of both svg and aliased canvas circles again but with your Nexus 5, you'll notice that while SVG is very sharp and perfectly aliased, the canvas 3X version is not.
In order to obtain a similar result you might want to scale up the ratio a little bit, let's say 4X ... you see? with this latest link the canvas is almost as sharp as the SVG. Still not a perfect ratio with 445 pixels per inches.

Those Bad Boys

So the honest Blackberry 10 with its 2.2437500953674316 (!) ratio looks actually sharper once forced at 2X with less artifacts visible on such good display.
Android 2.X on Samsung Galaxy Y with its 0.75 ratio looks smooth and antialiased enough.
The least considered device, at least in the US, aka Windows Phone that has a ratio of 1.5 since version 7 devices, looks very sharp! It is possible to compare with blurry circle perimeter forcing ratio at 1X ... that's how every logo and/or graphics is looking these days in Windows Phone: crap, because most likely you, your framework, or your CDN, is serving 1X images thinking that's enough for that screen. I tell you there is already a huge different, you should try it!

This Is MA MA MA MA MA MA MA MA Mad Mad Madness

The last project I am working on some spare time over the week end ended up with some code like this:

function createShortcutIcon(iconCreator) {
  for(var
    link1, link2,
    // used to generate icons at runtime
    canvas = document.createElement('canvas'),
    // where to place links
    fragment = document.createDocumentFragment(),
    sizes = [
      30, 57, 60, 72, 114, 128, 144, 173, 196
      // completely random , hopefully future proof, entries
      , 214, 256
      // btw, the whole sizes and 2X idea is so wrong ...
    ],
    i = 0; i < sizes.length; i++
  ) {
    link1 = document.createElement('link');
    link2 = document.createElement('link');
    link1.rel = 'shortcut icon';
    link2.rel = 'apple-touch-icon';
    link1.type = link2.type = 'image/png';
    link1.href = link2.href = iconCreator(
      canvas, sizes[i], '#E6A72A', '#286868'
    ).toDataURL();
    link1.setAttribute('sizes', link1.sizes = sizes[i] + 'x' + sizes[i]);
    link2.setAttribute('sizes', link1.sizes);
    fragment.appendChild(link1);
    fragment.appendChild(link2);
  }
  (document.head ||
   document.querySelector('head')
  ).appendChild(fragment);
}

Above non-sense creates every sharp icon for Home Screen saving in every bloody device I have to deal with, where it does not make sense to talk pixels when we cannot know dynamically/upfront how many we need.

The FirefoxOS Joke

There is a manifest validator, which is nice, that tells you that the icon supposed to be 60x60, or 90x90, but maybe 120x120 is good too, and if you really want to cover everything, provide 256x256, 128x128, 64x64, 32x32 and 16x16 ... are you mo$#^*@&^#&*^fu&#&*!^%$#&@ng kidding me?

An Epic Fail, IMHO

This part of moving the web forward, including the inline CSS data URI that unfortunately cannot scale as well with all sort of devices pixels ratio, unless you don't inline SVG directly, took a very weird direction where nobody knows anymroe what to do to make an image, an icon, looks good across all platforms.
Raster Images Are Death, IMHO, and we should provide maximum 3 sizes for these, as it is already for stremed video: from the very-high quality, to the medium, and low one for those that have to pay for bandwidth but holy crap there's no way even Akamai will ever provide the right ratio for every device so why on bloody earth we should write stuff like this?

<img srcset="
  320.jpg .89x 400w, 480.jpg 1.33x 400w, 640.jpg 1.78x 400w,
  480.jpg 1.04x 520w, 640.jpg 1.39x 520w, 960.jpg 2.09x 520w,
  640.jpg 1.1x 639w, 960.jpg 1.66x 639w, 1280 2.2x 639w,
  320.jpg 0.89x 800w, 480.jpg 1.33x 800w, 640.jpg 1.78x 800w,
  480.jpg 1.09x 959w, 640.jpg 1.45x 959w, 960.jpg 2.18x 959w,
  320.jpg 0.89x 1200w, 480.jpg 1.33x 1200w, 640.jpg 1.78x 1200w,
  480.jpg 1.09x 1440w, 640.jpg 1.45x 1440w, 960.jpg 2.18x 1440w,
  480.jpg 0.86x 1920w, 640.jpg 1.14x 1920w, 960.jpg 1.71x 1920w, 1280 2.29x 1920w,
  640.jpg 0.86x, 960.jpg 1.29x, 1280 1.71x, 1920 2.57x
">

This is not me speculating, Mr. Tab Atkins Jr wrote a post about this and he is one of those guys that are trying to make good standards for everybody future ... do you see the problem I am talking about now?

Solution

I wish I had a silver bullet for this, unfortunately nobody can tell hardware and screen developers that they should stick with few predefined resolutions: they are competing with each other to put as many pixels as they can in a smaller part to make it sharper ... and while somebody complained our eyes cannot even spot the difference, I have created the circle test that is showing to my eyes that circles are not so sharp and crisp yet, but I don't think the web will ever go far using raster images, no matter how optimized are these since these do not scale.
SVG or make it vectorial All The Things is my current mantra ... that does not require a new manifest for FirefoxOS per each new device with a better screen in the near future.

A Not So Geek Person On A Nexus 5

The first day it was announced, I've ordered a Nexus 5 due its value for money ratio, probably one of the best out there, its Android KitKat support, and on top of everything, due its Google Chrome first approach when it comes to mobile browsing, and as you know I do mobile web development since quite a while so that's something I should test/take care: thanks gosh the random WebKit stock browser era is ending!
Anyway ...

This Is Not About Me

Another person got this phone for another reason: to improve a forgotten Sony Ericsson Xperia Arc S on Android 4.0.4 experience, a phone so stupid it cannot even upgrade its own preinstalled apps thanks to its inability to use the external SD card as storage for preinstalled software such Google Maps, Google Play Store, Google Whatever. This is not about me, then not about somebody that knew what was going to buy, going to appreciate as update, going to use it at its best ... this is a post on behalf of the person that received this Nexus 5 phone, a person that I rather don't even mention because it does not matter: she is just a user, and not a geek one!

First Contact

Now, the very first reaction was something like:

OMG it's huge!

Well, that's actually a valid point. Phones are getting too big, imho. Phones should be phones, this trend where phones are getting closer to mini tablets ... I honestly never got it. I want to be able to put my phone in my pockes, any pockets, as I was very happy doing that when phones like this were the best option ever.

More on the first day, I've insisted to give it a chance, 'cause it's going to work, and it's going to be better, faster, easier, stronger ... and the whole Daft Punk repertory.
And so she did ...

Few More Days

Few concerns came up, such "where are my contacts?" or simpler "where are SMS?" or stuff like "why is my battery lasting 1/3 of the old phone?" and reasonable questions like these.
I mean, I have an answer for all these questions but why a normal user should be so disoriented? Battery a part, how can the old Android SMS icon disappear like that so that nobody would click it and re-learn that hangout is now the new SMS manager? And still ...
"I don't want Google to know all about my SMS".
Specially in these days where NSA story is under everybody nose and were common users keep getting scared and aware about security every day more, and I am lucky I just know all this stuff and somehow still manage to sleep during the night, remembering to never write my plans to conquer the world via web or mobile phone data, I didn't even feel the need to blame her or reply. I mean .... right? A single software knows everything I write and receive? That's scary! How can I even start explaining that is basically what happens since the beginning of the smart phone era and even before that it was basically possible/the same?
How to even start a conversation such: "Hey, that's just an aggregator app. You still send SMS when it's about SMS and Web or MMS when it's about those things, don't panic!"
I don't indeed, and keep observing the situation ... until today ...

The Straw That Broke The Camel's Back

I am just quoting here:

I start thinking I want my old phone back.
I have enough of Google in the middle of everything I do.
I had to quickly save a mobile phone number, this phone asked me so many things I threw it on the table and grabbed pen and paper to write this number down!
Moreover, I don't want to re-login to a gmail account for everything I do with my life!

I don't know what you think about this, but this is actually another valid point I give for granted. I know Google effort to simplify users life is great, but also there are limits where asking, and making something once an easy step more complicated, because of "features" somebody may not even desire, isn't exactly UX progress.
This happened to me too, and many times, where technology that supposes to make my life easier got so selfish that made impossible for me to get a result and, as result, I had to drop such technology.
An alarm that forgets to wake you up is pointless, you know what I mean ...
We already reached that regression where either your phone is on or your alarm will never wake you up, as it has been for all devices "before smart phones" generation ... but right now ...
A phone, which historically has an easy to access contact list, should never be in the middle and ask which email or gmail account to use to store a contact, it should do that eventually after the operation and batched somehow, to be non blocking for the user, but still clever for the next time.

Last On G+

To have access to Apple, Facebook, Linked In, and any other social network, you don't need a Gmail account. To have access to Google Plus you do need a Gmail Account. I mean, that's actually fair from Google perspective, but not so cheap or easy for people that use the same email since ever and are not planning to embrace Gmail any time soon.
That's how you could reach everyone on this planet, letting them use everyday tools and stuff they are used to, still offering great services as Google Plus is.
That was actually the latest, most disappointing complain I've heard, about this "all you can Google" phone that did not match the daily life of somebody outside "that circle".

As Summary

I still believe the Nexus 5 is the best Android phone I've personally ever seen and used, but I have quite a background about Android since version 1.5, and I believe we, in IT, should never forget that some people don't like to change a phone each year, some people don't like to change anything at all, but even more adventures prone people, might want to keep having simple tasks simple, not a charger with them all the time, and no need to buy clothes with bigger pockets, as well as being able to just save a bloody contact in few steps: now that's progress, right?

P.S. I am still quite happy with my Lumia 620, I don't think there's a phone out there that could make me happier right now, but this is another story I am planning to tell you soon.
Stay tuned ;-)

dumb.min

This is a needed explanation of a tweet of mine that has been mostly and instantly mistaken (just read through all comments):

this keeps bugging me: can we all please stop putting .min suffix when it comes to save bytes and use .max instead when size doesn't matter?

I've already posted about this a while ago but haven't seen much feedback/changes after that so here again trying to explain this matter only.
As spoiler, please don't take it personal or get offended by the abused dumb word, I am the first one that used and probably still use somewhere the .min suffix, aright?

Logically Speaking

So here the thing: we all use automations in order to create minified version of our files and if we don't we should. There are tons of easy to use tools out there, repositories such gitstrap that works with Makefile or grunt that could watch all files and keep building for us ... pick an option, create your own one, do whatever, and at the end create the build folder.

The dumb.min.js Output

Since we use automations, there's no reason on earth to provide to our users 4 extra bytes for a script, css, anything minified that is there to be served as fast as possible.
I mean ... the purpose of minification is to serve the minimum possible amount of bytes per each request, right? Where even headers and file names matter per every single network request, right?
Then .min is a name for developers that want to feel cool they are serving the minified version, throwing 4 extra bytes to every user, in every page, and for everything that uses such suffix conventions ... for who's supposed to be convenient?
The user? No! The bandwidth? No! The semantic? ...

dumb semantic

You now open any website that uses a CDN to load a common library. Let's choose jQuery, one of the most popular, right?
You go in the download page and there is no link to any CDN that does not end up with .min ... now ask yourself: who is that dumb that would ever serve the full, uncompressed, non gzipped/deflated version, of any CDN library? Develoeprs to debug? Good, they are 1% of the traffic of that website ... so is this how we do things? Penalizing the default use case in favor of dumb laziness?
What do you expect from a CDN in first place if not the best available and performant options to serve the file?

... and mootools-yui-compressed.js ...

When I've read this page I thought "this must be a joke".
Seriously, check all that Google CDN list. Actually, what does not contain .min is really not minified at all! There are developers out there serving Prototype 1.7 with comments and moreover, the gold medal for the best anti-pattern naming convention for a minified file goes to that mootools one. How about we put the date, and the list of all authors and the license name of both YUI and MooTools in there?</sarcasm>
140byt.es offers entire scripts in a tweet size, and we think naming something with 15 extra pointless-for-purpose chars as -yui-compressed is good for anyone out there?
Bear in mind this is not a real/concrete issue in using MooTools library itself, as explained later on, but a matter of logic that once applied everywhere, makes things look weird (aka: "something went terribly wrong at some point on the internet").
In this latter case, even automations could be improved and use -yc or something else if really needed (as if the tool used means different library behavior ... hopefully no, otherwise drop that tool!)

... plus min.map.js ...

If it was about having a convention able to tell the browser where to look for the file I would re-thinnk this ... but as you can see in Microsoft CDN all files need to have the equivalently named one with the map suffix so once again, who's gonna benefit from this dumb convention somebody created one day and nobody ever thought it wasn't that clever?

Quoting @craigpatik

...min.js, ...min.css, ...min.svg — one of those pieces has useful meaning; the other is redundant.

Not CDNs Fault

Absolutely not, it's entirely developers fault because their automation most likely will create those files with those names.
Still using jQuery as example, but many libraries are like this, the task to create distribution files is like:

distpaths = [
  "dist/jquery.js",
  "dist/jquery.min.map",
  "dist/jquery.min.js"
]

How utterly simple would be to have any of these variant instead ?

distpaths = [
  "dist/jquery.max.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

// or ...
distpaths = [
  "dist/jquery.source.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

// or ...
distpaths = [
  "dist/jquery.src.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

// or ...
distpaths = [
  "dist/jquery.yo-mama-can-build-scripts-too.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

What Will We Gain Doing So

So, it's not that suddenly anything will go twice as fast or any user will ever notice that, it's just a pure semantic, logic, sense sake and that feeling of "doing it right" that might show new comers on the web that we are not so silly that to serve less bytes we automatically put 4 extra on top just because ... no: we discussed about it, we thought about it, and we choose the best option available not going too far with extreme non-sense optimization as "dropping the whole name" would be, simply applying common sense and logic to the chosen pattern.

Otherwise, it's like thinking that to distribute an executable we need to use program.compiled.exe as name ... we don't, we know that's already the compiled version of an executable, same is for served files, in 2013 they should be by default optimized, and the source one, eventually available for developers purpose.

Once again, not a big deal. We can all sleep during the night keeping things in this way but every time you'll setup a build script again, maybe you'll drop that dumb repeated .min and do things logically in every single layer of your stack.

a bit of Math

Here I've quickly found some jQuery CDN related stats and I am pretty sure the amount of website using this library is more than "just 16000" but if we take that and multiply by 4, we have 64000 pointless extra bytes for jQuery only. Now, assuming every site will have some extra plugin or script, and some extra CSS, let's say a minimum of 4 total files, we'll have a minimum of 256000 pointless bytes on the air nobody needs, wants, uses. If we multiply these bytes for the extra space a name could take in any filesystem, the extra 4 bytes every single CDN request url will transport ... etc etc ... you see?

As conclusion, and even if 4 bytes aren't an issue in a singular case, can we all agree that if the whole internet uses .min in every (probably minified too) HTML file to refer external resources, there is an absurdly redundant amount of pointless data which aim is concretely unknown for everybody?
Thanks for your time and your possible, future, collaboration.