With vscode there are some clever architectural choices they made to create a near native experience. They use stdin &#x2F; stdout integration between native services (like those for Go programming language) and the editor itself.  It&#x27;s anothe form of reuse for the libraries that already do intellisense, compilation, or other syntax-specific functions.<p>In the 2nd and 3rd generation codenvy systems, we tried to duplicate some of the JDT capabilities for Java directly within the browser with webworkers. We had to write that in JavaScript.  I believe this is how C9 handles their support for HTML, CSS, and JavaScript.<p>We had pretty decent support, but there were all sorts of issues: having to rewrite JDT services is nearly impossible and really the domain of language teams, the browser has limited context where many intellisense services need access to multiple directories and meta information, and there were some performance issues in certain edge cases that are hard to resolve without having certain I&#x2F;O and cache mechanisms (which are readily available on file systems).<p>So the VSCode model of reusing the language services and then layering on a stdin &#x2F; stdout protocol is pretty smart.  We are doing a similar approach with Che, but instead of stdin &#x2F; stdout, we are packing a restful interface on top of the JDT &amp; JavaScript services.  We see some potential to consolidate vscode &amp; other approaches into a multi-language intellisence server, powered by REST + stdin + stdout.  That would be really fun to have all programming languages remotely accessible through a common protocol.