Salesforce and Developer Happiness
A little over four years ago I did an internship working with the Salesforce platform (SFDC) and, at the end of the summer, passed the Salesforce Developer Certification test. After that, I vowed to steer clear of working with Salesforce. It took the fun out of writing code.
A few weeks ago I was staffed on a project at work that required developing public-facing web pages on SFDC. I was intrigued to see if the SFDC development experience had gotten better over the last few years. There were three main points of friction that really bothered me in 2011.
- Lack of documentation and answers online
- Low Quality Development tools
- Unclear Best Practices
TL;DR - Working with SFDC is only marginally better than it was four years ago.
Documentation and Community
I quickly found that the documentation has gotten much better. It is much easier to find the information I am looking for and the doc pages have a nice clean design.1
Also, when I went hunting for answers away from the documentation I discovered that SFDC now has its own StackExchange.
These changes are a big step in the right direction for SFDC. Despite this, there is one issue that they can’t fix. The size of the developer community still makes it difficult to get help. SFDC is an expensive platform and there aren’t too many resources out there.
Development Tools
Not much has been done in this area. The “Salesforce IDE” is still around, but remains an extremely buggy IDE built on Eclipse. Painful.2 It feels as if Salesforce continues to add bells and whistles but doesn’t really concern themselves with the developer experience. Let me share a few other examples.
On this particular project, I needed to create a few web pages with the client’s branding. Normally, you would just write your HTML (or templates), create a few CSS files (or SCSS), drop in a <link> tag and refresh the page. In order to add static resources (CSS) to your SFDC page, you have to manually upload a zip file. Imagine doing this on every change.
You are probably thinking, “Oh, I’ll just code up the HTML and CSS on my local machine with dummy data, then upload once when I’m done.” Sadly, its not that easy. Take this Visualforce (VF) button tag (VF is the SFDC markup language):
<apex:commandButton value="SUBMIT" action="{!failToEnrollPage}" id="submit" styleClass="ContinueButton" />
Outputs this:
<input id="j_id0:j_id5:submit" type="submit" name="j_id0:j_id5:submit" value="SUBMIT" class="btn ContinueButton">
Salesforce adds its own IDs to all HTML elements so you can’t depend on IDs at all (or name). Secondly, there was a “default” SFDC CSS file included on every page that I could not get rid of. I had to make several changes to correct the effects of these errant CSS rules. As you can see above, SFDC includes the class .btn for all buttons created with the <apex:commandButton> tag with its own default CSS rules.
Best Practices
Normally, you’d expect best practices to form around any development platform. I have had a hard time figuring out what (if any) best practices exist. Some of this I attribute to the small community. There are little or no open-source libraries for APEX (the SFDC java-like programming language). This is mostly because there isn’t a way on the platform to install or use third-party code. It is a big contrast to the Ruby/Rails community where there are a plethora of blog posts and third-party gems to browse through. It is easy to seek out best practices and/or opinions in the Ruby community.
Despite the marked improvements, I still wouldn't want to be involved with Salesforce. Working within the platform limits takes a lot of the fun out of creating software.
1: Speaking of good design, big props to the Salesforce UX team. I found their recent project very impressive. ↩
2: Despite the Salesforce IDE being terrible, there are several decent alternatives: Mavensmate, Brain Engine, Cloud9 and others. I used Mavensmate Sublime plugin and it worked pretty well, much better than the Force.com IDE. ↩