I'm evaluating pros and cons for building an integration with Salesforce on Force.com platform. This time, I'm curious to what extent are the following points (still) valid, since they were made a couple of years ago. I'll copy and paste some of the mentioned disadvantages for easier referencing.

They're taken from Disadvantages of the Force.com platform.

  1. Apex is a proprietary language. Other than the foce.com Eclipse plugin, there's little to no tooling available such as refactoring, code analysis, etc.

  2. Apex was modeled on Java 5, which is considered to be lagging behind other languages, and without tooling (see #1), can be quite cumbersome.

  3. Deployment is still fairly manual with lots of gotchas and manual steps. This situation is slowly improving over time, but you'll be disappointed if you're used to having automated deployments.

  4. Apex lacks packages/namespaces. All of your classes, interfaces, etc. live in one folder on the server. This makes code much less organized and class/interface names necessarily long to avoid name clashes and to provide context. This is one of my biggest complaints, and I would not freely choose to build on force.com for this reason alone.

  5. The "force.com IDE", aka force.com eclipse plugin, is incredibly slow. Saving any file, whether it be a class file, text file, etc., usually takes at least 5 seconds and sometimes up to 30 seconds depending on how many objects, data types, class files, etc. are in your org. Saving is also a blocking action, requiring not only compilation, but a full sync of your local project with the server. Orders of magnitude slower than Java or .NET.

  6. The online developer community does not seem very healthy. I've noticed lots of forum posts go unanswered or unsolved. I think this may have something to do with the forum software salesforce.com uses, which seems to suck pretty hard.

  7. The data access DSL in Apex leaves a lot to be desired. It's not even remotely competitive with the likes of (N)Hibernate, JPA, etc.

  8. Developing an app on Apex/VisualForce is an exercise in governor limits engineering. Easily half of programmer time is spent trying to optimize to avoid the numerous governor limits and other gotchas like visualforce view state limits. It could be argued that if you write efficient code to begin with you won't have this problem, which is true to an extent. However there are many times that you have valid reasons to make more than x queries in a session, or loop through more than x records, etc.

  9. The save->compile->run cycle is extremely slow, esp. when it involves zipping and uploading the entire static resource bundle just to do something like test a minor css or javascript change.

  10. In general, the pain of a young, fledgling platform without the benefits of it being open source. You have no way to validate and/or fix bugs in the platform. They say to post it to their IdeaExchange. Yeah, good luck with that.

  11. You can't package up your app and deliver it to users without significant user intervention and configuration on the part of the administrator of the org.

  12. THERE IS NO DEBUGGER! If you want to debug, it's literally debug by system.debug statements. This is probably the biggest problem I've found

  13. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com

  14. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature

closed as primarily opinion-based by Samuel De Rycke, Sergej Utko, Alex Tennant, Chris Duncombe, Jagular Sep 4 '14 at 15:48

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

Apex is a proprietary language. Other than the foce.com Eclipse plugin, there's little to no tooling available such as refactoring, code analysis, etc.

True, but I could also argue that all languages are somewhat proprietary to some extent. WordPress and Joomla are both in PHP, but you can't easily port your modules and plugins between the two. Comparatively, if you're used to writing Java, you can write Apex Code fairly easily. Porting is still required, but I don't see that as a particular detractor.

Apex was modeled on Java 5, which is considered to be lagging behind other languages, and without tooling (see #1), can be quite cumbersome.

Tooling API's now exist, and are getting better each release. Even the Developer Console, a JavaScript in-the-browser IDE, is improving radically. You don't even need to install software to write code.

Deployment is still fairly manual with lots of gotchas and manual steps. This situation is slowly improving over time, but you'll be disappointed if you're used to having automated deployments.

I could almost list the things you can't deploy automatically on one hand. The few minor annoyances that exist only affect projects that are doing very specific things. The only complaints one could likely still have is the trouble deploying Apex Code and Visualforce at once, when removing functions/members, and the block placed on scheduled classes.

Apex lacks packages/namespaces. All of your classes, interfaces, etc. live in one folder on the server. This makes code much less organized and class/interface names necessarily long to avoid name clashes and to provide context. This is one of my biggest complaints, and I would not freely choose to build on force.com for this reason alone.

You can use inner classes to simulate packages of sorts. While it's not as robust as true packaging, I've never found myself in a place where I absolutely need the organization. You're more likely to run into other limits, like the total code side limit (3,000,000 characters) before you run into other organizational problems.

The "force.com IDE", aka force.com eclipse plugin, is incredibly slow. Saving any file, whether it be a class file, text file, etc., usually takes at least 5 seconds and sometimes up to 30 seconds depending on how many objects, data types, class files, etc. are in your org. Saving is also a blocking action, requiring not only compilation, but a full sync of your local project with the server. Orders of magnitude slower than Java or .NET.

You're saving to a server. Sometimes the server gets busy. The new Force.com IDE that was open-sourced is much faster, and when the server isn't busy, saves can take a second or less. If saving is really a problem, you can also turn off automatic builds, and build at your leisure. Also, Ctrl-Shift-S to save all files at once triggers only one build/deploy when automatic builds are turned on, which saves time.

The online developer community does not seem very healthy. I've noticed lots of forum posts go unanswered or unsolved. I think this may have something to do with the forum software salesforce.com uses, which seems to suck pretty hard.

SFSE hovers around 85% answered at the time of this answer. We are growing, and we are getting better. The developer forums were kind of chaotic, and I think they've been largely displaced by SFSE, which isn't a bad thing. There's a huge community on Twitter as well. Odds are, you'll get your answer.

The data access DSL in Apex leaves a lot to be desired. It's not even remotely competitive with the likes of (N)Hibernate, JPA, etc.

I think inline queries and other natural queries are far better (on average), than most other languages. Part of it is a matter of preference, which seems to be the original author's nitpicking on minor nuances. I'd wager the original author probably doesn't like Java, either.

Developing an app on Apex/VisualForce is an exercise in governor limits engineering. Easily half of programmer time is spent trying to optimize to avoid the numerous governor limits and other gotchas like visualforce view state limits. It could be argued that if you write efficient code to begin with you won't have this problem, which is true to an extent. However there are many times that you have valid reasons to make more than x queries in a session, or loop through more than x records, etc.

The limits have steadily increased over time, from 20 queries per transaction to 100, for example, and more DML limits, etc. The limits are there to protect the entire system. If you let a query gather up 1,000,000 records in a trigger, then that record will be locked for several minutes. That means more users getting more errors about concurrency locks. Yes, the governor limits are daunting sometimes, but usually you'll find that the page or transaction seems unresponsive (e.g. users will complain about how slow the system is) far before you'll hit a governor limit, in practice. And, over time, you'll naturally start to write more efficient code, making the entire system run faster for everyone. The same is true if you're a game programmer, application developer, etc. You want your users to be happy, and that means you want your code to be a lean, mean, processing machine. We're all on the same side.

The save->compile->run cycle is extremely slow, esp. when it involves zipping and uploading the entire static resource bundle just to do something like test a minor css or javascript change.

So, don't do that. Use one static resource per file, and you can edit them directly in MavensMate, Force.com IDE, etc. You should only package up the ZIP when you're finally done and want to upload a finished version.

In general, the pain of a young, fledgling platform without the benefits of it being open source. You have no way to validate and/or fix bugs in the platform. They say to post it to their IdeaExchange. Yeah, good luck with that.

There's two types of bugs. Those you can fix, and those you can't. The salesforce.com application layer wouldn't benefit from being open source in any particular sense, and they do have an obligation to protect their intellectual property. And, before someone says, "well, open source projects get fixed faster because they have incentive to make it better", salesforce.com also has an incentive-- their jobs and their paychecks. They want to make it better for everyone, and not having chosen OSS isn't an automatic death indicator. Truth is, proprietary, closed-source code still tends to perform better than OSS on any given day. Compare the look and feel of Linux to Windows. I still prefer Windows for its aesthetics, even though I prefer Linux for its general security and power.

You can't package up your app and deliver it to users without significant user intervention and configuration on the part of the administrator of the org.

Most of the time, it's click on a link, next, all users, next, install. The post-setup stuff is usually related to the fact that salesforce won't willingly trample your settings (e.g. page layouts, etc) without administrator intervention. This is a Good Thing, and anyone that says otherwise is probably Crazy.

THERE IS NO DEBUGGER! If you want to debug, it's literally debug by system.debug statements. This is probably the biggest problem I've found

Checkpoints. They help. Also, the debugger in the Developer Console is greatly improving, including a timeline, profiler, etc. If you're not using the Developer Console, then I'd say you're not working most efficiently. Also, I don't test by debug statements, I test by unit testing. That's right. When something doesn't work, I write a test method, and simulate it. Takes all the guesswork out of what that debug statement means.

Also, with the Winter '16 release, there is a proper debugger available, but it does cost extra.

Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com

More language features added every release, even those that are pointless (String.equalsIgnoreCase comes to mind...). Of course, we still can't work in bytes (my biggest annoyance), nor zip/unzip natively, but barring these simple problems, I've never really came across a challenge (other than mentioned previously) that I couldn't handle. The language is competent. It doesn't need to be Java. It needs to do what it needs to do, and it does it.

There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature

This is a problem still. Not a game-breaker, but I'd argue that it would greatly simplify my life if the documentation included limitations or caveats. Usually the documentation is all sunshine and rainbows, and there's not a cloud in the sky. This isn't the reality, and while their marketing literature should be this way, their documentation should not. The documentation isn't there to sell us something, it's there to help us use a system we've already bought.


Overall, I'd say that most of these "fears" are mostly unfounded, obsolete, or blown out of proportion. I've been coding on Apex Code since before the days when "bulk" was a keyword to indicate that a trigger could work on more than one record at a time. We've come a long ways since then, and it continues to evolve. The hardest part of coding salesforce.com is simply getting started.

There's a robust community to help you, increasingly better documentation, a versatile API, and a powerful, maintenance-free cluster of servers at your command to build The Next Great App, be it a blog, an ERP, an order system, license management, or almost anything else you can dream of.

I'll try to respond to these. Overall, I'd take these limitations over trying to implement everything else on another platform. One thing a lot of people overlook when they are evaluating Force.com is the amount of things that can be done without code. Defining your data model doesn't involve dealing with a database, you've got page layouts that are drag and drop for data collection and display, workflow rules let you automate actions, there's built in data validation, etc. I think a lot of the complaints I hear about Force.com come from people new to the platform that don't fully understand they don't have to code everything.

  1. While proprietary, Apex does have more tooling options available now. There is the Tooling API and many devs I know use MavensMate.

  2. I haven't had any problems getting what I need done using Apex. Salesforce is constantly adding features that make things easier. For tooling, see MavensMate.

  3. Deployment can still be manual, but it is possible to use CI tools for many tasks. (Shameless plug: I'm presenting on CI at Dreamforce)

  4. There is still a lack of namespaces, but I think this is more of an annoyance than a real problem. You can use naming conventions to group and avoid conflicts.

  5. The Force.com IDE was recently open sourced, and is improving. Again, see MavensMate.

  6. We've got our own Stack Exchange site! I find the developer community to be very helpful and vibrant.

  7. I don't have any experience with other DSLs, so SOQL seems just fine to me. Since there aren't specifics in this complaint, it is hard to respond.

  8. Governor limits are constantly being reduced. For example, the number of script statement limit has been removed. There are increases coming for async methods in the next release.

  9. While the save->compile->run could be faster, I find MavensMate and the tooling API does a pretty good job. MavensMate also lets you build resource bundles for zip files for much faster work with css and javascript.

  10. Yes, there are some things about the platform that you just want to see changed and Ideas can be out on IdeaExchange for a long time, but we get 3 releases a year with a lot of new features.

  11. I'm not an ISV, but I haven't had issues installing apps from AppExchange. They usually can be installed with little to no setup by me.

  12. Yes, there is no interactive debugger, but you can now put in breakpoints to see a snapshot at a point in time in your code. You can't step through code, though.

  13. True, you can't use external libraries like in Java. There is code people post to Github that can be used in your org, though.

  14. I'm not sure what the complaint is here. I've usually found answers as to why I am getting an error.

Not the answer you're looking for? Browse other questions tagged or ask your own question.