[basicallydan]

Fog Creek are the _kings and queens_ of dogfooding. Spolsky, you sure have nurtured a group of very loyal team players. I applaud you all. It must be really nice to work at a place where the love of the process and the product are both so strong.

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. From the start, design your system this way.

Good post, and an entertaining read.

[iLoch]

While I don't think client side apps are the only way of doing things, I will say that I think client side apps will become much more popular once browsers get a little better.

I love the separation of concerns that is possible with JS apps - you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation. Once it's all done, you've already got a fully functional and secure API (because it wasn't an afterthought) that can be used for other clients.

[ChuckMcM]

   > I love the separation of concerns that is possible with ... one team working on the API and one on the interface

That is, in my opinion, the larger point. If you can do solid 'interface driven design' then you enable rapid evolution on both sides of the API. One of the things Jon Wall and I did at NetApp was prototype a better split of system across the RAID and Filesystem layers, that split achieved 50% better performance across the same spindles and it allowed for innovation in the file system layer that was currently hindered by "all the hooks into the RAID stuff".

The key though is picking the right layering, and not having too many. Like hashes in perl you can go crazy and suddenly everything is an API and simple things go through n layers and bog down.

When people tell me they want to be architects I ask them questions about layering, that is where you separate the good systems thinkers from the not so good ones.

[basicallydan]

> I love the separation of concerns that is possible with JS apps - you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation.

Yeah, me too. Apart from the actual, observable benefits you mentioned, I just find something really satisfying about the separation. Fewer hacks, easier to modify things.

I think the rise in the popularity of doing things this way is largely thanks to the increase in popularity of test-driven development. Creating a client app without an API is so easy given all the tools available for mocking or faking APIs, and creating a standalone API is easy given that most of the time, you're just testing the JSON or XML output of a bunch of functions.

[copergi]

>you can have one team working on the API and one on the interface and the only place they really need to communicate is in the API documentation

That's already how you should be working anyways. Unfortunately, most language don't seem to have support for a decent template system that makes this natural. People need to start making heist clones in their language of choice so doing things right becomes more common.

[iLoch]

I agree, but it's often too easy to just add another variable in your controller then modify the view, and now there's undocumented functionality. IMO the full separation is more helpful to stay DRY.

[reddiric]

What does the article say to advance "single page apps" as the "best thing ever" over other application models that use a clean interface and separation of concerns between client and service?

[copergi]

>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]

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.

[DEADB17]

> 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]

That type of double-server architecture isn't one I'd considered. Very interesting.

[DEADB17]

It is, let me know if you want more info

[noblethrasher]

>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).

[Cthulhu_]

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]

> 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 :)

[copergi]

>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]

Thanks for the name of 'heist' - never heard of it before and it looks interesting.

[basicallydan]

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.