The points raised are good, but I think web vs. native is a false dichotomy to be honest. It is quite possible for both to co-exist. The problem I see here is t

The points raised are good, but I think web vs. native is a false dichotomy to be honest. It is quite possible for both to co-exist. The problem I see here is that, by losing the shackles of backwards compatibility, native vendors are able to move much more quickly and that upsets developers in much the same way kids get upset when their sibling gets a shiny new toy. The pragmatic kid will try to find ways of sharing the toy, or get one of their own, but the stubborn kid will convince the others that their toy is batter, faster, smarter, stronger, and all of the things. The analogy breaks down a bit, but I hope my point gets across. The web, for all its warts, is a wonderfully resilient system. It can break any which way and it'll still probably mostly work. Most other systems simply don't work that way, because it's damn difficult to build such systems. By working within the constraints of the web, you're almost forced into it. What we can do to help developers better leverage the web, regardless of whether their UI is native or HTML, is to not be religious about the things that don't really matter – which I think is what James is trying to really say. His points are clear and good, but the underlying (and in some parts quite explicit) message is one of: let's not be kids. Our toys are sometimes broken (DOM, CSS layouts, single thread execution models) and we should consider changing them for better models or even new ones, that aren't so broken. But we have to stop the in-fighting, zealotry won't get us anywhere. --- It should also be noted that James' post while talking about the web is actually more about rendering than anything. There is so much more to the web, architectural principles that transcend platforms – such as hypermedia, stateless message transfer, metadata. Let's not pretend rendering is the end-all be-all that the web has to offer.