8 comments

[ 3.4 ms ] story [ 31.8 ms ] thread
Perhaps it'll soon be Joe Hewitt.
That's something I would definitely bet on (likely).
Loren Brichter seems to be an iOS app developer?
Loren Brichter's company, atebits, created both Tweetie for Mac and Tweetie for iOS, until they were acquired by Twitter.
Yes. Brichter wrote Tweetie, which became the official Twitter client for iOS and Mac. With the iOS version he invented the intuitive and widely copied "pull to update" mechanism.
Blame IE6.

Web developers spend an inordinate amount of time doing cross-platform testing, and they don't use the best technology possible, because they will need to think about how it degrades.

Also, Loren, amazing as he is, didn't put together his backend. That took tens of engineers, millions of dollars, and a lot of time.

Because you have to deal with multiple browsers, some of which are still in the stone age. Because you have to be mindful of loading times. Because you don't have access to the system's full processing power, just what the browser gives you. Because you don't get pixel-perfect control.
For CRUD and other common business apps I think you can be more productive developing web apps than you can be developing native apps.

It happened without people being conscious of it, and enterprise 'architects' are always trying to undo it, but the standard model webapp that has a stateless front end that keeps all persistent information in a database has a number of advantages over the 'tangle of pointers' architecture that native apps have. 'tangle of pointers' applications inevitable have failures of memory management that, like cancer, will take the application down if it runs long enough. Even if you don't think about it, webapps force you to have an engineered application state.

There certainly isn't anything like Visual Basic for the web but Ruby on Rails and all of the modern frameworks that imitate it make it easy to pound CRUD apps out fast.

If you want to do something that doesn't fit into the CRUD model, if you feel like you need a fancy interface, or if you do AJAX for the sake of AJAX, then you might be more productive writing native apps.

AJAX for AJAX sake is a particularly serious web antipattern. I must admit I take delight when my competitors develop AJAX-heavy web sites that are like Romulan Cloaking Devices so far as Google is concerned. I get free traffic from search engines and they get nothing... Even though they're smart people who've worked even harder than I have.

To be fair, there are answers to the AJAX 'complexity barrier' that people run into because of the difficulty of choreographing asynchronous communications. Unfortunately nobody has written much about them because those of us who could are either busy doing it or have reached the conclusion that front-end development is lame.