[jamesmccann]

Can you please elaborate on how a CRM is likely to be in a category where it would benefit from state heavy client-side?

A CRM is typically a form based app doing CRUD - to be this makes it a solid candidate for being a stateless client.

I feel like there's a whole class of applications out there now (including my own) that have gone down the stateful client route where it wasn't necessary and introduce a whole new set of problems and solution libraries / frameworks that can be forgotten about with a return to a stateless arch.

[urlwolf]

I would love to know the answer to this too.

[grandalf]

Apologies for my brief and unsupported assertion. My take is as follows, surely many people would disagree.

For building a prototype CRM system, a server side CRUD-oriented system is going to be the fastest. You could probably build an impressive prototype in Rails (or similar) pretty quickly.

But as the system starts to scale, you'll end up having to extract performance improvements either by optimizing the "within request" performance (caching, etc.) or by creating a hybrid system that uses some client side code to do lightweight updates to a server-rendered page. This is where complexity creep comes in and where may projects start to die and become unmaintainable.

I think many application building decisions are optimized around the early win of easy crud or easy data grids. Even in an app that is full of these things, it does not always make sense to choose the easiest solution.

Instead, figure out how often data changes. If most data changes rarely, as in a CRM system, data can be relatively lazily cached on the client.

Obviously a lot depends on what CRM app you are building, who is using it, how long you expect them to use it, whether it's going to be used on mobile or slow clients, etc.