In-Depth

Visual Studio Code and the Third Wave of Source Code Editing

Imagine platform-neutral, language-agnostic tools for writing code. Awesome, yes, but using tools like Visual Studio Code to compose your programmatic masterpiece will require a bit of rethinking.

• By Tim Patrick
• 02/28/2017

About 20 years ago, Microsoft mushed together several of its development tools into a single package, and slapped the name "Visual Studio" on it. Not only did the new product combine distinct programming languages into one source code editing environment, it brought the entire development process for those languages -- from syntax checking to end-user deployment -- under one licensed umbrella. But software development hasn't always come wrapped up that neatly. A look back across the history of software development shows three distinct waves of coding tools.

The first wave had a distinct wild-west feel, primarily because the standards we now take for granted were still being created and debated. Block-mode editors, such as XEDIT on the IBM 3270 terminal, and imperative-command editors for DECwriters and other paper-based workstations were only an incremental step up from punch cards. Text editors from this era focused on one person and one file, and were designed in part to compensate for the limitations of their environments. The lauded vi editor, for example, enabled you to reduce the number of 80-character display lines down to, say, just seven lines at a time, because anything more would have been maddening over a 300-baud remote mainframe connection.

Tools from this era included Emacs, TECO, the QBASIC-purposed MS-DOS text editor, Windows Notepad, and for the truly desperate, the SED stream editor. These were raw-text-based solutions for a raw-text-based world. The goal was efficient editing of the source code text, without reference to the logic or content of that text. Programmers who jumped between systems were expected to make due with whatever tools could be found in each setting. Enhancements came in the form of macros, complex command strings, and the filtering of buffered text through piped shell statements. Some editors included extensions to make programming in specific languages easier, such as auto-indent within a set of C-language braces, or parenthesis pairing when working in LISP. But in general, these were generic text editors for programmers wedded to a specific platform, and who knew how to compile, link, debug, and deploy their creations outside of the editor environment.

Riding the IDE Wave
Visual Studio represents the second wave of code editing. Such integrated development environments not only combined all of the functions that a programmer needed to create, debug, and distribute software solutions into a unified application interface, they tied programmers to specific platforms and development worldviews. If you were a Visual Studio programmer, you were a Visual Studio programmer all the time, from the moment you rolled out of bed just before noon, until your 3:00 a.m. coding marathon finally came to an end.

The strong integration between the editing environment and the target system led to significant enhancements in tooling and code management, and developers quickly came to expect that the tools would do more and more of the work for them. Systems such as Eclipse for Java and XCode for the Macintosh offered drag-and-drop simplicity for a WYSIWYG computing universe. Although programmers referred to applications as "my source code," wizard-style code generators and snippet templates allowed developers to offshore portions of the coding logic to the IDE itself. While some environments such as Turbo Pascal were cross-platform, the sizeable domain-specific platform needs for each IDE pretty much guaranteed that developers would not wander too far from a given OS. And with the lucrative fees commanded for some team-based IDEs, platform vendors were in no hurry to dissuade this practice.

Coding, Unshackled
Integrated development environments are still de rigueur, but the third wave of code editing and management is quickly washing over developers. Unlike the platform-seated systems from the second wave, these new tools are platform-neutral, language-agnostic and, most of all, hackable. GitHub Atom and Adobe Brackets are two of the key established players in this space. But last year, Microsoft added Visual Studio Code (and its Visual Studio for Mac variant) into the mix.

Microsoft bills its new product as "Code editing. Redefined," and it is. While you are still encouraged to use .NET as the foundation for your applications (now in a cross-platform manner, thanks to Microsoft's acquisition of Xamarin), Visual Studio Code isn't wedded to that framework. Gone are shackles to any underlying platform. But also gone are many of the training wheels that made modern programming accessible to mere mortals. In the third wave of code editing, programmers are expected -- required -- to understand front-end and back-end development across all major computing platforms, as well as the data and communication standards needed to link client and server processes.

Like any major transition, the move from the second to the third wave will put new demands on developers. Programmers and software architects used to the traditional Visual Studio desktop-first-and-why-not-a-mobile-app-as-well way of doing things will need to reorient their mindsets. Here are a few of the paradigms that a system like Visual Studio Code brings to the programming table:

• Logic over Interface: If you like drag-and-drop in your UI design, you'll hate Code. It's called "Code" for a reason: The core tool has no visual editors, and pretty much all of your work is done with source code, XAML content or other text-based data structures. The tool assists developers who create cross-platform, multi-language projects where much of the code is disconnected from UI concerns.
• Separation Between Code Processing and Code Editing: The coding and compilation processes are loosely coupled in Visual Studio Code. For a traditional Visual Studio user, this can be conceptually difficult to grasp, because in the second wave those two code tasks were tightly integrated within the IDE. Each release of Visual Studio has tightened that link, with the "Roslyn" compiler playing an active role in every character you type in a Visual Studio editor window. Visual Studio Code does away with all that, making editing and compilation co-equal yet distinct. Third-party extensions restore some of that integration, but the underlying understanding is that these tools are extending the process beyond the core purpose.
• Shared Content Ownership: Visual Studio Code, with its Git integration, is designed for distributed, open source development, even by anonymous participants. It's a tool created with team-based editing in mind, rather than as an IDE replacement for a lone developer working on a lone project. In fact, the Visual Studio Code preference for showing you the most recent files each time you open it might be off-putting for those who manage dozens or hundreds of related yet independent projects within an enterprise environment.
• Everything as a Service: Visual Studio Code takes a micro-kernel approach to code editing and processing, and any additional features you need hang off of the core engine. This includes features that you think Microsoft would be crazy to leave out. For example, if you want the editor to critique your C# or Visual Basic syntax, you must install an extension. Even the extension model itself isn't a Microsoft-dominated element, because Node.js is promoted as a key means of adding new functionality.
• Open Contracts instead of Persistent Integration. Those who didn't get the message from ADO.NET and MVC that presentation, logic and data need to be separated now need to get on board. By putting the focus on logic instead of on UIs, Visual Studio Code encourages the separation of logic domains. Xamarin and other application libraries extend this by encouraging you to put as little code as possible into the platform-specific projects within an overall cross-platform solution.
• Platform-Phobic Development: While you can use Visual Studio Code to create traditional Windows-bound applications, it works best for cross-platform solutions using generic libraries like .NET Core, or standardized languages and data formats like JavaScript and HTML. Code includes built-in support for JavaScript debugging, but stepping through a traditional Windows application written in C# requires an extension. The Apple-centric Visual Studio for Mac product bills itself as a "mobile-first, cloud-first IDE." That tagline makes no mention of the Macintosh, macOS, or even desktop applications. It is all about the cloud, and the cloud is not a platform-specific environment.

The third wave of code editing, with its preference for text over UI, seems like a move back to the pre-Visual Studio days. But it's actually a giant leap forward, one driven not by vendors, but by grass roots programming trends. Mono (the starting point for Xamarin) came into being because Microsoft had no interest in seeing developers leave its coveted Windows system. But leave they did, and in the process, developers forced Microsoft and other vendors to come with them.

Visual Studio Code, the open source .NET Framework, and the inclusion of non-Microsoft properties like Apache Cordova within Visual Studio 2017 are confirmations of this new community-driven era. Developers interested in working with the latest technologies have no choice but to dive into the third wave head first. That's also true for vendors.