1

I've used eclipse for a lot of purposes. At the beginning to write code and later mostly for deployments.

Now I see, that Salesforce is focusing on Visual Studio Code for the future.

I love and hate eclipse and force.com IDE at the same time. I love it because it can do a lot. I hate it, because its old, slow, full of bugs and greedy for local resources on my notebook.

But my primary needs are not around Scratch Orgs and the most important things are

  • Edit and Save Apex, Visualforce, Lightning Components and JS in zipped static resources on any Org (especially normal DEs and Sandboxes) without using repositories and with a simple ctrl+s to save
  • doing that save very very quickly (im counting miliseconds and I want the highest speed possible with an org using)
  • deploy stuff like with eclipse: select multiple mixed types of metadata on the UI (like pages, layouts, apex, components at the same time), right click, deploy to ANY server

I've had a glance on Visual Studio Code and read a bit into DX but my old school requirements are addressed only partly and DX seems all about scratch orgs and Scratch Orgs I do not want to use. I don't want to discuss or elaborate "why" but only say that we need huge masses of complex linked SObject record data and complex org prerequisites plus configuration even for simple developments. I can't and DON'T WANT to recreate in that the scratch org livecyle. I know a lot could be automated but it would be a huge effort I don't want to invest into that right now.

Is it already possible now or will it be possible at some time in the future to use Visual Studio Code more like eclipse or will it only stay closely coupled with scratch orgs?

2

DX is a new shift in Salesforce development. It's not meant to be an IDE-based development cycle. Instead, you use a Scratch Org to quickly build out new features, then use 2GP (Second Generation Packaging) to quickly deploy those changes to new orgs. If you choose to use a Sandbox instead of a Scratch Org, you lose the benefits of faster development cycles, but you can still use DX in that situation. There's no strict requirement that DX use Scratch Orgs or repositories. These are simply optimal development cycles.

The new force:source:retrieve and force:source:deploy features enable you to quickly retrieve and deploy a limited amount of metadata to/from your computer/org. It's not as fast as force:source:push and force:source:pull, but these commands are geared for developers that don't want to use Scratch Orgs or repositories. However, they are slower, and you will not get "millisecond-fast" saving using these features. Ultimately, you'll end up needing to use the Developer Console if you go this route.

In other words, if what you need is a new IDE, DX is not the tool you're really looking for. At least, not today. It may include better support for Force.com-style functionality in the future, but for now, that's how it is meant to be used. You simply can't obtain the speed and versatility of Force.com IDE today with DX. However, it is likely that something like that will occur in the future, either by salesforce.com directly or a third part developer that leverages DX to perform this sort of functionality, but for now, DX is not the solution you're looking for; it does not meet your requirements.

  • I would use scratch orgs, only if there was an scratch-org-create feature as comfortable as creating sandbox with at least the partial-copy data limit of 10k records to copy per sobject. as clone-source i would want any org: other scratch orgs, prods, DE, sandboxes. I could live with a smaller data storage, though. But setting up complex networks of related objects with a critical mass of meaningful data is more like a datamigration and this cost outweighs the benefits of scratch orgs in my cycle – Uwe Heim Nov 4 '18 at 16:26
  • I've seen there is a feature to create sample data in DX but someone told me it's limited just to e few hundred records – Uwe Heim Nov 4 '18 at 16:31
  • @UweHeim Your data import is limited by only storage space. While there is a "200 per import" rule, the system allows you to import thousands of records via something called a "data plan." I don't have a lot of experience with it, but I don't see why one couldn't import 10,000 rows if one wanted to. – sfdcfox Nov 4 '18 at 16:34
2

What sfdcfox said. I should add that it is on the VSCode/DX roadmap to eventually get feature parity with Eclipse. In the meantime with the new force:source commands you can start to get closer to it. There is a right-click deploy feature that works with whatever you have set as default org in the command line, and you can switch it at will.

I honestly can no longer recommend the Eclipse plugins to anyone because they are TOO OLD. If you, for example, retrieve a Flexipage using an old API version, any features newer than that version get wiped from the page and vanish when you deploy back.

If you want an IDE for traditional org development to fill the gaps until you reach feature parity, look into either Welkin Suite or Illuminated Cloud. I believe those are the only two that haven't called it quits.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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