As more and more developers build on top of the MindTouch platform, some seriously impressive and complex tools and applications have emerged. From NeilW’s incredible sortable paginated zebrafied table template to our own esteemed RoyK’s time tracker and beyond, our App Catalog is growing rapidly thanks to people developing on MindTouch. For me personally, it’s interesting to watch these applications progress and take different twists and turns to arrive at their final revisions.
Being on this side of the telescope has allowed me to get a good idea of not just how all the moving parts work, but also how they work best. By that same token unfortunately, I’ve also gotten a good idea of how they work the worst! And believe me… it can be plenty bad.
Mise en place
Oftentimes, sluggish apps are doomed to Performance Purgatory because they were created in less-than-ideal spaces. The French phrase “mise en place”, or “everything in it’s place” (yes, I watch Top Chef), is equally applicable when it comes to developing 
within the MindTouch platform.
MindTouch’s distributed nature, combined with its’ RESTful API, provides countless means to extend functionality. With those means, however, it’s important to know what and where to create your apps; the DekiScript/Javascript/jQuery toolkit is an essential part of building useful enterprise tools, but it’s not the only (or always the best) one to use. Depending on the intended functionality, using other programmatic methods could greatly increase performance not just for that app, but for the entire site as well.
DekiScript/Javascript/jQuery
DekiScript is a very powerful but easy-to-learn scripting language that allows users to mash up data from a number of different sources into one uniquely useful product. Parameterized templates, dynamic reporting, and custom workflows can all be created using it. Most users in MindTouch use DekiScript to some extent, even if they don’t realize it; extensions such as flickr and Google are easily inserted by the extensions manager, but the end result is a DekiScript call.
More technical users use DekiScript (along with Javascript and jQuery) to create mini-apps like a simple poll or a bug tracker. DekiScript is great for things like this, for a few reasons:
- It’s client-side, so users don’t have to install anything on the backend
- Users can modify templates or pages to fit their individual needs
- Templates are easily shared
- You can utilize other DekiScript extensions and functionality, without having to create additional connectors
As a result, the vast majority of applications for MindTouch are written using the scripting tools available. Many of them, contributions from our community on both our developer site and in the forums, have blown me away with how much they can do. However, there are some downsides to DekiScript, which I’ll detail.
First, to use some of them, you need to have the UNSAFECONTENT permission to save it. Obviously, this is a good thing, since it prevents malicious activity. However, if a user with those permissions creates a page with unsafe content and another user without those perms edits and saves it, the scripting is disabled, essentially breaking the functionality. Second, because it is exposed to end user modification, it’s subject to changes that may make it more difficult to upgrade in the future. It’s also subject to bugs from other components, such as Internet Explorer or Mono. Sometimes the issues that arise from those components can require hair-pulling workarounds that’ll make you cry (jQuery and IE6, for example). Lastly, depending on what it’s doing, performance can be substantially slower than other server-side implementations; while DekiScript is powerful, it still relies on the browser and on calls going back and forth to the API. As such, poorly-contrived code can be brutal on a MindTouch instance. I would know, I’ve been guilty of writing some!
PHP
The alternative to using client-side scripting is running your app server-side (duh). This has a number of advantages over making the browser and the MindTouch engine do all the work, as well as some disadvantages. For this post I’m just going to be referring to PHP on the same MindTouch server, but you can write your app in almost any language.
If you choose to have the app server-side, you have the security of knowing that only you (or other admins) 
can screw it up. This is a huge plus if you’re maintaining a site; because you have complete control over modification, maintenance and upgrades are much easier. In addition to the maintenance, performance is often significantly better. You’re not relying on the browser to do calculations or data manipulation, and since the script and MindTouch reside on the same server, data transfer times are drastically reduced.
PHP is also a great choice for a few other reasons. Hooks make it easy to interact with the API, and Special Page Plugins can be quickly created to extend MindTouch’s functionality. PHP is also very MySQL-friendly, so more complex apps that require the use of database can be written. Finally, the MindTouch UI is written in PHP!
Of course, some of the advantages of using PHP can also be disadvantages. It’s not quite as intuitive as DekiScript, so the technical ability requirement goes up. As it does reside out of reach of end users, the script cannot be collaborated on like templates can. It also cannot utilize the built-in MindTouch extensions. And if you’ve got a prohibitive IT department which has a lot of processes for deploying updated scripts… well, prepare for a lot of back-and-forth emails!
Who’s better?
The simple answer is… neither! Both the DekiScript/Javascript/jQuery toolset and server-side scripting have their appropriate places to be used, and they’re certainly not mutually exclusive; the richest apps I’ve seen to date are a combination of both client- and server-side implementations. From experience, I can say that the best way to determine what to use comes from taking the time before you start writing to properly spec your application. It’s a little more effort, but doing so will help you to figure out the best angle of attack and prevent headaches (and drastic changes!) down the road. Your apps (and your users) will thank you for it.
