4 ms·

When all you have is a hammer ... jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and t

When all you have is a hammer ... jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and there. It does a poor job of modeling the UI state. Sinatra is also a poor architecture choice for the client since the client has persistent state. We already have a well designed client architecture. It's called Cocoa and its implemented in the browser as Cappuccino.

jherdman 17y ago
Interesting point. I tend to agree with you. I find myself hesitant about putting my business logic essentially on the front-end. With the current model we can hide some of the "secret sauce" that makes our applications unique on the server end. With something like Cappuccino (or Sammy.js, etc), how do we keep our secret sauce secret?
- shykes 17y ago
  > I find myself hesitant about putting > my business logic essentially on the front-end Leave the business logic on the server where it belongs - but hide it behind a REST API, and leave the rendering to the browser. I think that's the core argument, if you omit the "CouchDB as an app server" part (which is orthogonal).
  - ams6110 17y ago
    This was exactly the approach I took with an app about 4 - 5 years ago. Back then XML not JSON was the data transport format, but I kept it lightweight. The UI was built in the browser using XSLT to generate HTML. Additional transforms tied to UI events allowed filtering, sorting, etc. all on the client. IE, for all its other flaws, actually supported this much better than any other browser at that time and we were developing in an IE-only environment. Business logic was on the server in stored procedures, which were exposed in a simple web service api so they could be called directly by the browser script logic. This also made it very testable because the stored procedures could be invoked by testing scripts that did not depend on the presence of any middle tier or UI at all. It also would have been a simple matter to build other client front-ends, as long a platform could work with XML and HTTP it could in theory be a client. The XSLT to render the UI from XML could get a bit verbose but despite that it turned out to be a very productive way to work. The downsides at the time were that IE was slow to render when you injected the HTML output of the transforms into the body.innerHTML property; this became noticeable if the generated page was large, but on the plus side this was a constraint against developing overly-complex pages.
voidfiles 17y ago
I find the grafting of cocoa onto javascript a bit stomach turning. Its like watching a man read the news to you on TV. Different mediums require different methods. I don't think anyone has really gotten this right yet. I agree jQuery isn't the whole solution, I don't think Sammy.js is the whole thing either. But I do think there will be something built on top of this stack. I have started to try and create something like this http://github.com/voidfiles/BHive http://github.com/voidfiles/BHive .
- richcollins 17y ago
  You didn't explain why the Cocoa model doesn't work on top of the DOM.

jherdman 17y ago

Interesting point. I tend to agree with you. I find myself hesitant about putting my business logic essentially on the front-end. With the current model we can hide some of the "secret sauce" that makes our applications unique on the server end. With something like Cappuccino (or Sammy.js, etc), how do we keep our secret sauce secret?

shykes 17y ago
> I find myself hesitant about putting > my business logic essentially on the front-end Leave the business logic on the server where it belongs - but hide it behind a REST API, and leave the rendering to the browser. I think that's the core argument, if you omit the "CouchDB as an app server" part (which is orthogonal).
- ams6110 17y ago
  This was exactly the approach I took with an app about 4 - 5 years ago. Back then XML not JSON was the data transport format, but I kept it lightweight. The UI was built in the browser using XSLT to generate HTML. Additional transforms tied to UI events allowed filtering, sorting, etc. all on the client. IE, for all its other flaws, actually supported this much better than any other browser at that time and we were developing in an IE-only environment. Business logic was on the server in stored procedures, which were exposed in a simple web service api so they could be called directly by the browser script logic. This also made it very testable because the stored procedures could be invoked by testing scripts that did not depend on the presence of any middle tier or UI at all. It also would have been a simple matter to build other client front-ends, as long a platform could work with XML and HTTP it could in theory be a client. The XSLT to render the UI from XML could get a bit verbose but despite that it turned out to be a very productive way to work. The downsides at the time were that IE was slow to render when you injected the HTML output of the transforms into the body.innerHTML property; this became noticeable if the generated page was large, but on the plus side this was a constraint against developing overly-complex pages.

voidfiles 17y ago

I find the grafting of cocoa onto javascript a bit stomach turning. Its like watching a man read the news to you on TV. Different mediums require different methods. I don't think anyone has really gotten this right yet. I agree jQuery isn't the whole solution, I don't think Sammy.js is the whole thing either. But I do think there will be something built on top of this stack. I have started to try and create something like this http://github.com/voidfiles/BHive http://github.com/voidfiles/BHive .

richcollins 17y ago
You didn't explain why the Cocoa model doesn't work on top of the DOM.