Thursday, November 6, 2008
Power User Toolbox: JavaScript for SharePoint – Pt1
Adding JavaScript to your SharePoint toolbox? When can we use JavaScript to fulfill user requirements? When should we avoid it?
I find it simpler to identify scenarios where JavaScript makes a poor tool.
- Data manipulation: manipulating data really belongs to workflow. Javascript can change the data in form fields prior to a submit action or make it appear as something else, but if the data actually needs to change, take javascript off the table.
- Security: If you have a really tight security policy for a specific area of your site, do not rely on javascript to keep things that way. Javascript has a few flaws when it comes to security. First, since it gets processed on the client side (in the browser) everyone can read it. Second, clever users can manipulate javascript to do something other than what was intended by essentially changing the code and reloading the page. Third, users can totally turn off javascript processing. So don’t depend on javascript for highly sensitive stuff.
- Client Environment: Javascript can get complicated and cause the browser to loop through several actions all (hopefully) before a page gets rendered to the user. When people using the site have slow PCs, public or shared PCs, or only mobile browsers, javascript will often cause more problems than it solves. Know your audience and know their machines.
- Browser Differences: Like so many things when you deal with web technologies, there are subtle but frustrating differences between the major browsers that can cause errors in javascript. For the work I do, most of those differences relate to the Document Object Model (DOM) and how certain elements are rendered to the screen. For example, IE uses the innerText property while most other browsers use textContent. So in addition to knowing your users’ machines, know their browsers and include cross-browser testing in your development.
- Web Standards: JavaScript has the capability to wreak havoc on the DOM. So if you have a crack design team that created highly standardized master pages and templates for you to use, check with them first if you add custom JavaScript, it could push their hard work outside the standard.
- Limitations: Since its creation, JavaScript needed some limitations to help keep the client’s machine safe from malicious script. Suffice to say, you can’t read or write files on the client’s computer with JavaScript.
View all entries in this series: PaulGrenier-Power User Toolbox»
Entries in this series:
- Power User Toolbox: JavaScript for SharePoint - Pt1
- Power User Toolbox: JavaScript for SharePoint - Pt2
- Power User Toolbox: JavaScript for SharePoint - Pt3
- Power User Toolbox: JavaScript for SharePoint - Pt4
- Power User Toolbox: JavaScript for SharePoint - Pt5
- Power User Toolbox: JavaScript for SharePoint - Pt6
- Power User Toolbox: JavaScript for SharePoint - Pt7
- Power User Toolbox: JavaScript for SharePoint - Pt8
- Power User Toolbox: JavaScript for SharePoint - Pt9
on
1 – Data manipulation: agree that there are better ways to do it. There are a few fringe cases JavaScript makes sense but on the whole it isn’t good for data manipulation on top of SharePoint.
2 – Security: Totally agree
3 – Client Enviroment: Disagree. Yes it can get complex but there are many well documented ways to make sure it is fast and managable, especially when using libraries like jQuery. Assuming you put it on your main pages (using master page or CEWP) it will not effect mobile users as they get pages rendered differently. Performance is also becoming less of an issue thanks to the work that Google, Firefox and Microsoft have done to build a better JavaScript engine into their newer browsers.
4 – Browser Compat: Once again disagree. JavaScript is the same on all browsers, it’s the other things (HTML and XML DOM) that are the problems and those issues between browsers are well documented and a quick Google search can also find the solution.
5 – Web Standards: Agree that manipulation of the DOM could make your page non-standards compliant but as you pointed out, this is solved by consulting with your web designers and making sure it doesn’t.
6 – Limitations: Totally disagree. Yes you can’t read/write to the client machine, but then neither can Silverlight, Flash (they do both offer a sandbox storage but that is not the same as total freedom), ASP.NET (it can read by using the HTML+HTTP, but that requires the user to select the data – JavaScript can do the same thing) or any other web technology. The language itself is well built and extemely flexable for it’s purpose – WEB SITES!
Thanks for the article – looking forward to other parts of the series. It would be great to have a series of articles on using JavaScript with Sharpepoint – perhaps similar to the excellent “Taming the elusive Calculated column” series. I’ve been really impressed by examples, especially on the “Stump the panel” forums, of some creative uses of JavaScript to solve specific problems or, more often, work round Sharepoint limitations. Would love this to be explored a bit further.
Regards,
Greg
@Robert
Mobile browsers are not all created equal. In my testing, some scripts made the load time on my mobile ridiculous. I’m just saying, it’s something a good developer will test.
You’re absolutely right about JavaScript equality. However, in the section, Browser Differences, I tried to convey the need for those new to JavaScript to test their code on multiple browsers for the reasons you mentioned. Some googled resources neglect to mention “this only works in IE” and it can take a novice longer to figure out why a script fails in one browser, but not another.
@Greg
As the series evolves, I will certainly have some sample scripts and talk about using script libraries. We’re even going to try a new method for displaying the code in the EUSP blogs.
Thanks for reading,
Paul
Agree completely with your points, but why would mobile browsers use anything other than the mobile view for SharePoint? That view is not able to be extended with JavaScript (AFAIK… which is not much).
Agree with Robert’s comments. I think some of your examples are not about Javascript being a poor tool, but rather about the tool being misused.
Christophe
There have always been differences in the JavaScript language and I don’t suppose they ever bothered to fix it. Netscape used to have a BLINK function didn’t they that I don’t think everyone implemented?
JQuery is intended to help you get around many of these browser differences and at around 50KB it’s not bad. That said, I regularly evaluate Sharepoint page weights (using the Firefox Web developer Toolbar) at 400 to 600 KB compressed which is hefty enough and will diminish the UX on a slow Internet connection. JQuery will add 10% or more to this. On top of that you will also add your own script.
On the topic of mobile web, the W3 recommends that pages be around 10KB in size and recommend against using script for anything non-trivial and we’re meant to design with W3’s recommendations in mind. If Sharepoint mobile views don’t support JavaScript then I think that’s so much the better as it’ll help to keep developers (like me) honest!
@Christophe,
You are completely correct. I did not convey my message clearly. I meant to say that JavaScript is a hammer. While a hammer is a useful tool in many situations, it’s not a screwdriver and using it as such can do more harm than good.
Mike,
Waldek is writing an article on JQuery implementation in SharePoint this week. Keep an eye on the site.
Mark
(You need to add the JavaScript tag/category to this post so that it shows up with the others…)
Oskar – Done. Thanks for the heads up. — Mark