That is a really big "It depends". If you know that you are going to be on 2010 for a long time then it would be safe to build a web part in Visual Studio.– spevilgeniusSep 26, 2014 at 16:44
My take on these:
Server-side code is fun and easy to write, and you can incorporate any feature of SharePoint in order to manipulate it. You can build out vast solutions that touch many different aspects, even outside SharePoint, and bakes it into SharePoint using webparts, timer jobs, event receivers, and the like. It is hard to maintain, and migration to the next version is not guaranteed, and can cause problems for future implementations.
Client-side code is very quick to start and you can see results almost immediately, and this is the preferred method and also supported by O365 and future versions of SharePoint, but 2010's client-side scripting doesn't allow every object or feature to be manipulated, so there are limitations to using 2010 CSOM. SharePoint 2013 has vastly improved the amount of features you can code against using CSOM and JSOM (in anticipation of O365 adoption).
Thanks for that. I think I'll go client-side; I have a server-side version of the web part but it doesn't work and I think redoing it in server-side code will lead to the same problems. That said I am curious what limitations 2010 CSOM has. Are there some objects & features I can't manipulate ever, or is it obtuse to find the solution?– ChrisSep 26, 2014 at 23:11
in 2010, there are very advanced features that you cannot manipulate. Search , MMS, User Profile, and such are specific to 2013 and is not in 2010. geekswithblogs.net/KunaalKapoor/archive/2012/11/26/…– MikeSep 29, 2014 at 13:50