Pros and cons of code vs. no code in SharePoint development?

Question

Here's my situation: I work in a user area and have been tasked with creating usable SharePoint sites for different areas. Some are doc management, some are collaborative work spaces, some are task and calendar-driven. Some are combinations of the above. My point is that I've got a very diverse group of sites to create.

Our IT department is unprepared to support SharePoint. Even though I can do the requisite .NET development necessary to create the feature-rich sites I envision, that's not something I've been cleared or given access to do. If I were to develop an application, the question "Who's going to support the application?" will inevitable arise, and it's back to resources again. Our limitation seems to be OOTB SharePoint Foundation, without any .NET development, AJAX, or other nifty tools to make it more usable.

As I ask questions looking for creative client-side only solutions, I see several comments from posters that suggest the folly in that approach. However, I also get responses that give me a workable client-side solution. While the latter gets me what I need, the former makes me question if my approach is the most prudent.

I see a lot of "no code" questions, but haven't really found any information about why server vs. clietn development is an issue. Apart from the usual standards issues when everyone's developing willy-nilly, what other considerations must I make? For me, the beauty of SharePoint is the dozen or so ways to do anything. When is it appropriate to make an application that uses ONLY OOTB client vs. server-side development? What questions do I need to be asking to ensure that I make the correct recommendations? If we jury-rig applications to run without any server development, are we setting ourselves up for problems in the future, and what sorts of problems might we encounter? Is it worth doing OOTB development now and 'upgrade' to a server-based solution when we can, or is it more prudent to wait until IT has their support infrastructure set up and can start coding? Is there a good rule-of-thumb for determining if an application should be server-based or OOTB SharePoint client functionality only?

Answer 1

The client side (no-code as you call it) approach is non-destructive to the platform as it all happens with what SharePoint natively serves up. If something breaks, you remove the problematic script and you're back functioning natively without any fancy customizations. If done right, this can still be very powerful and SharePoint gives you native version control. So your JS files can be versioned and rolled back quickly if there is an issue.

The coded approach is modifying what the server is sending to the user, so it's much more destructive in that if you don't have something right, i can cripple the site and or farm as a whole.

The client side approach is harder to deploy to multiple instances unlike the coded solutions which are deployed as features and can easily be activated anywhere.

I am in the former (no-code) with some spatterings of code (data view web parts, some custom CSS and master pages) and we can still deliver rich, specifically targeted applications.

Answer 2

"It depends" :)

No code is great when you want to do something reasonably small, quick, not wide ranging on your site. You can do a fair bit with JavaScript, content editor webparts and client object model.

It isn't particularly scalable though. You end up copying a lot of stuff around, hacking away at master pages in notepad, that sort of thing just because you can't easily deploy code.

It comes down to whether you have complex systems which are maintainable because you follow decent solid software engineering principles, repeatable trustable deployment, source control, supportability etc

The fact that you create things through the UI and use JavaScript in CEWP, change master pages etc doesn't mean you don't have an application. You have still built one, just one which is harder to fix when it goes wrong.

Answer 3

As I am in the exact same situation here in my company, I can imagine your situation. When I searched for answers I stumbled upon Marc D Andersons Blog and especially his Middle Tier Manifesto. These ideas helped me a lot to define my situation.

If you are all new to JavaScript in SharePoint and don#t know yet what you can do with it, I recommend you to take a close look at Marcs SPServices library. It is an abstraction of SharePoints Webservices and all about retrieving and sending data from and to SP lists and so on.

Answer 4

As @PlanetWilson wrote "It depends"

Here's my view on Server side/Client side/Sandboxed solutions. I only list the benefits of each, then you can extrapolate the drawbacks by looking at the benefits of the other parts or by thinking of when the benefit may be a bad thing.

Benefits of Server side

• Can perform actions which the current user don't have permissions to do. Which means you protect list/items so they can only be updated/accessed through the code
• Can get access to all of the SharePoint functionality.
• Application lifecycle management. There are good tools/techniques for version control of code and for controlling the deployment/upgrade of solution in Dev => Test => Staging = Prod environments
• "Easy" to develop/lots of examples
• If well developed gives a lot of power to the users by allowing configuration/connection of web parts.

Benefits of Client side

• Can be deployed to environments where you can't get Server side code for some reason
• Often gives a better UI as we're doing AJAX anyway

Sandboxed solutions

• Can add some functionality like event receivers where Server side solutions isn't allowed
• Can't bring the servers down

Answer 5

Probably, most questions will arrange in more system if you look at Sharepoint from the point of view of cloud technologies and specifically of using Sharepoint Online (Office 365).

There:

• there is no access to Central Administration and. hence, administrator-approved forms or disabling notorious Loopback Security Check or using/administering AD, et., etc.
  In Sharepoint Online, the server-side dev is simply does not have much sense
• you can create code-behind for Infopath 2010 forms in VSTA (Visual Studio for Applications) but that VSTA is really Visual Studio 2005 for Applications with .NET 2.0 no higher than 2.0
  The latter should be considered in order to not break development solutions a-la VS2005/.NET 2.0
  But if you deepen in client coding then you understand soon that it is mostly a waste of time and better to spend your time to know well what can be done codelessly and OOTB
• client solutions (like Infopath client/Filler Forms) are cheaper and, surprise-surprise, is richer in functionality and easier to configure (do not have double-hop authentication issues) than Infopath browser-based forms requiring Infopath Form Services from Enterprise Sharepoint Server 2010 plans, etc.

BTW, I am developing on Windows XP SP3 32-bit computer using Sharepoint Designer 2010 and Infopath Designer 2010 against Sharepoint Online 2010 (Office 365) site
This is cheaper, simpler. less intrusive and more maintainable than putting every developer on Windows Server 64-bit machine with farm or server privileges.