They are very different worlds. I've worked both sides of the camp, but mostly server side. I work classic client-server rather than web though (yes, we are still around).
- Client-side is all about user interaction, server-side (most often) has no user. This is actually quite liberating.
- Server-side means thinking about managers, rather than users. You need to provide access for fault-finding, reporting, diagnostic logging - your own and the Windows event log usually.
- Client-side is ephemeral (users come and go), server-side is persistent. Resource management is therefore paramount: leaks mean death. Memory leaks, handle leaks, heap fragmentation. You end up dreaming about this stuff. I got dragged to Spain on 24 hours notice because one system could blow the top off the Windows DDE memory allocator in an anomalous condition, which tells you how important this stuff is.
- On the client side responsiveness to the user (servicing the GUI) is everything, on the server-side it's more complicated. Threading becomes more important, but threading for scalability rather than for keeping the GUI responsive. I haven't started counting processor cycles or checking interrupt latency figures like I used to in my firmware days, but it's getting close.
- Security becomes important, but less than you might think. Not every server application is internet-facing. Think in terms of levels of access, limiting access through views etc.
- Once upon a time server-side always meant native, but that's changing.
Edit:
By threading for scalability, I mean that it's quite easy to apply threads in a way that doesn't scale. Spawning one thread for each query is fine, until your modelling tells you that you might have five hundred concurrent queries. So you need to think in terms of thread pools and queuing.
As far as "managers" are concerned, there are really two types of requirement here, one is reporting for SysAdms, and one is reporting for be-suited management types. SysAdms need help with fault-finding, which I take to be systemic faults that happen to impinge on your applications (network outages, network storms, hard disk full/crash, server failover, invoking DR etc) and diagnostics, which I take to be reporting anomalous behaviour of your own applications.
SysAdms have very short term needs - this hour, this day, email me, SMS me, get it back up etc. They need detailed technical information available all the time, because you don't know when you'll really need it. But no matter how much information you give them, only the very best SysAdms won't pick up the phone and ring you when the ordure hits the air movement device.
Managers need medium to long term performance reporting, how many queries per day/week/month, how did I do last week, what do I need to do to improve this week, how do I make performance to target visible to my staff/peers/superiors etc. This is mostly on request (reports), though things like wallboards with running stats are often asked for... but even those aren't necessarily real-time. You can suck this kind of stuff out of a database on a poll. As a server-side guy, you might have to design some views to facilitate this reporting, but most of your work aims at the anomalous conditions that interest SysAdms. At least, in my experience that's the case. But bear in mind if the SysAdm isn't left happy, you'll be dealing with the manager anyway...
An aside: curiously, although SysAdms seem to lead quite stressful lives, all the best ones I've ever worked with were very laid-back people. Odd, that. I suppose it's a coping mechanism.