4 ms·

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

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.

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.