5 ms·
New Rails-like Framework from 37signals for HTML5 Mobile Apps
- chrisbroadfoot 16y agoDoesn't sound very mobile-specific to me. Buzzword? But still, I'm interested to hear more.
- LaGrange 16y agoThe 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.
- pygy_ 16y agoAfter 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 16y agoNot really sure to what extent Node is embracing coffeescript, unless there's news I haven't read you could link to.
- Void_ 16y agoWhy only mobile? We need something like SproutCore, but easy like Rails. Backbone.js maybe?
- thibaut_barrere 16y agoWhy ? 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.
- yatsyk 16y agoOwn programming language, own templating engine - looks like NIH syndrome. But with 37signals' developers they could afford it.
- thibaut_barrere 16y agoThe 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 16y agoI agree that HIN is not always bad, Joel has good article about this: http://www.joelonsoftware.com/articles/fog0000000007.html http://www.joelonsoftware.com/articles/fog0000000007.html
- epo 16y agoIs HIN a reinvention of NIH? :-)
- yatsyk 16y agowhen Forth programmers are not reuse code I believe it should be called HIN :)
- epo 16y agoTouche!
- tlrobinson 16y agoIt's Yoda's version of NIH.
- raganwald 16y agoOwn programming language Is coffeescript from 37Signals? I thought it was written by Jeremy Ashkenas at DocumentCloud?
- mhd 16y agoAh, Coffeescript, the Ratfor of a new generation…
- jrockway 16y agoThere is a need for Coffeescript; programming Javascript directly leads to cross-browser issues. Something like Coffeescript can abstract away the per-browser style issues. (The main annoyance I notice is the behavior of trailing commas in lists. In Firefox, it works. In IE, it silently breaks. Coffeescript avoids this issue, since the code you type never sees the browser.) I would personally find a Javascript->Javascript compiler more compelling, as it would mean I wouldn't need a new editor toolchain. But that wouldn't be as fun to blog about, becuase you would still have to type $("DOM") instead of $ DOM!
- mhd 16y agoWasn't abstracting the differences between different Fortran compilers part of the raison d'etre of Ratfor, too?
- apl 16y agoIt'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_ 16y agoSo "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 http://jsomers.net/blog/it-turns-out
- m0th87 16y agoWhen I used it, it cut ~25% of the LoC off my project. And it only took about an hour to learn because the documentation is so damn good. On the usefulness scale, I'd put it next to jQuery and backbone.js.
- sstephenson 16y agoHey 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.
- zavulon 16y ago> an HTML5 mobile UI for Basecamp Oh man, that would be great! All Basecamp iPhone apps are terrible... If you don't mind me asking, is the "hold" temporary, so will the project be resumed at some point?
- kevinholesh 16y agoWhy 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 16y agoWe have open-sourced one component, the Eco template language: https://github.com/sstephenson/eco 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.
- flacon 16y ago"It just isn't a priority for us right now" I think the number of upvotes your getting demonstrates a sincere interest in such a framework. Really look forward to seeing more from this project.
- petercooper 16y agoFor 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/ 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 16y agoIf 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/index.html http://documentcloud.github.com/backbone/examples/todos/inde... The particular Backbone/LocalStorage integration works quite well for this little app, despite being simplistic: http://documentcloud.github.com/backbone/docs/backbone-localstorage.html http://documentcloud.github.com/backbone/docs/backbone-local... 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 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...
- armandososa 16y ago