

New Rails-like Framework from 37signals for HTML5 Mobile Apps - abraham
http://thinkvitamin.com/mobile/new-rails-like-framework-from-37signals-for-html5-mobile-apps/

======
sstephenson
Hey folks, there's nothing to see here right now. We spent three weeks
experimenting with some new tech to see what we could build, and ended up with
something that looks a bit like Rails, but entirely client-side and written in
CoffeeScript.

The project driving the framework—an HTML5 mobile UI for Basecamp—has been on
hold for about a month now, and we're still a ways off from having anything to
show. It just isn't a priority for us right now. When (or if) we do have
something we'll be sure to post about it on our blog.

~~~
kevinholesh
Why not put it up on Github so we can help you finish it?

I'm currently a full time jQTouch developer, but I would much prefer a working
environment like the one you're describing. I would certainly be willing to
help develop it.

~~~
sstephenson
We have open-sourced one component, the Eco template language:
<https://github.com/sstephenson/eco>

A couple of other smaller components are ripe for release, too. But the
framework itself needs more work before it can be made public, and that work
is directed by the needs of the application.

------
petercooper
For anyone interested in the idea of having multiple views in JavaScript (with
their own URLs!), "Sammy" is a client-side JavaScript framework that's like
Ruby's Sinatra: <http://code.quirkey.com/sammy/>

Indeed, what Ryan mentions sounds a bit like the ideas of Sammy, Backbone, and
HTML5 local storage and offline caching blended together into a single tasty
package.

~~~
jashkenas
If you'd like to browse an example Todos application (with annotated source
code) that fuses Backbone.js and HTML5 local storage, here's a good place to
start:

[http://documentcloud.github.com/backbone/examples/todos/inde...](http://documentcloud.github.com/backbone/examples/todos/index.html)

The particular Backbone/LocalStorage integration works quite well for this
little app, despite being simplistic:

[http://documentcloud.github.com/backbone/docs/backbone-
local...](http://documentcloud.github.com/backbone/docs/backbone-
localstorage.html)

 _Edit_ : There seem to be a lot of folks who think that Sammy is the only way
to get client-side routing -- nothing could be further from the truth. Sammy
asks you to structure your entire app around an inappropriate faux-server-side
API, and Sammy apps don't work correctly in Internet Explorer because Sammy
doesn't use an iframe to set history in IE. Doing hashchange events yourself
only takes about a page of code, and handling hash URLs is a relatively tiny
portion of a client-side app:

<https://gist.github.com/624773>

That said, so many folks have asked for hashchange routing that perhaps it
would be wise to build a Backbone plugin for it that smooths over the
difference between pushState and hashchange...

~~~
boucher
Completely agree, and I'd definitely recommend an integrated history
management component.

------
pygy_
After node, this is the second big project to endorse Coffescript (although
this is still vapourware of course). And 37signals rock at marketting.

I' glad the language is getting traction.

~~~
boucher
Not really sure to what extent Node is embracing coffeescript, unless there's
news I haven't read you could link to.

------
Void_
Why only mobile? We need something like SproutCore, but easy like Rails.

Backbone.js maybe?

~~~
thibaut_barrere
Why ? I would say: "Focus, focus, focus"!

After doing my experimentations with various mobile stuff, I tend to think I'd
prefer investing time in something specific to mobile like this or sencha, and
rely on a (Rails or other) app with JSON API for the site or back-end.

------
chrisbroadfoot
Doesn't sound very mobile-specific to me. Buzzword? But still, I'm interested
to hear more.

~~~
LaGrange
The target seems very mobile-specific. HTML5 is better supported on mobile,
and the proposed model sometimes fits "desktop" web apps, and almost always
mobile web apps.

So yes, buzzword, but it fits.

------
mhd
Ah, Coffeescript, the Ratfor of a new generation…

~~~
apl
It's mildly annoying. Unlike Fortran, JS doesn't desperately need a
preprocessor language. Adding another layer of "abstraction" and some
syntactic sugar will make the process of developing good JS needlessly complex
and fragile.

~~~
pygy_
So "it turns out"[1] that Coffescript will make the process of developing good
JS needlessly complex and fragile.

Would you care to elaborate?

From the coffeescript site :

> it compiles into clean JavaScript (the good parts) that can use existing
> JavaScript libraries seamlessly, and passes through JSLint without warnings.
> The compiled output is pretty-printed and quite readable.

[1]<http://jsomers.net/blog/it-turns-out>

------
yatsyk
Own programming language, own templating engine - looks like NIH syndrome. But
with 37signals' developers they could afford it.

~~~
thibaut_barrere
The trick with NIH syndrome is balancing, as with any other syndrom. Once you
know about it, you can also detect situations where it's worthy rolling your
own (GitHub's Resque is another successful example of that).

~~~
yatsyk
I agree that HIN is not always bad, Joel has good article about this:
<http://www.joelonsoftware.com/articles/fog0000000007.html>

~~~
epo
Is HIN a reinvention of NIH? :-)

~~~
yatsyk
when Forth programmers are not reuse code I believe it should be called HIN :)

~~~
epo
Touche!

