Salesforce DE Org - Great Javascript Sandbox

Compared to other sites, Salesforce can feel a bit sluggish. I’ve seen some web apps, such as Gmail, Grooveshark, and the new Twitter site, that feel quite responsive, making them more fun to use and explore. I found that the enabling tool at use in these sites is Ajax and lots of Javascript to move the application logic into the web browser instead of the server. These highly responsive apps inspired me to start playing with Javascript and other HTML5 features to see what’s possible client-side to make the web site experience faster. I chose to test these Javascript ideas in my Salesforce Developer Edition org, and looking back, I’m pleasantly surprised with how good of a choice this was.

The first wonderful thing about using Salesforce Developer Edition orgs for testing web pages is that there is no server to set up. To experiment with a new page, simply click the “New Page” button and you are ready to start writing HTML and Javascript. Server software doesn’t even need to enter your mind, lowering the barriers and allowing you to whip up a web page relatively quickly to test out a new idea. A few weeks ago, I blogged my thoughts about the complexity that server software add to a web site, a complexity that Force.com does not really have.

The second great thing about using a SF DE org for testing HTML page ideas is using apps and tabs to organize your experiments. My first round of web page experiments involved testing out various Javascript MVC frameworks. I created a different page for each framework I wanted to test, created a tab for each page, and collected all these tabs in an app called ‘JS Frameworks’. Likewise, when testing ideas for using Javascript to enable drag-and-drop multi-file uploading, I created a new tab for each experiment and grouped them into a new app named ‘Multi-File Upload’.

This organization becomes more apparent in the third benefit of using a SF DE org, that the pages are always available. Why is this important? Whenever motivation or an idea strikes, no matter where you are, you can fire up a web browser, log into your DE org, and update your page’s code directly from the browser. This high availability, in time and place, makes Force.com an epitome of truly ‘developing in the cloud’, and it’s quite motivating.

Of course, there are few downsides to choosing Force.com as a testing ground for new ideas. A Visualforce page with the standard Salesforce sidebar and header injects a glob of extra Javascript into your page. While it doesn’t affect your development most of the time, it will occasionally cause headaches while you track down an odd Javascript issue.

Another side effect is that your pages must pass through the Visualforce parser. Why is this a concern? If you use Visualforce tags, their element ids will be prefixed with the element’s entire ancestor id hierarchy. This looks quite messy, for one, and you are forces to craft your Javascript to handle these messy ids. Another issue with this is that it must become standard practice to use a noConflict version of jQuery for your own app. I believe Salesforce also uses a version of jQuery, and they advise this as a best practice to avoid conflicts. An inconvenience, to be sure, but definitely worth the trouble to gain the other benefits of the platform.

Surely an interesting platform on which to test new ideas, Force.com has its benefits as well as its downsides. I will continue to use it as I continue on my quest of attaining highly responsive web pages that utilize Javascript.

Posted in: Programming, Salesforce, Web Development