As the world was still relishing the success of Jetbrains IntelliJ over Eclipse, and other tools, a quiet horse was making strides. Sublime Text was making inroads into a small but influential community of people doing demos in the conferences.
And, before anyone realised, everyone was asking about the need for more complex IDEs when the simplicity, speed and feature richness of a text editor can cover 80% use cases, why bother.
But, the market was for Sublime to loose. It did not add features fast enough. Soon, Atom arrived on the scene, and took over the void felt by the developers. But, both Sublime, and Atom, focused on the Editor workflows.
Language Server Protocol became the defacto standard, and the energy behind it is simply overwhelming. Look at this list, maintained by Microsoft , for a hint on the breadth of language support on VS Code is, largely driven by the community. The number of tools using this protocol is also interesting.
And this one, community driven, ( langserver.org ) also shows the maturity and coverage. Its been done before, but this was a design pattern whose time had come, as Jetbrains mentions in their post, written in 2019, related to the Scala plugin .
VS Code achieved things faster than I anticipated. And innovation, as is always the case, seeds more innovation. So, we now see a project like Eclipse Che ( eclipse.org/che ) being created to enable modern development environments, that are:
- Mirrors, or very close to, the production environment, because everything is deployed in containers and Kubernetes is king in that space
- Source Code can be made better compliant with company security posture, because everything can be hosted in controlled infrastructure.
One company, offering a product in this space, is Coder .
Another product, from the makers of VS Code, which is not available as of this writing, but will get released soon, is Github Codespaces .
As more and more build/validation/package/deploy stages move to the CI/CD pipeline, the requirement to run regression test cycles as a pre-requisite to every merge will become feasible. There will be more advantages, as developers build their environments they will innovate.
There are offerings from likes of DigitalOcean (referral link) and Linode (referral link), where one can, at very low costs of $10/month, host Docker. Managed Kubernetes environments, that need a little more infrastructure, is a more widely available service. The infrastructure costs a little more than the vanila
docker-compose based setups.
Employers will be able to quickly bootstrap new joiners, without having to spend '000s of dollars on expensive, fully loaded laptops. Even the minimal (8gb/256gb) ones should be able to support local IDEs with remote Language Server instances.
I have been experimenting with a local Docker based setup for a little while, and I am very happy with the isolation, speed of spinning up and upgrading, and the fact that I am replicating "exact" environments on my teams desktops. Have found so many best practices being then implemented in code (specifically secrets, but in general the differences in dev and prod) that would otherwise have found only when the application when to production in a container.
Having said all this, every team is different from others, and they evolve their work strategy as they mature. If you are looking for help in migrating your team to such tools, do reach out to me.
This blog was originally posted on my site: blog.mandraketech.in