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).
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.
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.
Their sense of timing is impeccable too given the current storm brewing around Apple's latest AppStore policy decisions on apps with content bought outside the store...
I keep thinking this myself however theres still alot of problems with the html5 frameworks including that while they can access some of the hardware its very limited. Also are you talking specificaly about things like jqm and sencha touch? Or are you also talking about webkit frameworks.
the beauty of jqtouch is that it doesn't pigeon hole you into any development techniques, so with a bit of careful planning your site will degrade well by just disabling the js and css. it's just html. while unsupported browsers may not get the best experience, they still get an experience (which is still more than you can say for native apps).
This is a good point. Not only is degrading an issue but theres so many phones with different screen sizes and whatnot and that must be considered to be coded in. I havent really looked at frameworks enough including jqtouch but its certainly something to consider if your app is intented for a larger public audience.
By the way is jqtouch still being developed. I understand the lead developer when to work for sencha. Which ive tried but couldnt get to work. I was using jquery mobile but had problems with it which considering its only an alpha is understable.
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.
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...)
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.
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.
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.
Ive been exploring phonegap appcelarator and rhomobile myself lately and have been settling more and more on rhomobile. Can you explain why you have been looking at phonegap instead? Im wondering if theres something about it i missed. That you.
A nice work around to the uploading files issue would be to piggyback your existing email solution. So after posting a message you could show a little "Attach files" link which would show an email address to mail the files to (or open a mail client if that makes more sense).
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.
Obviously at this point it is best used for applications that essentially provide a mobile interface to a web application that utilizes some of the advancements in UI design gained from the iPhone and Android generation of smartphones. Eventually I see the full gamut of APIs for things like camera, notifications, Geo tracking, etc. It will get more responsive too as people learn to use local storage to cache the app.
Well this is why people look at frameworks such as phonegap and appcelarator and rhomobile. They theretically give you the best of both worlds. Theres issues with them though including a lack of documentation for each of them. But as you say if you dont need to access the underlying hardware then theres almost no reason to not use html5.
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.
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'.
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?
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!
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.
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.
Why do they use js for the client side logic? Cant they use ruby? I know phonegap appelarator and rhomobile allow for this with rhomobile but all ruby. As im playing around with mobile applicaitons more im finding managing the javascript to be somewhat of a headache. So ive been wondering if theres ways to do with with other languages.
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.
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!
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.
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.
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.
