IDE’s come from a time in which the majority of what we programmed were monolithic desktop applications.
But that’s not the reality anymore for many of us.
As web developers we now work on distributed systems consisting of many different microservices.
Let me give you an example: Not long ago we were all happy to listen to our music with Windows Media Player, a nice and simple desktop application that could probably build and run in any C-IDE without many problems.
Today many people use Spotify or similar streaming services to not only listen to music but also share and interact with the artists.
I don’t even want to imagine the hassle of setting up a development version of such a big software system.
A typical workflow of mine
Here is an example of the Codesphere co-founder Jonas. It is about setting up a new project from one of his friend. Spoiler: It’s not a great experience.
Because I recently got a new development machine I set up my keymap, installed a couple plugins, pulled out my split keyboard and I was able to do my code changes at a reasonable speed (ignoring the occasional wrong import suggestion I always seem to get).
Now the time comes to test my changes.
I begin with installing the project dependencies and at this point my hands begin to sweat as the CPU fan of my modern 2k€ laptop begins to spin at its maximum rate.
The IDE has started indexing a couple million of files and is burning away my battery at light speed. After a couple of minutes my computer becomes responsive again and I try to start the build and run script. But it’s not working!
It looks like some of the linux commands from my colleague don’t work on my windows computer. Also, I accidentally change the line endings from LF to CRLF on the files I modified, which will probably cause a headache later on when I try to deploy this to the production linux infrastructure.
Finally I get some of the microservices I want to test running. They are complaining about wrong credentials and about being blocked by the Azure firewall.
So I whitelist my daily changing IP address and gather the development secrets from the companies file share.
Even now: one of the services is still not fully healthy.
I ask my friend for help… He tells me that that particular service manages cluster resources and can only be run in a kubernetes environment and that I would have to install it if I wanted to debug that.
At this point my morning is over and I leave the desk to get a second coffee and ask myself:
‘Integration’ is a significant part of I(ntegrated) D(evelopment) E(nvironments) — so why are IDEs disconnected from our workflows today?
Let’s fix this
As web developers we always try to port as many desktop apps as possible to the browser.
After all, the browser seems to have solved the problem of software distribution allowing users to work at any place and any time.
Anywhere: Imagine being able to code anywhere, even on your Android tablet without having your lap burned from the CPU quickly burning away your battery.
Anytime: New collaborators could simply click a link and start coding right away. No individual setup process for the specific hardware.
There are more advantages to think of like real-time collaboration, having your settings synced everywhere and simplifying the integration of cloud services just to name a few.
At Codesphere we make this vision a reality.
Do you know the limitations and painpoints Jonas is describing in his article? Let us know! If you enjoyed reading this article, feel free to share it and follow us!
Latest comments (80)
"my windows computer"
found the problem : D
Never told you to throw it out :) And sorry I did not say that clear enough, I was talking about production code.
It does not front any cloud, it is running on its own data center in germany, soon in other parts of the world as well.
I would love to hear your feed back If you can spend some minutes when we launch :)
Note that you are deploying to serverless, no databases, no real time messaging. It's a fairly simple task.
Also I don't know how VS works with telling you about hot spot code, screenshot testing, privacy testing, security testing and so much more :)
There is always something to be done :)
VS works as well for NodeJs and many other languages.
Many programming languages can be used the same way with serverless on AWS, GCP, Azure, Vercel, and Fission...
Also feels much like an IDE with great plugins and tmux :)
Server costs are cheaper than DEV time cost most of the time. Also efficiency comes late in the game, when you have a huge established clientele. And then you can also choose to rewrite only the ones that would really-really benefit from those languages.
At first, we build dedicated tools for TypeScript, JavaScript and NodeJs.
We chose it, not because it is our favorite language, but because it is highly adopted while the tooling is (because it is so new) a pain in the ass.
We are investigating support for other languages like Java, PHP, Deno, and Go which may come in the summer.
Personally, I see languages really as tools and I don't understand all the religion around some of them.
Use the right tool for the job, and if the job is being highly productive in a browser + microservice environment, TypeScript feels very reasonable (e.g. same language in frontend and backend, OOP, async...).
PS: We will be cheaper than your avg. cloud provider as well.
I just added a comment elsewhere (if you can find it) explaining that in my opinion the premise of the article is flawed, and that a large part of the comments and discussion are highly confused and are mixing up a number of things ... the problem isn't with IDEs at all, the problem is about setting up and maintaining your development environment/runtimes. Whether the IDE runs in a browser or on the desktop or somewhere else is totally irrelevant!
haha "Teflon undies" I like it :-)
I agree that the article is flawed, but not for the reasons that you mention ... the article is flawed because it claims that there is a problem with IDEs, and then it goes on to describe a problem with the deployment of the app and its services on a local development workstation, so the hassle of setting up and maintaining a local test/dev environment - THAT is the problem at hand ... so, clearly, and obviously, this is not a problem with the IDE as such, therefore the title of the article is a misnomer IMO.
So the issue is not one of "IDEs being stuck in the past" or whatever nonsense - the problem is with the burden of setting up and maintaining a test/development environment on your "local" machine - and the solution (supposedly) is to move that environment into the cloud (which at the same time also makes your dev environment portable across machines, if for instance you want to access your stuff "on the go").
So that is the problem to be solved (if we assume it is a problem) ... "cloud" would be one answer to that, Docker and so on are other solutions. The question where your IDE runs and what it looks like, whether it's browser based, or a desktop app, or whatever, is really inconsequential, as long as you have a mechanism to get at your "stuff" (source code and running app) in the "cloud" or in "Docker", or in whatever environment it runs.
Well, isn't that the best of both worlds then, and a smart strategy? Use native code for stuff where it matters (the language servers), and JS where it's more than adequate (the UI) ... it's the end result that counts, and we can't complain there about VSCode.
Maybe to some degree. I was responding to the "it's a glorified browser app" assertion I hear all the time. Electron is only superficially similar due to sharing some components of the webkit.
As to C/C++ vs. Java or Javascript: an assembled language is always going to be capable of better performance than an interpreted language. A JIT- or AOT-compiled (to machine code) language implementation will be close to an assembled language in potential performance, although the startup time will be by nature slower.
What complicates that is how well the code is written in terms of performance. Badly written C++ will still be slower than well-written Python (specifically CPython) purely because of the principles of algorithmic efficiency.
VSCode is faster than some C++-based IDEs for that reason, not because Electron is particularly prone to being greased lightning.
Sure, we all know about compiled versus interpreted and the pros and cons of those, but Javascript running in V8 is not entirely just "interpreted" or it would be slow as molasses (which it isn't) ... it's a JIT compiler :-)
What I see (and what you concede) is that the speed of VSCode is more than adequate in the great majority of cases. But, I think the whole premise of this article that there is an "IDE problem" is flawed ... I've elaborated that in another comment, so I'm not gonna repeat that here. I think that discussion is more interesting than whether your IDE has to be coded in JS with Electron or in Java, or in C/C++, or in Rust, or in ... :-)
Agreed.