If I was asking whether Visual Studio Code (VSC) can replace Expression Web as my primary development tool, the answer depends on perspective.
As I mentioned in my earlier article, Expression Web: The Final Denouement, EW has some extremely nice features, not all of which are available in VSC.
VSC cannot be a replacement for EW. In spite of that, I am beginning to see how VSC can become my central development tool, with EW as an adjunct for those unique features that I acknowledge will never be a part of VSC or, for that matter, any other contemporary tool.
Key Expression Web Features
My "Denouement" article lists key areas of Expression Web that are very good. Here's how VSC stacks up for just those features.
Multiple Instances: VSC can do it. I haven't tested fully yet but it appears to work in the way one would expect. It's probably more reliable than EW because EW's aging FTP engine can sometimes become confused when multiple instances are running, especially if the publishing destinations are at the same hosting company.
Projects as Web Sites: In EW, a project is a self-contained folder. That works just fine in VSC.
Publishing: The publishing system in EW is excellent, better than any other tool I've used. With VSC, publishing is not built in and requires an extension. I'm using what appears to be the most popular extension, SFTP by liximomo, and it seems to work well. I believe it may handle multiple publishing destinations but I have yet to test that. What it lacks is a user interface. This points to a key difference; everything in EW is surfaced, while many things in VSC are handled by text configuration files, most often (maybe always) in JSON format.
Dynamic Web Templates: No. I need to get over this. I will. It's not really a ding against VSC because no other product can do it except for Dreamweaver.
I'll eventually deal with this by eliminating my dependence on DWTs. In the meantime, I can still use EW to manage the template; VSC won't care. And once I'm past needing DWTs, I can also get rid of all the metadata files EW keeps in folders with the _vti_ prefix. There is one of those folders for every folder in a project and each of those folders keeps a ghost version of every file in its associated folder, thus doubling the number of files in the site.
Design View (WYSISYG): No. When needed, I'll simply continue to use EW. It can't handle modern HTML5 and CSS3 but as long as I'm just using it for light WYSIWYG, it will remain a useful tool for static HTML.
Search & Replace: EW has an excellent, comprehensive search capability that is surfaced in a single dialog. I complained loudly about Rapid splitting search into two dialogs, Find and Find in Files. VSC has the same bifurcation and I don't like it in VSC any more than I did in Rapid. Actually, it's worse than Rapid because the dialog is incredibly tiny:
This is part of the "Zen" or style of VSC - many things are minimalist. On the flip side, this is a search that happens as you type, so you get real-time updates of the number found and there are up and down arrows so you can move quickly between them. The found results are highlighted in the file. For find in files, the action happens in the left sidebar but again the results are displayed as you type, in real time, with the results displaying in the sidebar.
I think I will be able to adapt quickly to this style. I will say one thing - I searched for "fastie" in my personal site and VSC found 10,000 instances in 1,773 files in less than 5 seconds. Fast, so to speak.
Key Visual Studio Code Features
It's too early for me to speak intelligently about VSC features. I've got 20 years of experience with FP/EW, 30 years of experience with other Microsoft code editors, and 4 years of experience with Rapid. For VSC, two months. I've got a lot to learn. Let me just mention a few things.
Price: Yes, I consider it a feature. VSC is free. For any use, private or commercial.
Extensions: Bolt-on features don't mean much if the editor isn't popular. The very large library of extensions is evidence that VSC is a strong product here to stay. It's also a piece of luck for me; without extensions, VSC would not be an effective PHP editor and would lack publishing capabilities.
Git: I use a crude form of source code management that is largely manual and does not enable me to track changes well. Git is now built in to VSC and, given Microsoft's acquisition of GitHub, is something I should latch on to.
Editing and Intellisense: VSC is a very, very good editor. It's fast and responsive and in my limited experience it seems to do a useful thing at exactly the right points. It also acts like a Microsoft editor and thus I have more "finger familiarity" with it than with Rapid PHP or PhpStorm.
PHP, the server-side language I use, is a second-class language. You would not know this from looking at VSC's home page, which scrolls a long list of languages as if they were all supported equally. But on the FAQ page, the distinction is clear.
Thus Intellisense for second-class languages depends upon the skill of those providing the extensions. I've been testing VSC for five years and it's only recently that I decided the PHP extensions were strong enough to support my editing. Even so, there are some Intellisense behaviors that show the work is not quite done.
|File Explorer on the left, tabs with editors for code in the center, and the "Minimap" on the right.|
User Interface: As I mentioned above, VSC "feels" like a Microsoft editor at one's fingertips. Yet it does not have the historical UI one expects from the Visual Studio family. Rich dialogs are replaced by minimalist dialogs that present almost a command line interface. That is certainly a different look for Microsoft. It also takes a little getting used to. Rich dialogs provide many hints about what is needed, while command lines provide none.
In spite of that, and once one starts to find all the pieces, the UI turns out to be relatively clean. It's shown in dark mode in the image to the right (click to see full size). On the left is the Explorer area, which displays a variety of items controlled by the icons on the far left. In the middle is the tabbed editor area, in this case showing a PHP file. On the right is the "minimap," which shows a representation of the entire file shrunk to illegibility.
The minimap is used to indicate where you are in a given file and to highlight problems, if any. Clicking on the minimap takes you to that area of the file. Despite its lack of readability, if you are familiar with the file you're editing you can usually find the general area you want and thus navigate to it quickly.
One notable absence is toolbars, a staple of Windows apps for decades. I know part of that is due to the cross-platform nature of the tool; it is available for Windows, MacOS and Linux (with Ubuntu leading the pack). While all these systems have become very close in feature, there is a lowest common denominator at work. It's easier to ignore UI features that will take a lot of development effort, which is at least understandable.
What's the substitute? Keyboard shortcuts. The other day I was trying to figure out how to have the editor comment out some code. It took me a while to find it, while in editors with toolbars I would have quickly found it visually. The shortcut in this case turned out to be Shift+Alt+A but there are four different shortcuts for variants. One needs a reference card.
That's more evidence that the editor has a command line orientation. I'm not saying that's bad; I'm just saying you gotta have that reference card. It's only a page but its 120 entries are in fine print ; that's not all the shortcuts. Also see Key Bindings for Visual Studio Code.
Syntax Checking: This one caught me by surprise. Even though I had used VSC before, it is only recently that I starting using it full time and thus really began to grasp how it worked.
In the User Interface image above, you'll notice that I've deliberately made a coding error by omitting the semi-colon at the end of one of the lines. Within a second, VSC lit up everything to point to the error. Within the editor itself, VSC put a wavy line under the next line because that's where it realizes a syntax error is present. Then it turns the name of the file in the Explorer red and puts a bullet next to it. To make sure you can find it again if the explorer list is collapsed, VSC also puts bullets next to the containing folder and to the entire folder structure above. Finally, VSC puts a red bar across the line in the minimap.
While doing work on a CSS file, VSC picked up a syntax error, something I had missed and that had been hanging around for a long time. I had opened the file intending to add something new but when VSC lit up, I immediately set after the error. Embarrassingly, VSC also presented warnings reflected by amber markings in the minimap,. I say I was embarrassed because these flaws do not affect rendering, they are simply bad form. I'm not sure how I feel about my editor reprimanding me.
Rapid PHP 2020 did not find this CSS error. PhpStorm 2020 did. I should also note that while VSC reprimanded me with 8 warnings, PhpStorm found 8 errors, 33 warnings, 20 "weak" warnings, and 60 typos. I've looked at this before in PhpStorm and, frankly, find it exhausting.
Bottom line: VSC syntax checking is lightning fast and perfectly targeted, even for second-class languages like PHP. It was better than I expected, better than Rapid PHP, and if not the equal of PhpStorm, close enough for my work.
Does VSC Stack Up?
It's too soon to tell for sure. The casual notes I've provided here only begin to scratch the surface of this powerful editor. And I've not stressed it with my normal workflow, which involves having multiple instances open to work on multiple projects at a time. That's a common scenario for me; my clientele is small businesses and it's common to have multiple requests pending for minor changes.
That said, I'm using VSC every day now. I doubt that would be true if I had any major reservations.
I'm looking forward to pushing VSC harder and getting more comfortable with it.