

37signals Basecamp Mobile HTML5 app for WebKit browsers - sstephenson
http://37signals.com/svn/posts/2761-launch-basecamp-mobile

======
sstephenson
Basecamp Mobile is written in CoffeeScript using our in-house Cinco mobile
framework, which ties together Backbone.js, Zepto, the Eco templating language
(<https://github.com/sstephenson/eco>), and Stitch
(<https://github.com/sstephenson/stitch>).

~~~
jashkenas
Considering that the rest of 'em are already open source, any current plans to
open source Cinco?

I'm presuming that the back-end for Basecamp Mobile is the current Basecamp
Rails app -- I'm curious about why you decided to use Stitch to package your
JS, instead of what Rails is using (probably Sprockets or Sprockets 2).

~~~
sstephenson
We'll definitely be open-sourcing Cinco in the coming months.

There are a couple of reasons we went with the Stitch approach. For one, we
found the CommonJS module system (as implemented by Node.js) to be an elegant
way to declare dependencies and share state between closures.

Second, our test suite runs headlessly in Node.js. By using Node's require
system, we're able to get useful information and correct filenames in
backtraces during development.

------
rjrodger
This is the way to go guys - HTML5 web apps will eventually kill native apps
anyway. Might take a few years, but local decisions, like yours, show the
dynamics behind that prediction.

~~~
anthonycerra
Completely agree. In addition to saving on development costs by eliminating
the need for specialized platform devs you also remove the app store Gods from
the equation.

There's really only 2 reasons to have a native app: 1) to take advantage of
hardware that you can't access otherwise and 2) screen real estate. The latter
reason being a poor one to solely base the decision on.

~~~
thechangelog
Not to mention an easy way to charge for a service.

------
jashkenas
This being one of the first large production CoffeeScript apps, did you run
into any unexpected trouble with using a language other than JavaScript?
(Naturally, I ask for selfish reasons...)

~~~
joshpeek
CoffeeScript has been a joy.

Because most of the code runs in the browser, we were able to use the WebKit
debugger. I never had any trouble matching up the compiled JS with the
original CS source.

------
csmuc
I was very bullish on mobile HTML5 apps a couple of months but that has
changed. As a user I really appreciate native apps on iOS and their overall
consistent UI and efficient use of the limited screen real estate.

Basecamp feels totally different compared to other native apps on the iPhone:
the back button looks weird, no fixed navigation bar and I'd expect to see the
typical tab bars (all things you currently can't really imitate with
HTML/CSS/JS).

It may not be a shit sandwich (as in
<http://daringfireball.net/2007/06/wwdc_2007_keynote> ) but still it's clearly
a trade-off driven by developmnt concerns. I totally understand that it's not
really feasable to develop native apps for all those mobile platforms out
there, but again it doesn't feel like a decision made from the user's
perspective.

------
srik1234
What compromises did you have to make by going for an HTML5 app instead of
native app? Notifications/Reminders?

~~~
sstephenson
For Basecamp, probably the biggest compromise is that you can't upload files
or photos from your browser. We're interested in exploring tools like PhoneGap
(<http://phonegap.com/>) for smoothing over the missing functionality.

~~~
JBiserkov
>you can't upload files or photos from your (mobile) browser

How come? Mobile browsers don't support it (for security reasons?) or it's
slow/eats up precious bandwidth? Or am I misreading you completely.

~~~
shubber
Mobile browsers don't support it. I've never been clear on the reasons, except
maybe that there's a tension with the carriers over airwave bandwidth.
Honestly: there's a Javascript interface in mobile Safari to access the
location sensors and, IIRC the accelerometer, but the camera is offlimits.

On the other hand, the HTML interface is a mime-multipart form and a file
upload - it's only convention that says "upload images only" - and the mobile
platforms are very particular about access to files on the device. iOS for
sure won't allow one app to touch the files of another.

------
anthonycerra
My favorite thing about this is Jason Fried's response to a troll in the
comments.

Troll - "Disappointment"

Jason - "Good morning to you as well."

I've been studying his responses to customer feedback, both positive and
negative, for a while now and have learned a lot. Just read his tweets for a
lesson in great customer service.

~~~
nomurrcy
I actually viewed this as kind of snarky.

I don't see why disappointment is an unacceptable response. I was kind of
dissapointed to see that this is where they were going for mobile apps.

~~~
anthonycerra
There was more to the negative comment. The very next sentence was this: _If
it’s not native on iOS, it’s not worth using._ There was nothing constructive
about his comment.

I also don't think customer service should be synonymous with ass kissing. I
appreciate knowing there's a person with a personality responding to my
inquiry instead of repeating canned phrases. You can be polite to a rude
customer without giving a phony 'sorry' or 'thank you'.

------
adamhowell
A question I haven't yet found a satisfactory answer to: should the mobile
version of a webapp like Basecamp have mobile marketing pages or just a login
form?

------
simonista
Could someone explain why something like eco makes sense in this context
instead of just using rails (ERB) templates. Presumably you have to query the
rails backend at some point to get the data. Are the templates in coffeescript
for cache-ability? Thanks!

~~~
joshpeek
All the eco templates are compiled and shipped along with the JS files. The
server backend only sends JSON to the app. Its much smaller and faster to
render, plus its cacheable on the client side. Its a huge win over RJS
templates.

~~~
simonista
Thanks. Any downside?

~~~
joshpeek
Theres some duplication between the server side (Ruby) and client side (JS)
models.

~~~
nickw
This is something I'd really like to see solved in client side frameworks like
this.

It seems to me that you could do something similar to how ActiveRecord queries
the database for a model's attributes - but instead expose a JSON service that
returns a models attributes and validations. But perhaps JS doesn't have the
dynamic / meta-programming capabilities to make this happen like Ruby does.

------
bonaldi
Pretty glad there are already great native apps out there. Lowest-common
denominator remains lowest-common denominator whether or not it's done for a
principle.

~~~
jasonfried
For those who would prefer a native app, here's a list:
<http://basecamphq.com/extras>

------
futuremint
I thought something like this might be coming after seeing the Chalkboard app.

I personally think that apps in this style are better long-term than native
apps for most business-y things.

------
dools
I'm so glad to see a heavy hitter like 37signals coming out in opposition to
"app madness".

As I've commented here before, I see the current native app trend as nothing
more than a replay of the browser wars of the early 2000's - folks developing
with IE specific features etc.

The natural tendency for programmers is to do _less_ work. This native app
bollocks is purely the result of commercial interests of device manufacturers:
if you make it harder to develop cross platform stuff then developers must
choose a platform. If developers must choose a plaform that means one platform
will have all the coolest stuff, driving sales of the device.

I own and love my Nokia e72 and was really pissed off when 37signals released
an iPhone app rather than creating a mobile web app.

The Nokia e72 browser probably won't cope with the HTML5ness of the Basecamp
offering but at least there's hope! I will never use an iPhone because I need
a qwerty keyboard (try typing find . -name "*.php" | xargs grep -il "function
someFunction" on your iphone keyboard - or try editing a file in vim via SSH
... yeah, didn't think so).

At least with this trend maybe my next phone will have access to mobile
Highrise goodness!

~~~
syncsynchalt
If you're going to use find | xargs, please use find -print0 | xargs -0 or I
will put a newline in a filename so that you rm something you didn't want to.

Also acceptable: find . -name '*.php' -exec grep -il "function someFunction"
{} \;

------
dickeytk
This is great. I've seen slight issues though. On my phone (iPhone 4) when I
was clicking around the todo lists, they responded very slowly to my taps and
I was able to highlight todo lists without actually going to them.

However, I love that you guys are doing this. I'm excited to see the cinco
framework as well. I have been looking for a mobile platform, I've used Sencha
a bit, but find it difficult to learn and bloated.

------
weixiyen
I think the correct decision is to make a native shell that holds an HTML5 app
for iPhone and Android. That does not require any additional developers to
accomplish and you can track/save the state locally.

That way it can be downloaded from the app store as that's what people are
used to anyways.

