The Internet is a great resource for all of us SharePoint folk, even MVPs and people who work on the product at Microsoft. There is a plethora of information (good and bad) in regards to how to accomplish tasks of varying complexities, whether it be debugging an issue or determining if you should load the latest cumulative update. (Tread very carefully here.) I was sitting with a group of very smart speakers last year, and the joke was made that the Internet made up half of our brains.

Of course this isn’t true. But what I am observing more and more in the SharePoint world and among my clients is the ability for power users to implement complex code to accomplish complex tasks. The power user can almost become a developer. So, the Internet has made everyone a developer. As Sheldon Cooper of TV’s “Big Bang Theory” might reply to that statement, “Is that sarcasm?” I will leave that for you to decide after continuing on.

I am going to boil down how a power user can obtain this capability through three enabling client-side technologies. I say client-side because nothing needs to be loaded on the server for these technologies to work. The only tools you need to use to create solutions are SharePoint, a text editor and SharePoint Designer. The technologies are:
• Content Editor Web Part
• SharePoint Client Object Model
• jQuery

The positive side of the Internet is that many of us are willing to share our solutions via blog posts, webinars, podcasts and other media. For the enterprising person who is willing to research a solution, it is most likely out there in some form. The bad part is if you are an enterprising person who is willing to research a solution, it is most likely out there in some form and can immediately be implemented. Or, said another way, the enterprising person implements a solution and now thinks they need no developer: They are the developer.

The first technical capability that enables power users to implement bad code comes to us in the form of the Content Editor Web Part (CEWP). There is no lack of information on the Internet on how to do complex tasks in SharePoint.
#!
My favorite cautionary tale of the CEWP was when I was managing a team working on a public site for a large enterprise of a brand we all know and love. One of the folks I was not managing, the customer’s personal HTML designer (a great designer), decided he wanted to make a change to the public home page. He implemented this change via the CEWP, published the page, and BAM… corrupted the whole page, throwing all the elements off. He thought he was implementing something simple, but did not understand the ramifications of component relationships on a page.

This is exactly why I have a STRONG dislike for the CEWP and turn to it only when I must. My best practice with the CEWP is to utilize the Content Link. The benefit of this is twofold: The first is that the code (HTML/JavaScript/CSS) does not get buried in the Web Part itself. Burying code in the CEWP is bad because every time the code needs to be modified, the page must be checked out and the Web Part modified.

The other benefit of using a file-based approach via the Content Link is that the file frees the page from ever being edited. When you want to modify code, you do it via a file. Not only that, but now you have versioning. In addition, you have the ability to manage the permissions on the file so that not just anybody can change the code, especially to a public site!

The second enabling technology is the SharePoint Client Object Model. This one is a bit tougher for power users to utilize. In order to properly use it, C# is best utilized. However, power users who can create and edit pages have the ability to implement this type of solution with simple copy/paste. Just like the CEWP, a power user implements this solution on the client-side.

The caveat to this technology is that it is a quantum leap more powerful than the CEWP solution. We are talking code here, people! One must be knowledgeable about items like constructors, the hit a server takes when batching queries, writing modular code, order of operations via JavaScript, and complex things like asynchronous/synchronous call and response.

The last enabling technology is jQuery. This is an open-source JavaScript class library that, when added to a site, gives users the ability to do all kinds of complex client-side operations. Think of it as a bionic suit that enhances your muscles. It enhances your skills, but it can’t give you skills. jQuery is exactly that. It has a rabid following, and a great website with lots of code examples that can be immediately utilized in a SharePoint environment.
#!
If you know JavaScript, implementing a solution with jQuery is not difficult. But jQuery has its own quirks that one must be aware of. You are implementing a library and then your own code that interacts with it. Package your code in files, try not to insert the code inline. If you are using someone else’s open-source code, ensure you understand it. jQuery is powerful, but like any other codebase, there are the potential for bugs.

My cautionary tale in relation to jQuery had to do with a solution that was created for rotating images at the enterprise above. Every day, 60,000 desktops opened up to this page with the rotator. The client did not like the timing between the images and asked us to speed it up. The consequence is that PCs took a major hit since they had a maximum of 1GB of RAM at the time. Combine that with the windows that a person had open, and all of a sudden the helpdesk was deluged with calls about PCs freezing up. Cause and effect. No one wanted to be the developer that day.

Client-side programming has opened up in the last five years with powerful tools that give power users a taste of feeling like a developer. HTML5 and SharePoint 2013 are opening this tool set even wider. With the ability to use a tool like Dreamweaver, now more than ever complex solutions will be implemented client-side.

But being a true developer takes several years of coding to be competent. Copying and pasting some code does not make you a developer. Understanding the complexities of coding, how the code interacts in different environments, understanding how to write and debug code, is a skill earned through experience.

But, thanks to the Internet, everybody is a developer. (Yes, that is sarcasm).

Peter Serzo is a published author of the “SharePoint 2010 Administration Cookbook,” a founder of the SouthEastern SharePoint group, a speaker, and SharePoint Architect for High Monkey Consulting. Peter has been in the IT industry for 20 years. He has extensive experience with SharePoint implementing business solutions for several enterprise organizations over the past seven years.