Shulou(Shulou.com)06/02 Report--

This article will explain in detail what are the highlights of the VSCode project. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

Visual Studio Code (VS Code) has achieved explosive growth in recent years, and has become a necessary artifact in the vast number of developer tool libraries. As an open source project, it has also attracted numerous third-party developers and end users, and has become one of the top open source projects. It is commendable in terms of function, ease of use in experience, and simplicity and fluency in the case of a large number of plug-ins.

I am a VS Code user, and I also develop plug-ins for it. Many Java plug-ins in the plug-in market are basically the work of our team, so I have observed a lot of engineering highlights of VS Code in my daily work. Let's discuss them one by one.

Concise and focused product positioning throughout

Did you know that VS Code has a small development team? It's hard to believe that everyone thinks that VS Code is omnipotent, and how can a few people do it with such a powerful tool. In fact, rich functionality is a good illusion, because most of the functions for specific programming languages and technologies are provided by third-party plug-ins, and the core of VS Code is always very concise, which tests the product team's ability to handle things: they are overdone, overstaffed, and understaffed; underdone, too weak, and unused. Their team chose to focus on the development of core functions to provide users with a concise and smooth experience, and put this idea through every aspect of product development. In my opinion, this is the first bright spot.

The first bright spot is also a difficulty, because "simplicity" in the final analysis is the "form" of the product, what is more crucial is the pre-problem-the positioning of the product, what problem it solves in the end. From the user's point of view, this question can be translated into the following points-why do we need a new tool? Is it a code editor (Editor) or an integrated development environment (IDE)? Let's see what the project leader has to say:

Https://link.zhihu.com/?target=https%3A//www.youtube.com/watch%3Fv%3DVs3AGfeuNKU

Video screenshot-Erich describes the positioning of VS Code: editor + code understanding + debugging

For those of you who are unable to watch the video, please take a look at this screenshot, which describes the positioning of VS Code: editor + code understanding + debugging. This is a very restrained and balanced choice, focusing on the "most commonly used" features of developers, while striving for simplicity and efficiency in the form of the product. Judging from the results, this positioning is quite successful.

Under the guidance of this positioning, these engineers came up with VS Code. The relatively small feature set enables developers to improve code quality, and end users get a tool with excellent performance, which is an important reason why VS Code stands out from the rest of the editors. About Excelsior, you can refer to this blog post, which records the process of VS Code's re-implementation of Text Buffer, but also shares the process of thinking. Because of the high degree of restraint in product positioning and team responsibilities, team members are able to spend their time on such issues and write code that stands the test.

At the same time, smaller teams also make team members uniform in behavior, which is particularly evident in community interaction. People can go to GitHub to see their Issues, and requests and feedback beyond product positioning are basically declined or transferred to third-party plug-in projects, which can be said to be very focused.

See here, everything seems to be all right, but the problem is, millions of programmers, you use Node I use Go, you do front-end I do backstage, VS Code how to meet these various needs? Witty you have already answered-- a large number of plug-ins. So let's take a closer look at how VS Code runs a huge plug-in ecosystem.

Plug-in model for process isolation

It has become commonplace to extend functionality through plug-ins, but how to ensure that plug-ins are as good as native features? History tells us that there is no guarantee. You can refer to Eclipse, the plug-in model can be said to be very thorough, the functional level is omnipotent, but there are several annoying problems: unstable, difficult to use, slow, so many users switch to the embrace of IntelliJ. It can be described as a plug-in for success and a plug-in for failure. The essence of the problem is information asymmetry, which leads to inconsistencies in the thinking and quality of code written by different teams. In the end, the user got a messy and stuck product. So it can only be a good wish for the plug-in to be unified with the native functionality in terms of stability, speed, and experience.

Let's take a look at how other IDE does it. Visual Studio takes care of all the functions on its own, and does well, leaving others with nothing to do, which leads to its reputation as "the first IDE in the universe"; IntelliJ is similar to it, out of the box, plug-ins are optional. So it seems that it's a good way to take care of everything on your own, but did you know that there is a huge engineering team behind Visual Studio, which is obviously not something that VS Code can handle. They chose to let everyone do plug-ins, so how to solve the problems encountered by Eclipse?

A little bit of knowledge is shared here-the developers at the core of Eclipse are the early VS Code team. Well, so they didn't step into the same river twice. Unlike Eclipse, VS Code chose to put the plug-in in a box.

The first problem to be solved in this way is stability, which is particularly important for VS Code. We all know that VS Code is based on Electron, is essentially a node.js environment, single-threaded, any code collapse is a catastrophic consequence. So VS Code simply does not trust anyone, put the plug-ins into a separate process, let you toss about, the main program is in order.

Plug-ins are isolated from the main process

The VS Code team made this decision for a reason. As mentioned earlier, many people on the team are actually the old part of Eclipse and naturally think deeply about Eclipse's plug-in model. One of the design goals of Eclipse is to push componentization to the extreme, so many core functions are implemented in the form of plug-ins. Unfortunately, Eclipse plug-ins run in the main process, any plug-in performance is poor or unstable, will directly affect the Eclipse, the end result is that people complain that Eclipse is bloated, slow, and unstable. VS Code successfully solves this problem by achieving physical level isolation based on the process. In fact, process-level isolation brings up another topic, that is, the isolation of the interface from the business logic.

UI rendering is isolated from business logic and provides a consistent user experience

The problem after "instability" is "difficult to use", specifically the chaotic interface and process, which is due to the "inconsistency" of the interface language between plug-ins, which leads to an unusually steep learning curve. And there is no unified solution to the problem. VS Code's approach is to give plug-ins no chance to "invent" new interfaces at all.

As shown above, plug-ins are locked in the Extension Host process, while UI is in the main process, so plug-ins naturally cannot tamper directly with the user interface. VS Code manages all user interaction portals and sets standards for interaction. All user operations are converted into various requests sent to the plug-in. What the plug-in can do is respond to these requests and focus on business logic. But from beginning to end, plug-ins can't "decide" or "influence" how interface elements are rendered (colors, fonts, etc.), and it's impossible to play dialogs.

VS Code for the control of the user interface can be said to be cautious to abnormal, people who have done plug-ins understand, interested students can dig deep into the history of TreeView, will have a more intuitive experience. At first glance, third-party developers are stuck to death, doesn't this limit everyone's creativity? I would say that this practice is closely related to the background of the team, and a different group of people are likely to fail. They were successful because the team worked hard in the field of development tools for many years, and they translated their experience into ideas that eventually translated into VS Code's interface elements and interactive languages, and as a result, they were very popular.

The complete separation of the interface and business logic makes all plug-ins have consistent behavior, and users get a uniform experience. Not only that, this consistency of interface and behavior eventually translates into another "great" feature-Remote Development, which we'll discuss later. Next we are going to talk about another initiative of VS Code-- Language Server Protocol.

LSP-- text-based protocol

The previous article mentioned two features of VS Code positioning: code understanding and debugging, most of which are implemented by third-party plug-ins, and the bridge between them is two protocols-Language Server Protocol (LSP) and Debug Adapter Protocol (DAP). The two are highly similar from a design point of view, so let's focus on the hottest LSP. First of all, why do you need LSP?

Full-stack development has long become the mainstream of this era, and software practitioners are increasingly not limited by a particular language or technology, which also poses a new challenge to the diamond in our hands. Take Chestnut, for example, I use TypeScript and node.js as the front end, write background with Java, and occasionally use Python to do some data analysis, so I probably need a combination of tools. The problem is that I need to switch frequently between tools, which is inefficient from the point of view of system resource consumption and user experience.

So is there a tool that can handle all three languages in the same workspace? Yes, VS Code-- supports multilingual development environments, and multilingual support is based on Language Server Protocol (LSP). The protocol has achieved unprecedented success in just a few years. So far, there have been 100 implementations from Microsoft and other large factories and communities, basically covering all the mainstream programming languages. At the same time, it has been adopted by other development tools, such as Atom, Vim, Sublime, Emacs, Visual Studio and Eclipse (click here for a complete list), proving its excellence from another perspective. What is more commendable is that the protocol is lightweight and fast, which can be said to be the killer feature of VS Code, and it is also one of Microsoft's most important IP. Wow, it's powerful and lightweight, and it's all a scam anyway, so let's see how it does it.

First draw the key points: 1, moderation design 2, reasonable abstraction 2, thoughtful details.

Let's start with design (Design), which is a common problem. If I were to design something that supports all programming languages, the first reaction would probably be to create a superset that covers all language features. Microsoft has tried to do this, such as Roslyn--, a language-neutral compiler based on both C # and VB.NET compilers. As we all know, C # is very rich in language features, and the fact that Roslyn can support C # shows its strength. So the question is, why isn't it widely used in the community? I think the root cause is the side effect of "powerful": complex and subjective (Opinionated). Syntax tree alone is already very complex, other features and the relationship between them is even more prohibitive, such a behemoth, ordinary developers will not easily touch.

By contrast, LSP obviously takes compactness as one of its design goals, choosing to be the smallest subset, implementing the team's consistent style of moderation. It is concerned with the physical entities (such as files, directories) and status (cursor location) that users most often deal with when editing code. It does not try to understand the characteristics of the language at all, and compilation is not its concern, so it naturally does not involve complex concepts such as syntax trees. It is not achieved in one step, but gradually developed with the iteration of VS Code functions. So since its birth, it still maintains a small figure, easy to understand, the threshold to achieve is also very low, quickly gained widespread support in the community, various languages of Language Server (LS) blossomed everywhere.

Small to small, functions can not be less, so abstraction is very critical. The most important concepts of LSP are actions and positions, and most of LSP's requests express "perform a specified action at a specified location." For example, the user hovers over a class name to view the relevant definitions and documentation. At this point, VS Code will send an 'textDocument/hover' request to LS, and the most critical information in this request is the current document and the location of the cursor. After LS receives the request, after a series of internal calculations (identify the symbol corresponding to the cursor location, and find out the relevant documents), find out the relevant information, and then send it back to VS Code to show to the user. This back-and-forth interaction is abstracted into Request and Response in LSP, and LSP also specifies their Schema. From the developer's point of view, the concept is very few, the form of interaction is very simple, and it is very easy to implement.

Seeing here, you should have a better understanding of LSP, which is essentially glue that binds VS Code to LS in various languages. But it is not ordinary glue, but very tasteful glue, which is reflected in the details.

First of all, this is a text-based protocol, which makes it easier to understand and debug. With the success of HTTP and REST, it's hard to imagine what it would be like if it were a binary protocol, and even the SOAP of the same text protocol is long gone, enough to illustrate the importance of "simplicity" in building the developer ecology.

Secondly, this is a protocol based on JSON. JSON is arguably the most readable structured data format. If you look at the configuration in each code repository, you can see how correct it is. Does anyone still use XML in new projects? Once again-"simple".

Third, this is a JSONRPC-based protocol, due to the popularity of JSON, the major languages have excellent support for it, so developers do not need to deal with serialization, deserialization and other problems, this is the implementation level of "simple".

As can be seen from these details, the VS Code team has a very accurate grasp of today's technology trends, and their decisions take full account of "simplicity" and firmly capture the hearts of community developers. So say the important thing three times:

When doing design, you must tend to be simple.

When doing design, you must tend to be simple.

When doing design, you must tend to be simple.

Integrated Remote Development

In May this year, VS Code released Remote Development (VSCRD). With it, we can open a VS Code workspace in a remote environment (such as virtual machine or container), and then connect to work with a local VS Code. The following figure illustrates its operation mode:

VSCRD essentially improves the experience of remote development. Compared with common remote desktop sharing, the specific improvements are as follows:

Quick response: all the interactions of VSCRD are completed in the local UI and respond quickly. Because the remote desktop transmits screenshots, the round-trip delay of data is very large, and stutter is the norm.

Follow local settings: VSCRD's UI runs locally and complies with all local settings, so you can still use shortcuts, layouts and fonts you are used to, avoiding productivity overhead

The data transmission overhead is small: the remote desktop transmits video data, while the VS Code transmission is operation request and response, and the overhead is similar to that of the command line. The situation of Catton is further improved.

Third-party plug-ins are available: in the remote workspace, not only the native functions of VS Code are available, but all the functions of third-party plug-ins are still available; for remote desktops, you have to install them one by one

Remote file system is available: the remote file system is fully mapped to the local, which is similar to the other.

So what magic operation did VSCRD do to achieve the above effect? Take a look at its architecture diagram:

In fact, the answers are all mentioned in the previous article:

Plug-in model for process-level isolation

Extension Host (that is, VS Code Server in the figure) is physically separated from the main program, so there is no essential difference between running Extension Host remotely or locally.

UI rendering is logically isolated from plug-ins, resulting in uniform plug-in behavior

The UI of all plug-ins are rendered uniformly by VS Code, so there is only pure business logic in the plug-in, and the behavior is highly unified, so it doesn't matter where you go.

Efficient protocol LSP

The two major protocols of VS Code, LSP and DAP, are very concise, which are naturally suitable for the situation of high network latency, and are perfect for remote development.

There is no doubt that the VS Code team's architectural decisions are very forward-looking, and at the same time, their grasp of the details is impeccable. It is precisely because of such a solid engineering foundation that functions like VSCRD were born, so I think this is a comprehensive work.

For students who have not yet tried VSCRD, here is Amway, which is very useful in the following scenarios:

The configuration of the development environment is very tedious, such as the development of the Internet of things, you need to install and configure various tools and plug-ins. In VSCRD, a remote workspace template can be done, and it is very easy to install additional tools, that is, to change the Dockerfile. Here you can find templates for commonly used programming languages and scenarios.

Local machines are too weak for some developers, such as machine learning, huge amounts of data, and computing requirements. In VSCRD, you can directly manipulate the remote file system and use remote computing resources.

Last

VS Code is like a dazzling star, attracting thousands of developers to contribute to it. From the success of VS Code, we can see how many miracles good design and engineering practices can do. Looking at the software industry, the models at all levels are constantly refreshed, which not only makes people excited, but also requires practitioners to constantly improve their skills. From the perspective of personal learning, understanding the causes and consequences of the birth of these models and understanding the decision-making process in engineering practice is very helpful to improve engineering ability.

A colored egg is attached. Please pay attention to the list of authors of the book Design Patterns. Yeah, that's him. You're welcome.

This is the end of the article on "what are the highlights of VSCode engineering". I hope the above content can be helpful to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.