Marcus Baker recently wrote about Ajax applications not being responsive enough, so the argument goes you should do just about everything in the browser, and mainly use the server-side for periodic persistence. I don’t think that’s always the right thing to do, but there’s definitely going to be more apps developed that way, and there’s definitely a performance driver to keep at least some business logic in the browser.
- Collections and related algorithms.
- Number-crunching algorithms.
- Basic variable manipulation (like Jakarta Commons Lang – simple, oft-repeated code like isWhitespace()).
- Security – Exposes business logic algorithms and enables them to be changed.
- Footprint – There’s the potential to download excessive library code, so careful management is required to avoid that situation.
- Scaleability – While client-side processing can actually out-perform server-side processing when the server is heavily loaded, there’s a scaleability problem – you can only run as fast as the client platform.
But having said that, there are places where it makes sense, and we’ll be seeing a lot more business logic in the browser. It therefore makes sense to ease the development pain when that happens.