4 ms·

>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Th

by copergi 13y ago

>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever Those are two orthogonal things. All my sites have a complete separation of presentation from code and access a nice API to get data. Including the ones that are purely HTML and have no javascript at all. Single page apps are good for things that are actually apps. Except that I want to leave the app open, and several other apps, and not have it interfere with my normal browsing. Until browsers realize this, it is actually pretty irritating to use browser apps.

thedufer 13y ago
Not completely orthogonal. The way Trello is set up, client and server releases are completely unrelated and don't have to know about each other. The web app is almost as separate from the server as the iOS/Android apps, which isn't really possible if you're rendering html in the server. That said, I agree that making something into a single page app just to get this separation isn't going to be useful.
- noblethrasher 13y ago
  >which isn't really possible if you're rendering html in the server. It's not only possible, it's pretty trivial in most cases. Just endow each user facing object with a .ToHTML() and .ToJSON(). This is actually one of the core benefits of REST, you send me a request for a resource along with some desired media type(s), and I send you back a representation in the media type of your choice (or as close as possible).
- DEADB17 13y ago
  > which isn't really possible if you're rendering html in the server. You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture
  - thedufer 13y ago
    That type of double-server architecture isn't one I'd considered. Very interesting.
    - DEADB17 13y ago
      It is, let me know if you want more info
- copergi 13y ago
  >which isn't really possible if you're rendering html in the server. Yes it is, that's my point. Our designers push new templates and our developers push new binaries completely independently. We literally have an API doc that the designers put "I want this" into, and the developers implement it and update the doc to reflect it being finished. People just use template systems that make this unnatural. See heist for an example of a system that makes it natural and straight forward.
  - porker 13y ago
    Thanks for the name of 'heist' - never heard of it before and it looks interesting.
- basicallydan 13y ago
  > That said, I agree that making something into a single page app just to get this separation isn't going to be useful. I agree, but there are other benefits too :)
- Cthulhu_ 13y ago
  I dunno, if you've got a good API, server-side HTML rendering is just another client, just like client-side rendering would be. The trap a lot of developers fall into is going around the existing API for server-side applications though, thinking they'll get more performance by (for example) going directly to the persistence layer. That's how most server-side apps are written, actually; api and front-end tightly coupled.
basicallydan 13y ago
Yeah, you're right, not the same. I was generalising and lumping them together as the same thing though for the sake of praising the Trello way of doing it and encouraging more people to keep the data and presentation separate. I personally like the single page app approach though for reasons other than the fact that it just creates the separation.

by copergi 13y ago

thedufer 13y ago

Not completely orthogonal. The way Trello is set up, client and server releases are completely unrelated and don't have to know about each other. The web app is almost as separate from the server as the iOS/Android apps, which isn't really possible if you're rendering html in the server. That said, I agree that making something into a single page app just to get this separation isn't going to be useful.

noblethrasher 13y ago
>which isn't really possible if you're rendering html in the server. It's not only possible, it's pretty trivial in most cases. Just endow each user facing object with a .ToHTML() and .ToJSON(). This is actually one of the core benefits of REST, you send me a request for a resource along with some desired media type(s), and I send you back a representation in the media type of your choice (or as close as possible).
DEADB17 13y ago
> which isn't really possible if you're rendering html in the server. You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture
- thedufer 13y ago
  That type of double-server architecture isn't one I'd considered. Very interesting.
  - DEADB17 13y ago
    It is, let me know if you want more info
copergi 13y ago
>which isn't really possible if you're rendering html in the server. Yes it is, that's my point. Our designers push new templates and our developers push new binaries completely independently. We literally have an API doc that the designers put "I want this" into, and the developers implement it and update the doc to reflect it being finished. People just use template systems that make this unnatural. See heist for an example of a system that makes it natural and straight forward.
- porker 13y ago
  Thanks for the name of 'heist' - never heard of it before and it looks interesting.
basicallydan 13y ago
> That said, I agree that making something into a single page app just to get this separation isn't going to be useful. I agree, but there are other benefits too :)
Cthulhu_ 13y ago
I dunno, if you've got a good API, server-side HTML rendering is just another client, just like client-side rendering would be. The trap a lot of developers fall into is going around the existing API for server-side applications though, thinking they'll get more performance by (for example) going directly to the persistence layer. That's how most server-side apps are written, actually; api and front-end tightly coupled.

basicallydan 13y ago

Yeah, you're right, not the same. I was generalising and lumping them together as the same thing though for the sake of praising the Trello way of doing it and encouraging more people to keep the data and presentation separate. I personally like the single page app approach though for reasons other than the fact that it just creates the separation.