Developers have long stuck to their own treasured IDEs like baseball players and their lucky socks. Back in June, Codenvy, Microsoft and MuleSoft made a somewhat innocuous announcement that (long term) could eliminate a lot of the variances that currently exist in IDEs and other software development tools.

From the outside, the Language Server Protocol (LSP), which is hosted on Microsoft’s GitHub page, would seem to be some sort of highly technical back end for editors. But inside, the LSP is part of the larger trend inside of the new API-driven economy toward reusability and computer-readable specifications.

The LSP provides a JSON-based way of defining languages for Visual Studio Code. That means developers can code up syntax, type and integration information into a language server, which then makes these features available to the consuming IDE.

(Related: Interest in C is plummeting)

Today, this works with Visual Studio Code, Eclipse Che and Eclipse IDE. In the future, however, any development tool and IDE would be able to add LSP support, and in doing so provide common and consistent language support.

To date, there are language servers for several languages and variants: Red Hat has built an Eclipse-like Java language server, Palantir has contributed a Groovy server, and Microsoft created a C++ server.

Uri Sarid, CTO of MuleSoft and creator of the RESTful API Modeling Language (RAML), has worked with his team to provide a RAML language server. “We’re still pretty early. As we look to taking the API capabilities we have now and breaking them up into smaller pieces—like the RAML auto-completion capabilities—and packaging it as its own library, you can offer it as an LSP-compliant package that can get injected into various IDEs. We’re pushing forward, but also waiting for other IDEs to adopt this,” he said.

And that IDE adoption is the key to the success of the LSP. The benefit of unified language supports across tools is only realized if those tools take the time to add LSP.

Sarid said, “For a long time, IDEs, especially for typed languages, had these capabilities which developers relied upon to help guide them. In some ways the world of APIs is very similar to that. You have a bunch of distributed systems, but if you can make them act like libraries in your code with well defined interfaces, you should be able to give the same kind of guidance to developers to help them assemble the pieces correctly, just like we used to do for code.

“LSP is a way to formalize what those language services are, and what are the APIs for consuming those language APIs themselves.”