He argues that while the tools exist (via media queries and min-device-pixel-ratio and it’s JavaScript friend) to deal with various DPI screens such as the iPhone 4+ retina display, it is too easy to make mistakes, and this is something that you should be doing time and time again, and thus it would be nice to have a dedicated syntax (such as this:)

selector {
  background: image-set(url(foo-lowres.png) 1x,
                        url(foo-highres.png) 2x) center;
}

I agree that life is too error prone, and have seen annoying bugs in browsers. The one that always surprises me is the extra download of CSS.

Saw you have separate style sheets like this:

<link rel="stylesheet" type="text/css" href="retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)">
<link rel="stylesheet" type="text/css" href="regular.css" media="screen">

Load that up in your browser and use the tools to see what the browser has downloaded, and you will probably see that both CSS files were downloaded. That could make sense if the media query was tied to the size of the browser (as that can change) but is your desktop browser suddenly going to double its DPI?

The other issue that I have with the media query solution is that it is easy to “miss” an image or two.

Now, with the proliferation of tools such as stylus, SASS, less and friends, you can work around the issues now. We wrap our images as image-element('images/someimage.png') and our tools make sure the background-size is set and the right image is referenced in our foo@2x.css.

These days we have new MVC rich frontend JS (and CoffeeScript) frameworks and node frameworks.

Two very contrasting and interesting frameworks were just launched:

Tower.js sits on top of node to deliver an opinionated stack for client and server:

• MongoDB (database)
• Redis (background jobs)
• CoffeeScript
• Stylus
• Jasmine (tests)
• jQuery

Includes a database-agnostic ORM with browser (memory) and MongoDB support, modeled after ActiveRecord and Mongoid for Ruby. Includes a controller architecture that works the same on both the client and server, modeled after Rails. The routing API is pretty much exactly like Rails 3′s. Templates work on client and server as well (and you can swap in any template engine no problem). Includes asset pipeline that works just like Rails 3′s – minifies and gzips assets with an md5-hashed name for optimal browser caching, only if you so desire. And it includes a watcher that automatically injects javascripts and stylesheets into the browser as you develop. It solves a lot of our problems, hope it solves yours too.

Think “Rails” in the new world. One of the biggest points of Rails was ActiveRecord, and Tower has a rich modeling layer in Tower.Model.

Tako is to Sinatra as Tower is to Rails (in a crude way). It is a very functional and simple way to create an “application” and add routes that map to static files or JSON or HTML… and Socket.IO works out of the box.

As we saw the modern mobile Web (the “there is only one Web” version vs. the WAP one) spring to life, we had smiles on our faces as we whipped up some -webkit-* and saw it work on our new iOS devices. Then we saw more devices come into the mix, and Android grew first to be a platform that you had to think about ([insert Opera mobile... big... blah blah]).

Fast forward to today and we have the following looming over us:

• A ton of devices coming onto the market quickly
• The devices are not coming to market with the latest OS/WebKit versions
• The devices are not updating quickly
• The WebKit builds are often quite bad!

This came to light again when a project I am working on was able to easily core dump the Android browser on a few devices (such as HTC Evo 4G Shift … but not the other HTC Evo 4Gs mind!).

02-24 16:35:07.589 I/DEBUG   ( 1253): pid: 6315, tid: 6329  >>> com.android.browser <<<
02-24 16:35:07.589 I/DEBUG   ( 1253): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000011
02-24 16:35:07.589 I/DEBUG   ( 1253):  r0 00000008  r1 49329435  r2 45e5d374  r3 47055720
02-24 16:35:07.589 I/DEBUG   ( 1253):  d30 0000000000000000  d31 3ff0000000000000
02-24 16:35:07.589 I/DEBUG   ( 1253):  scr 20000013
02-24 16:35:07.589 I/DEBUG   ( 1253):
02-24 16:35:07.639 I/DEBUG   ( 1253):          #00  pc 47055778
02-24 16:35:07.639 I/DEBUG   ( 1253):          #01  lr 4704e724
02-24 16:35:07.639 I/DEBUG   ( 1253):
02-24 16:35:07.639 I/DEBUG   ( 1253): code around pc:
02-24 16:35:07.639 I/DEBUG   ( 1253): 47055758 e1a0d00b e8bd4800 e28dd008 e12fff1e
02-24 16:35:07.639 I/DEBUG   ( 1253):
02-24 16:35:07.639 I/DEBUG   ( 1253): code around lr:
02-24 16:35:07.639 I/DEBUG   ( 1253): 4704e704 e5987017 e597000b e59b100c e52d0004
02-24 16:35:07.639 I/DEBUG   ( 1253):
02-24 16:35:07.639 I/DEBUG   ( 1253): stack:
02-24 16:35:07.639 I/DEBUG   ( 1253):     45edd8cc  00000002
02-24 16:35:07.639 I/DEBUG   ( 1253):     45edd8d0  a861c3b9  /system/lib/libwebcore.so

I shouldn’t be able to dump your core. From looking online I was shocked at the number of people complaining about some of these devices. To them, their browser crashes all the darn time. Why not use Chrome for Android I hear you ask… well that is only available for Ice Cream Sandwich, and hardly anyone has been able to upgrade to that. What about Dolphin HD? Or Firefox…. sure, but how many users are going to think to update their browser on their mobile like that? Not many…. unless they get used to awful default browsers as we did on Windows.

As I went through the myriad of devices to test things, I started to cry as I thought about the amount of effort it would take to get massively broad coverage that doesn’t crash some users. This is why being able to target an engine would be nice.

It is also why efforts such as the latest push for decent mobile Web standards and support are important. It isn’t just about passing the tests, but how well we pass them.

Brendan Eich talked about the tough task of pushing 60fps at all times on a mobile device. I am glad that Mozilla is pushing for this and doing pretty well I might add with their Boot 2 Gecko platform…. which gives you view source for your OS.

I hope that we can all turn this around and get away from the hell that is debugging for all of these platforms…. but can we?

Why do a simple line dance when you can have fun with a Morris dance!

We have seen a lot of graphing packages for the Web over the years. We have simple graphs and gRaphael, and then super interactive and rich High Charts.

Sometimes though you want a simple and clean line chart, and Morris.js certainly does that.

As most good libraries do, it was born from a real project. Olly Smith extracted the work from the charts that you often see on How Many Left.

A big cleanup is at the core of it all…. the main access point, which becomes the simple connect() and returns an object that you can then use to setup for both http and https land:

var connect = require('connect')
  , http = require('http')
  , https = require('https');

var app = connect()
  .use(connect.logger('dev'))
  .use(connect.static('public'))
  .use(function(req, res){
    res.end('hello world\n');
  })

http.createServer(app).listen(80);
https.createServer(tlsOptions, app).listen(443);

With a new Connect, we can now expect a new Express, and TJ promises 3.0 coming soon!

I was talking to someone who told me something I had heard before. If you get lunch at the Square offices, you will get a receipt for your food and it will be Square. Cute, right? You hear about the role that design has at Square (they surround the execs and are incredibly empowered). I love their work too, clean and beautiful both. The receipt though is a small example of how “keeping it square” gets rid of the form. It means that you only have the total and not the items… as that doesn’t scale to a square receipt printer.

Ben found another example, in the Apple iOS calculator itself. If you are doing a large calculation you will find that in the normal portrait mode you max out. The digits don’t get smaller to allow you to type more…. you are literally stopped here:

If you want to add more, sneak over to landscape mode:

Then, rotate back, and you see the hideous obtuse number instead of all of the digits scaled down:

Small things, and maybe it wasn’t a design but rather an engineer who just put a hard stop on the length…. but it more fun to blame design.

Some people love the minimalism, and others think claim that the minimalism doesn’t equate to simple, and the fact that you need to watch a “how to” when you launch the app to know what to do says something, but it is great to see this type of experimentation.

But, hold on a minute. The modern Web has todo lists as our “hello world”! Why don’t we put a “clear” UI on top of one of the many todo list backends?

Well, it happened… at least the UI part of it did, with a Web based clear demo by Evan You. All is done with some nice CSS applied via our friend Zepto.

He has just posted about client side MVC frameworks where he takes a part Gordon Hempton’s comparison and instead zeros in on the markup:

His rating criteria were different to mine. One that really sticks out is that I like the logic not forcing the template HTML to migrate to <script> tags. Depending on the sophistication of the app, I like to be able to see the app in a browser or DreamWeaver when the framework is not running. It gives me a way of gauging the composition of the app. It appeals to a WYSIWYG leaning that I have. I like my UI frameworks to be built for designability if you like.

I remember thinking this way back in the day. One reason that I liked Tapestry was its use of bolting onto HTML instead of some zany XML nonsense, or some inline JSP-monstrosity.

The game has changed though. I love the power of “Shift-Reload” for Web development. No compile step FTW and all that jazz. However, we are finally at a point where I think that we can get that power without leaving everything else.

I favor stylus over CSS. I understand why people want to use CoffeeScript vs. just JS (I use both depending on the situation). There are enough tools out there that I have a deploy step. However, this doesn’t mean that shift-reload is lost… and in fact, we can have things even better.

I make changes to my code, and when I save the file it goes through the build steps and updates the browser with any changes that it needs. No need to reload the app. Awesome.

Paul Irish showed of some new Chrome Dev Tools that I hadn’t seen yet. Chrome Canary has them to play with now… including being able to make changes to the computed CSS and have those changes sent back to the original files. Now I just dream of the tools grokking stylus and I am happy as larry. Oh, and then mapping any DOM changes back to my handlebars templates ;)

Dreamweaver? Come on Paul….. time for us to move on!

One of the key pieces of technologies is that of the Operational Transform, and Joseph decided that the world needed an open source (MIT) OT library that can be used inside the browser, or over in server land via node.

Enter ShareJS, and this is all it takes to create the basis of Etherpad (and a version that doesn’t require a massive JVM heap ;)

sharejs.open('blag', 'text', function(error, doc) {
  var elem = document.getElementById('pad');
  doc.attach_textarea(elem);
});

How it works

As you edit the text area at the top of this page, ShareJS generates operations. Operations are like mini commits to the document. (Eg, insert:’hi’, position:50.)

Like subversion, the server has a version number. If multiple users submit an operation at the same version, one of the edits is applied directly and the other user’s edit is automatically transformed by the server and then applied. Transforming is a bit like a git rebase operation.

In your browser, your edits are visible immediately. Edits from other people get transformed on top of yours. Unlike normal SCM systems, the algorithm is very careful to make sure that everyone ends up with the same document, no matter what order the operations are actually applied in. This allows the whole update & commit stuff to happen completely automatically, in realtime. There are no conflict markers or any of that jazz.

This is a great addition to the commons. Awesome.

I also enjoyed hearing Kevin Dangoor (who worked with Ben and I back in the day) give the walk through:

And we also get the fun fancy tilt-ness, full screen API, and add-ons are now compatible by default, which is a big process change.