The other day, I was doing routine maintenance on a website. It involved a very simple upgrade of a section of my SiteCommander back end, which I had performed on all my own sites and several other sites belonging to clients.

This time it went sideways, temporarily taking the site offline.

My typical SiteCommander updates are simply uploads of new code to the client site. New code is always tested on my sites first, so if anything goes wrong, I take the hit. All I need to make this work is an FTP/SFTP/FTPS client that is reliable and can tell me the specifics of a failure should one occur. I get that sort of feedback from FileZilla and even better information from the built-in deployment facility in PhpStorm. The aging Expression Web gives better clues. But the SFTP extension in Visual Studio Code (VSC) handled this badly.

Upon investigation, I determined that the cause did not lie with any of the FTP client software. Instead, there was a glitch at the hosting company that prevented the completion of the upload of a group of files. One file got hung in an indeterminate state, which I later confirmed to be the deletion of the original on the server and then a failure of the FTP server to accept the new file.

I could not clear this condition with the SFTP extension for VSC because it hung. Its tiny progress icon was spinning, but nothing was happening. I've cleared this condition before by closing and launching VSC, but whatever state the server was in could not be handled this time.

I then turned to PhpStorm. I performed the same update (same group of files at the same time) and, again, the client tripped over the bad file. However, PhpStorm specifically identified the file that it could not upload, and the FTP session ended (as compared to SFTP hanging). Then I selected the single file that had caused the problem and uploaded it alone, which worked.

I had also tried to clear the condition with FileZilla. Although it identified the problem, it could not upload the afflicted file. I think if I had used FileZilla to delete the remote file first, that would have cleared the problem.

The long and short of this is that the SFTP extension for VSC remains unreliable.

The dangers of open source, or Microsoft's fault?

Maybe both.

Visual Studio Code is an open-source project, initiated by Microsoft and, generally, under the control of Microsoft. This has worked out pretty well so far, with VSC getting a lot of positive reinforcement — not only from developers but also from the very large community of extension creators. There are thousands of extensions of an astonishing variety and sometimes for the simplest of things.

However, Microsoft is depending on this. When VSC was first released, it came equipped to handle a small set of languages very well. That set included C and, perhaps most notably, Python. It also supported HTML, CSS, and JavaScript. Microsoft pointed to that set of languages as a reason VSC was suitable for Web development.

Unlike Visual Studio or Expression Web, VSC did not launch with any sort of deployment capability. Instead, it promoted the use of source code control systems, especially Git. I think it was assumed that developers would use VSC to write and manage code but find the means of deployment elsewhere.

The absence of an FTP client was immediately noticed, and several extensions became available to provide the service. In my estimation, none are great and SFTP is the best.

VSC is a good editor. It's a good HTML editor. But if it's going to be used to write HTML, it makes sense that it should have a publishing capability similar to those in other Microsoft products, including Expression Web. I still do not understand why the basic capability is not provided out-of-the-box with VSC. I thus consider the lack of publishing a mistake on Microsoft's part. I do not think this is something it should have been left to third parties.

Which brings me back around to open source for extensions. The problem here is that it's easy to become attached to an extension that provides a valuable capability, only to find that the creator of the extension has moved on. That's what happened to SFTP. It languished for nearly two years with no updates even though a critical flaw was causing problems for many. Eventually, another developer decided to make the fix and it is his fork that is now the primary version of the code. But what happens if he can't find the time or doesn't care to carry on?

There is an expectation that serious developers who depend on open-source code will simply fork the code when necessary. I've done that once myself, when a core component of SiteCommander needed an update in order to work with TinyMCE 5. I wish I was knowledgeable enough to fix SFTP, but it's a bit out of my wheelhouse.

If I'm not going to meet that expectation, what am I going to do? The answer is rather simple — I'm going to use a tool that doesn't have these problems, or at least knows how to tell me about them so I can deal with them.

That probably means a complete conversion to PhpStorm as my primary development tool for my PHP-based Web projects. At least paying for the product puts my skin in the game and entitles me to complain about problems. With VSC, there is no such recourse.