News roundup: Chrome for Android, ASCII Fluid Dynamics, Node.js: doing life wrong?
(no podcast this week – Boo! Check back next week)
Chrome for Android
As always, the Sencha folks have released an excellent overview of the features in their HTML5 Scorecard:
Compared to the stock Android 4 browser, there is a substantial number of additional HTML5 features: Web Workers, Web Sockets, HTML5 Input Types, overflow: scroll, requestAnimationFrame and more. That’s not to say that Chrome for Android has absolutely everything. As detected by the other handy testing site for HTML5, many newer features are absent, notably Shared Workers and WebGL. The video codec cold war also continues: Ogg Theora and Ogg Vorbis support is still not there — which is not a surprise.
Another very nice tool in Chrome for Android is Remote Debugging straight out of the box. This lets you use your Web Inspector on desktop Chrome to peer into the inner workings of the browser as it’s running on your phone.
Also check out Tony Gentilcore’s overview on his blog.
ASCII Fluid Dynamics fanciness
Designer and developer Nick Kwiatek’s website has been making the rounds because of a particularly cool (and fast!) ASCII art and fluid dynamics mashup. Go check out the site and try waving your cursor around. And yes, that means it sadly doesn’t work on mobile.
A quick peek underneath shows that Nick uses a fluid dynamics library built by Oliver Hunt. Nick then builds on top of it and adds a neat ASCII display out of it. Pretty cool, and also a good way to get your website/portfolio passed around once it goes viral.
“If you’re using Node.js, you’re doing life wrong”
This rant against Node.js has been floating around a bit this week, probably in part due to its troll-like sensationalist title. I could swear I saw this exact same article floating around a few months back, making the same arguments, but I suppose that’s just what you call a case of déjà vu. Aha, I remember what I’m thinking of: Node.js is Cancer (Ted Dziuba) – another purposefully sensationalist title.
In any case, it’s good to see counterarguments to Node.js being the general savior of all things backend. This is a short article, but there are several points to the argument: 1) V8 doesn’t belong on the server, 2) callbacks are hard to debug, and 3) the argument that asynchronous/nonblocking doesn’t necessarily mean scalable, or even fast.
Certainly the case can be made that V8 on the server side isn’t necessarily a good combination, as that’s not where it was originally intended to be. There will be bugs.
As for the argument against callback spaghetti: that’s certainly an issue, especially for those coming from classical language backgrounds. But that’s not to say there aren’t good tools or best practices to ease this burden – Node offers a (partial?) stack trace, and there is also a recommended pattern of naming what would usually be anonymous functions, so you can track down exactly where your code is blowing up.
As for the argument about nonblocking not necessarily meaning scalable: this is certainly true. Node.js can handle many connections on a single CPU, but that doesn’t mean a single CPU is going to be scalable for everyone’s needs. Folks are already learning how to remedy that obviously (I’m reminded of Matthew Eernisse’s talk from NodeConf 2011).
Probably the best counterargument to the article comes from actual usage at scale by large companies. If Node.js is so doomed to fail, it seems like it wouldn’t have been adopted and successfully used by these companies.
Already there’s some excellent entries, including this canvas rose by Román Cortés, with a blog post detailing how he did it. You may remember Román as the guy who made the awesome 3D canvas Christmas tree for the last JS1K.
Modernizr 2.5 has been released
(audio) Nonbreakingspace (NBSP) is a new podcast worth checking out. Currently there’s shows up with interviews with Paul Irish and Ethan Marcotte
BackboneConf 2012 (May 30-31, Boston, MA, USA)