Why is The Welkin Suite worth the cost over the free Visual Studio Code?

With the ax falling on the Force.com IDE, with its depreciation date set by Salesforce this coming October, I have been getting a lot of questions from our perspective users about why it makes sense to pay for The Welkin Suite when there is the alternative of using Visual Studio Code for free. Also, even a few handful of our current users have asked us what our thoughts are on this, as they just want to maintain their due diligence in making sure they are using the best tool out there for their money. And being honest it is a good question that needs to be answered because as a wise person once said, “if it doesn’t make sense, it doesn’t make dollars.”

So I have tried to put together as many of the answers Vladimir, our head of product, and I have given on this subject into this article to help you out if you have had similar questions running around your head about what is the business case of “Why The Welkin Suite is worth the cost over V.S. Code?”, or “How do I keep justifying spending money for The Welkin Suite when there is the fact V.S. Code is free and has many Salesforce Extensions?”.

So let’s get to it!

We feel the real business case of why TWS is worth it is that for companies and even for the developers and admins who work with Salesforce, there is so much more to the work than just writing code, testing code, or deploying code, as you surely know. It involves working within the governor limits, keeping up with the fast changing environment of API’s, setup and organizational work, expanding development platforms, seeing everywhere a change could affect, third-party applications and services that enhance or simplify the experiences of working with Salesforce.

This is why our goal is to have a tool that can be used not just for classic development, but also for as many of the other tasks which are part of the whole work done by a developer. And also this is why our goal is to have a tool that the whole team can use, and as you might know, this is why we added the admin mode to the IDE to aid admins in their work.

A for a good real-life scenario of why using TWS is worth the money above V.S. Code, let’s look at what to expect if Vladimir would give a member of our parent company’s Salesforce team, which he oversees, the following task and their development tool is Visual Studio Code: create two new fields in an Employee object, add them to layouts, forbid access to the salary and salary change fields for everyone except the finance team, make the salary review date read-only for everyone except the finance team, add a validation rule to forbid editing of the salary for non-active employees, deploy this to sandbox, and deploy to production.

Well first off, if they are a developer, I am sure they would tell him that this is admin work and that the admins are sitting across the hall if he forgot where they are sitting, and I am sure if they are an admin, they would tell him something like, sure just OK me a few hours or more of overtime and I will get this done-- anyway the OT is good because summer is around the corner and I want a new motorcycle.

Well if The Welkin Suite would be used instead, our developer would not be so inclined to push it to the admin as they know this is just 10 minutes of work in TWS IDE, at the most, and it would take more time to explain to Vladimir why someone else should do this, and our admin more than likely would just sacrifice the time needed to drink an unneeded extra cup of coffee to get home on time, instead of sacrificing Vladimir’s OT budget. Ohh If you have not seen this function of TWS just look at our Dreamforce’17 presentation.

So if I would dive a bit deeper into the functionality that allows this, it is kind of hard to do a side by side comparison of TWS and other development tools for Salesforce, like VS Code, because a lot of us have the same or very similar functionality for the coded part: intelligent code completion, retrospective debugger, support for lightning, support for Git, full or nearly full support of Metadata, executing anonymous apex, test execution, and more.

However, there is a big difference in our approach. We believe that developers should not spend their time on configuring and setting up the environment, other tools, other extensions, or needing to go outside of the IDE to receive or look at other information. The seconds or minutes that it takes to jump from the development tool to a browser, or from browser tab to browser tab to deal with something that the development tool should give you out of the box, just add up to too much wasted time.

As a simple example of this – PMD support in TWS. If you would like to use this in VS code you need to install it manually and then you need to dive deep into the PMD rulesets file format and after that, you need to manually configure it all. In TWS – PMD is bundled with the IDE and is installed automatically, rulesets are easily configurable within the IDE in the graphical UI with all the documentation and help links available right there. You can even see this same approach in our DX support and new workflows for Salesforce configuration. With us, there is no need to Google “how to set up something to work with TWS”, or try to remember all the different command lines to start some process.

Another thing to say here is yes, Visual Studio Code could be and probably is a good tool for some, and like mentioned above, with the latest updates it has become better at handling debugging, Git, executing anonymous apex, and working with lightning, but the fact still remains that you are working with a text editor that requires multiple plugins and 3rd-party extensions that have been added to them by other developers to force it into working somewhat like a more complete development tool. This solution, being somewhat flexible, is prone to have a lot of cons from our standpoint such as:

1. Extensions/Plugins are not tied up together, so they are acting separately and there is no tight integration and synergy of the different tools that have been put together. It’s just a set of separate “tools” called from menus of a single application
2. 3rd-party extensions are often developed as pet-projects by developers or current heads of teams in companies as they are easier to do and require less of an upfront investment, thus they have a tendency to stop evolving once their developers lose their interest or the leadership in that company team changes or the direction of his team changes.
3. Resolving issues with extensions can also be tricky, as they are offered often for free or cheaper solutions with no strict support provided
4. There is a probability that the more extensions you will add to the editor – the more conflicts you might have between them
5. Staying up-to-speed over the long run for the extensions with Salesforce’s functionality is a question with no direct answer in most cases.

And the last thing to share here, or I guess it is more to re-emphasize, one of the standout business cases of The Welkin Suite, is it is a tool for the whole team or the complete working set of a developer for Salesforce, where Visual Studio is not. For instance, if you write code, do the point-n-click work, administer organizations, or a bit of all the above, which is the case for most developers or companies, The Welkin Suite has the tools that you need. So looking at that, even if you are focused on Apex/Lighting – you anyway deal with sObjects, Validations and Workflows impact your business logic and it’s essential to have all of them in the same tool where you write your code and you cannot get this in Visual Studio Code. And it’s essential to have not just plain XML files, but good and fast ways to do everything that you might need with the ‘Declarative’ part of the Salesforce configuration. You can see some of these functionalities HERE, but to list a few:

• Easy access to objects
• Field usage report
• Field Level Security inspector and editor
• Fields inspector
• Layouts inspector
• Clone fields
• Easy deployment and Orgs comparison
• SOQL Query builder & data editor
• Validation rules editor
• Permission Sets assignment

I really think one of our users said it best about our approach difference when he replied to our “Why did you choose TWS?” letter, so I will share this with you:

 “I’ve been using Sublime & MM but need a better IDE for use with both Lightning and Classic.  I tried TWS back when it was BETA and liked it, but because it was BETA and had bugs to sort out, and feature to yet be baked-in – I didn’t opt to switch to TWS right away.  I’m a .NET Developer which relied on Visual Studio as the defacto IDE for C#. The Salesforce Extensions for VS Code has just included support for standard Org development back in October but, it lacks some features and polish that TWS has currently.  Also, the Salesforce Extensions project file structure seems more complex, and it just doesn’t “feel” like Visual Studio as much as TWS. And because it was built for DX, it doesn’t “feel” like normal Salesforce IDE either – seem more like a hand-full of cobbled Salesforce CLI instructions”

 This should give you some good information going forward in choosing the right tool for your work in Salesforce, and please contact us via email (info@welkinsuite.com) or our forum if you would have any questions, or if we could be of any other help.

Have a great day,

Daniel, Manager of Business Development