Code generators all the way down: Why the Web sucks for Apps

Code generators all the way down: Why the Web sucks for Apps

Posted by: on Apr 16, 2012 | 8 Comments

You may have read my previous posts (here, here and here) on why, at a very fundamental level, I think the open web is a terrible way to make applications.

The web is doomed. Native will rule. I’m not alone.

Posted by: on Sep 27, 2011 | 5 Comments

A great piece by Joe Hewitt, who writes far better than I. This is pure killer:

The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.

As those of you who read my previous post on the possibility native could eclipse web on the desktop will know, I could not agree more. It’s not something I want, but I believe it may be inevitable. Even if Joe’s mooted guardians/CEOs of “the web” materialised, there’s no guarantee they would produce something compelling enough for the average user to use in preference to native apps.

Joe’s piece is bang on, in that the web geeks of the world are in complete denial of this and the dead weight of design-by-committee that will forever drag the core web technologies down.

Also ties into a tweet that I saw today:

@hnshah: “As far as the customer is concerned, the interface is the product.” Jef Raskin

There are a couple of ways to interpret this, but mine is “customers don’t give a shit how you implemented this or what your constraints are”.

What they see, feel and experience in front of them is what they care about.

Web devs who deny this is the case are just sticking with what they know, and companies sticking to web development are doing this purely for cost reasons that make not one jot of difference to the customer. Seriously, who wants to learn Objective-C, code Android, or Windows or OS X when they can already do HTML + JS? You can see the logic – it’s “cross platform”. It is however self-interest, and this does not drive the software market. The customer does, and the customer is rarely happy in the long term with lowest-common-denominator UX and functionality.

The web offers no gain for the customer whatsoever vs native. The converse is true for native vs web.

Yes I make a living from making web app stuff. For now at least.

Native will beat web apps on desktop too

Posted by: on Jul 27, 2011 | 14 Comments

It’s OK, I have two sets of flameproof clothing on.

Further to my contribution to the everlasting mobile web apps vs native debate I was discussing these issues again with good friend Richard (who is truly called a platform ninja), and again cropped up the “why is a tablet different from a desktop then? why is native better for tablets and not desktop?” question.

Functional testing in Grails just got a bit sexier

Posted by: on Jan 8, 2009 | 24 Comments

Ok so here’s the 1.0 release in the spirit of “don’t worry be crappy” (can’t use that phrase enough these days) of a new functional testing plugin for Grails.

Actually its far from crappy already.

I have developed this partly as part of my work for my generous client Historic Futures Ltd. who agreed to open source this.

I plan to continue improving and maintaining it personally. It’s surely a bit rough around the edges but the benefits should be pretty obvious to those who use it.

So what are you waiting for? Run:

grails install-plugin functional-test

See the documentation

…but in a nutshell it is HTTP testing with HtmlUnit under the hood but the rest is pure groovy smarts, leveraging standard JUnit.


import functionaltestplugin.*
class TwitterTests extends FunctionalTestCase {
  void testSearch() {

    click "Search"

    assertStatus 200
    assertContentContains "search"

    form('searchForm') {
      q = "#grails"
      click "Search"

    assertStatus 200
    assertContentContains "#grails"

What’s special about this?

  1. Simplicity and “elasticity” by default = less fragile functional tests as a result
  2. Simple compact DSL/methods to learn – it tries to “do the right thing”. Let’s face it writing tests is really boring.
  3. Ability to get/post directly without browsing to a page first. eg REST testing
  4. No .properties configs

…and one more thing URL stacktrace. When a test fails the report includes a stack of the URLs at the point of failure. The xxx-out.txt file contains request parameters+headers, content received etc. This feature will be expanded in future to allow a proper request/response chain autopsy.

Caveats – things I definitely want to sort out pronto:

  • currently test output is a bit ropey, I would like to do much nicer stuff with custom output xml and rendering
  • no simple way to set post body
  • no simple way to parse out json/xml responses yet

All this and more will come, with your support! Contribs also welcome!