Sammy - jQuery based RESTful evented framework | Hacker News Reader

Sammy - jQuery based RESTful evented framework

github.com

64 pointsSingAlong15 comments

Err... I may be missing something, but is there any way to POST data to a hashtag URL within the same page? You wouldn't be able to retrieve the posted data without some server-side cooperation. In fact you're not really doing a GET either in the example code, there is no HTTP action. This makes this not really a RESTful framework, but just a neatly structured event handler for onhashchange.

Edit: Oh I see from the docs, Sammy binds to form submit events ondocumentready and overrides them unless you return false from your route handler. Clever.

I've been using this on a couple projects for the past month or so, and it's awesome. Before I was tearing my hear out trying to keep track of state on my fully ajax-driven pages, and now all my routes and actions are neatly defined as a sammy.js app. I honestly can see building all my apps as non-refreshing fully asynchronous implementations given how easy this has made things.

It's also nice that it is very reminiscent of Sinatra and Rails routes, being a Rails developer myself. My rails app pretty much just serve as APIs for my front end js driven interfaces. Slick!

also awesome is the Sammy author's project that marries Sammy with CouchDB http://github.com/quirkey/soca

The link points to a github repository, which doesn't really have any information. Some digging takes you to a real description of what this is and how it works:

http://code.quirkey.com/sammy/index.html

If I build an application using pure javascript and server-side data apis, does anyone have a feel for how well google is able to index the content?

Do I need to provide "static" html versions of the data at the appropriate urls? e.g. #/data ==> /data or can google follow the js-only links to get at it?

http://googlewebmastercentral.blogspot.com/2009/10/proposal-...

I'm pretty sure that, if you want it indexed, yes, you'd have to provide actual URLs (without the hash).

I think this is awesome, can't wait to try it out. Especially for writing apps that can run in desktop mobile webkit adobe air.

Ditto the comment on node.js integration. Need to wrap my head around this.

I've used Sammy for the routing functionality of a new touchscreen kiosk which is about to roll out in a couple of museums in London. Really impressed with it and can't wait to use it for other applications.

You design your application as if it were to run in a server but... but... it runs in the client.

Nice idea. I wonder how this could interact with a nodejs implementation on the server side.

I am not sure if this is actually the best way to design an application, or if it is just that we are so used to it by now. Seriously, not sure.

I'm using Sammy right now and so far I have two responses to the question of whether a client application should be designed as if it were a server application.

The first thing is that if you are going to run in a browser, I see it as a benefit to have an application where natural navigation "places" have bookmarkable, back buttonable URLs. Sammy makes that easy.

As for the "rest," you don't need to have anything to do with posts and forms and making things rest-ful if you don't want. Sammy ships with a storage plug-in and you can go to town making a state-ful application.

However, if you do want to sup[port book-marks and the back button, you want to give some thought to the relationship between applications state and URLs.

Good point, that makes a lot of sense.

You could have node.js serve different feeds of JSON data (or just use node.js for whatever you need realtime, via socket.io, and pull the JSON from an old-school CMS).

I tried it out, I think it's Awesome. GWT without the Java :)

Reply on news.ycombinator.com