DEV Community

Cover image for IDE’s are stuck in the past
Christian Siemoneit for Codesphere Inc.

Posted on

IDE’s are stuck in the past

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!

Top comments (89)

 
leob profile image
leob

Yeah but that's a completely different discussion, not everyone is using C#, a lot of people nowadays use JS both frontend and backend, whether by choice or imposed on them ... the fact that a program can be faster when you develop it in C#, or C, or Rust, or assembly, isn't relevant in the multitude of cases where you're not even free to choose your programming language.

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković

And that's the exact issue. JS is used too much, even for the things where other solution would be more suitable.

Thread Thread
 
leob profile image
leob • Edited

I don't know if it's an issue, if it works it works ... VSCode is programmed in JS and I hear nobody complain about it, even though it might be a tiny bit faster or more efficient if it was coded in C/C++.

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković

It's not that much of an issue, but once you have multiple Electron applications opened it can become a problem. Yes, we have much more memory available now but I prefer not to fill it up.

Thread Thread
 
leob profile image
leob

Yeah that's true, Electron apps are memory hogs ... I have mostly one or two open, and with 16 GB RAM it's not an issue. But when I have a couple dozen Chrome tabs open as well then at some point I can see memory filling up and my computer getting noticeably hot. Oh well :-)

Thread Thread
 
eugenepisotsky profile image
Eugene Pisotsky

IDEA consumes much more memory than VSCode

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković

IDEA is full-fledged IDE, VS Code isn't.

Thread Thread
 
leob profile image
leob • Edited

Oh I know, Java based IDEs like Eclipse, Netbeans, Jetbrains/IDEA/IntelliJ are such memory and CPU hungry beasts ... it felt like a huge relief when I dumped my Jetbrains IDE for VSCode, it's so much more lightweight.

Only when you're doing actual Java development does it make sense to use a Java based IDE.

Thread Thread
 
leob profile image
leob

"IDEA is full-fledged IDE, VS Code isn't" - well, when I do Javascript or PHP development with VSCode I'm not missing anything, nothing I'm aware of at least ... the only difference with IDEA is that VSCode just feels so much more lightweight and snappy (and on top of that it's free) ... swapped IDEA for VSCode two or three years ago, never looked back.

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković • Edited

I moved from VS Code to WebStorm because I don't have to worry about setup and it has many features which I find very useful for which I would need to add bunch of extensions and spend whole day configuring. Also, it showed as much better solution for bigger projects, especially for refactoring. I don't mind spending a bit more money for good software.

Thread Thread
 
eugenepisotsky profile image
Eugene Pisotsky

Of course, there are some cool things in IDEA (I've been using it for 8+ years, so I know about it), but for example "full-fledged" IDE still doesn't support remote development (youtrack.jetbrains.com/issue/IDEA-...) and I can't event open different projects in the same window (switching between windows is very annoying). I'm not trying to say now, that one is better than the other, I'm saying that both have its own pros and cons, it's not fair to say that one is full-fledged and another one isn't only because it doesn't support features you need.

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković • Edited

It is, because VS Code is not an IDE. Visual Studio is an IDE and IDEA is IDE, but VS Code is code editor. I'm not saying it's a bad thing, but there is a difference between those two. I'm yet to see an IDE which can debug C# like VS.

Thread Thread
 
eugenepisotsky profile image
Eugene Pisotsky

What is the different between code editor and IDE? "catching unused promises"?

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković

Have you ever used Visual Studio?

Thread Thread
 
eugenepisotsky profile image
Eugene Pisotsky

No, but I've used IDEA. You claim IDEA is an IDE and VSCode is not, and I'm trying to understand what's there so special that categorizes them like that

 
eugenepisotsky profile image
Eugene Pisotsky

Why isn't? Features like jump to definition, import suggestions, and so on are supported by LSP. Git, terminal, workspaces, extensions, what is missing?

Thread Thread
 
leob profile image
leob

Nothing is missing ... I say VSCode is an IDE :-) but as lightweight as an "editor"

Thread Thread
 
stojakovic99 profile image
Nikola Stojaković

WebStorm provides better code inspection, refactoring, debugging and CVS functionalities by default (for example, catching unused promises), connection with Jira and many other stuff. It's diff tool is one of the best I've ever seen. Not to mention that all of this is available in IntelliJ IDEA Ultimate so I can use same IDE for both Java and front-end development out of the box.

Thread Thread
 
leob profile image
leob • Edited

Yes, the git diff is quite good, I remember that, but most of the other features that you mention, well I just didn't use or need them. But I won't argue, I guess it just depends on your requirements and personal preferences.

What I like about VSCode is that it's really lightweight, and the utter simplicity of "project management" with VSCode - there just aren't any projects! You can cd to a directory somewhere in a terminal and type the command code . and then you just edit, in VSCode, right what's there ... sweet :-)

I guess the philosophy and the workflow of VSCode just suits me, but well just use what works for you, to each their own.

 
eugenepisotsky profile image
Eugene Pisotsky

Sure, I agree :)
It was the answer on Nikola's comment

Thread Thread
 
leob profile image
leob

haha I understand, it gets confusing :-) and with this whole discussion I think that a number of distinct and unrelated issues are being mixed up, but anyway

Collapse
 
latobibor profile image
András Tóth • Edited

First of all, I think that the node.js dependency and indexing problem is a totally different discussion. I will comment instead on the debugging and managing microservices problem.

Reading some of the comments and being familiar with the problem (corporate secret: blame the frontend guy if they can't run your super-duper microservice cluster locally!) I think the problem is that AWS, Google Cloud, Azure and the rest don't provide integrated solutions. So either they create an end-to-end solution with the IDE shipped or it won't happen. But there are privacy, security and vendor lock-in concerns.

There are still people in 2021 who think you should handcraft every .yaml file for your kubernetes cluster - because "control". People still want an editor that is not provided by big, evil corporation and expect that it will magically work with big, evil corporation's infrastructure. And everyone is figuring out their very own custom solution for managing services, testing them and hoping they can roll back if shit hits the fan.

So I think step number one is not an IDE, but standardizing and completely hiding the variability of the infrastructure. Setup should be as easy as to select with a checkbox if you need a dev, a stage or a production cluster. You press the button and then it creates everything necessary on your local machine to interact with the dev and stage environments. And then the debugging/managing functionality of an IDE will be just pretty UI over existing services. Can't really see without total vendor lock-in.

Collapse
 
eliasgroll profile image
Elias Groll

Agree, we aim to build exactly what you describe.

With the difference that we build the full workflow first, with these steps:

1: private-project-scale,
2: mvp-scale,
vision: production-scale

It's not a vendor lock in because you can just download all the config and deploy it elsewhere (or change and we deploy it for you).

Think of it as a cloud provider that generates your setup where the UI is an IDE :)

Collapse
 
latobibor profile image
András Tóth

That sounds great! Good luck with that!
Maintaining production replicas is a joyless task that takes too much time away from actual coding.

Thread Thread
 
eliasgroll profile image
Elias Groll

Thank you, that is the idea :)

Collapse
 
christian0cfg profile image
Christian Siemoneit

Thanks for this valuable and educated view. The IDE for us at Codesphere is 'just' a front end. Figuring out all the very own custom solutions plenty of resources and productivity. This is unnecessary in 2021.

Collapse
 
leob profile image
leob • Edited

Cloud IDEs/editors sound like the solution ... your whole dev setup in the cloud, and you use just a browser to access it - like your laptop is now just a dumb console, as in the good ol' mainframe days - no need for an expensive or powerful desktop or laptop anymore ... Apple and Microsoft won't like it :-)

Collapse
 
noctumsempra profile image
Leonardo Comerci

Tell me one person who actually enjoys developing on an old PC other than because of nostalgia. None. Cloud IDEs may seem a solution for a novice user who doesn't want or doesn't know how to install a proper IDE. Even these JAVA-based IDEs (i.e: Jetbrains' ones) are way better performant than browser-based IDEs. Not an Universal solution.

Collapse
 
leob profile image
leob

Not yet a universal solution ... I can see the potential advantages, but this still needs maturing, I don't see myself tossing my powerful workstation out of the window anytime soon. But who knows, never say never, I think this will take time.

Thread Thread
 
christian0cfg profile image
Christian Siemoneit

It will start with smaller projects and especially with new projects. But sooner or later the arguments for the cloud are just too compelling.

Thread Thread
 
leob profile image
leob

Spot on ... people won't start out by putting their mission critical stuff in the cloud - they will first try it out with smaller projects, then when they gain confidence they'll commit to it for their bigger projects ... step by step.

Thread Thread
 
christian0cfg profile image
Christian Siemoneit

Fully agree.

Collapse
 
christian0cfg profile image
Christian Siemoneit

Generally I would not disagree to certain parts of your comment. But a) a proper IDE can be cloud-based - why not? And b) this is all not about the IDE only. Having IDE and cloud services connected boosts the productivity of every developer as it leverages the full scale of technology and computing power at any time.

Thread Thread
 
seanmclem profile image
Seanmclem

Personally, I much prefer running on my local file system

Thread Thread
 
christian0cfg profile image
Christian Siemoneit

Sure. Anyone should be able to decide and there will be more and more advantages of a non-local set up.

Collapse
 
athomsfere profile image
Austin French

This. As much as a cloud based IDE solves problems, it introduces ones.

Your application was architected poorly (the story above) and your experience will suck.

But here I sit, on two good development machines. They can handle a good workload. I don't want browser funkiness to interfere with development. Stackblitz for example is fine for a quick POC, so is JS Fiddle.

But to me, neither is as good as a daily driver as VS.

Collapse
 
eugenepisotsky profile image
Eugene Pisotsky

I've been using JetBrains for years and just tried VS Code in cloud, don't see any problems so far. It feels much better honestly, without those endless indexations and other problems.

Collapse
 
christian0cfg profile image
Christian Siemoneit

Yeah, you are right! Coding in the cloud and adding intelligence between IDE and cloud services is the future. I am working on exactly that with Codesphere. Have you signed up for Codesphere? Would be great to see you there and have your feedback.

Collapse
 
leob profile image
leob • Edited

I checked your website, very nice, but it's a bit light on details - for instance:

  • what languages will you support - is it all Javascript based or will you support, for example, PHP

  • how flexible will it be - will it be open and extendable, will there be a Linux terminal, Docker ... will it be possible to install "anything" or will it be more like a walled garden concept?

  • how is this different from e.g. GitHub Codespaces?

More questions than answers, is there more information you can point me at?

Thread Thread
 
jonaszipprick profile image
Jonas Zipprick • Edited
  • Codesphere is optimized for Typescript or Javascript in the beginning. But we'll be expanding in the future if there is large demand for it (Thinking about PHP, or Golang).
  • You have your own isolated workspace where you can install almost anything, but the more you customize the more intelligence you loose.
  • GitHub Codespaces will have to follow a catch-all approach to support the many different project languages and architectures they have on Github. One downfall of that is that they can't really host your application for production. Codesphere has a more opinionated view on your programm, following the "convention over configuration" approach. This allows us a tight coupling of code and infrastructure.
Collapse
 
not4ro profile image
Matteo Notaro • Edited

In IDE performance, sometimes, means a lot and there's no way that a javascript application is more reliable and efficient than a C++/C desktop app

Collapse
 
leob profile image
leob

Well, until you realize that VSCode is a Javascript app (packaged with Electron) ... it isn't that much more than a browser app really, and look how performant it is, it's more than adequate for the great majority of development tasks.

Then when using an online or cloud version of it (with Github Codespaces or equivalent) you'd be completely in the cloud with a browser based IDE. I believe this will be completely feasible, and even enjoyable, in the near future.

Browsers and Javascript engines get ever more performant, even more so when throwing WebAssembly in the mix.

(oh, and apart from VSCode, other mainstream IDEs like Eclipse or Jetbrains aren't even coded in C/C++, they're developed in Java)

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

Well, until you realize that VSCode is a Javascript app (packaged with Electron) ... it isn't that much more than a browser app really, and look how performant it is, it's more than adequate for the great majority of development tasks.

Closes eyes and pinches bridge of nose.

You do realize that the Javascript engine in question is written in C++ running natively on the local machine, right? This is no more a "glorified browser app" than Python is. It's an interpreted language, not a website. Javascript just happens to be the language being interpreted.

And yes, I'm aware that Electron is using HTML and CSS for its styling. Once again — files being interpreted. There are other non-Electron, non-JS GUI toolkits that leverage CSS.

Most of the issues with web browser performance has a lot to do with the web browser itself, and with the particular Javascript engine, not the webkit per se. So this is really an apples-and-oranges type issue.

Thread Thread
 
eliasgroll profile image
Elias Groll

Electron packs a browser which is not much different to your local chrome + it runs a node process.

With a cloud IDE, you can run expensive tasks on many servers.

That said, Codesphere's goal is not to replace your IDE, its meant to replace your cloud provider.

We aim to do this in the long run with lower prices, more automation, more privacy and no setup.

The UI is an IDE because..uhm..yeah we liked the idea :)

Thread Thread
 
leob profile image
leob • Edited

Yes, that Javascript engine is probably written in C/C++, but what's your point then? If you run VSCode on your local machine, then you're effectively running an editor or lightweight IDE in the browser ... and if you'd use a cloud based IDE then you're also running an editor/IDE in the browser ... same, or not?

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Uhm....server round trip time? Unless it loads entirely locally, and then you have the initial download time more or less each time.

Network changes everything.

Thread Thread
 
leob profile image
leob

Well yes okay, the cloud development idea as such assumes that your connection is fast enough, otherwise the whole concept falls flat, so that's a big "if" ... downloading the source code would be one time and then being cached, I suppose.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Except it isn't just the source going over network. It's the data, the response times for operations, etc.

And it isn't just a matter of if your net is fast enough to WORK. It becomes a limiting factor in most cases: the responsiveness of many operations will be limited by network speed, not just local storage IO speed.

Ergo "this is apples to oranges".

Thread Thread
 
leob profile image
leob • Edited

Yeah maybe, there's a lot to be said about all this, but this wasn't the original comment of this thread ... :-)

The original comment said that the performance of a desktop application developed in C/C++ would always be superior over a browser based application. To which I responded that VSCode is in fact a browser/JS based app (and some other IDEs are developed in Java rather than C/C++).

So we're having a different discussion now than the original one.

Collapse
 
jonaszipprick profile image
Jonas Zipprick • Edited

I share your appreciation of performance and reliability.
Computation heavy task like compiling, code-analysis, and search indexing have to be done with a compiled language.
But that's nothing speaking against cloud IDEs.
Moving this computation to the cloud can even be an advantage because you can share dependencies and build artefacts between contributors and just work stronger computers in general.

For the frontend however, an IDE is just a fancy text editor.
I don't see why that particular part couldn't run in the browser.
The major web IDEs (VScode, Atom, WebStorm) are doing that already, running on either Node or Java VMs.

 
latobibor profile image
András Tóth

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.

Thread Thread
 
eliasgroll profile image
Elias Groll

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.

Collapse
 
pablodeveloper profile image
Pablo

What about the privacy? I don’t think companies would like to share it’s source code.

Collapse
 
jonaszipprick profile image
Jonas Zipprick • Edited

Security is always an important topic, especially with IaaS.
Not only can the code get compromised but also your secret keys, customer data, etc..

Encryption everywhere seems to the solution to me.
In practice that means using TLS for network traffic, and various tools to encrypt passwords, code and user data.
You can do static code analysis to prevent data leaks during runtime.

To be honest, those are all good practices even if you work with an inhouse datacenter.
But I know that it can be a hazzle setting all this up yourself, especially the TLS certificates.
Codesphere will manage all of that for you out of the box when you stick to certain conventions.

Collapse
 
christian0cfg profile image
Christian Siemoneit

Very good question. Source code must stay secure and that's the case in the pods. But there for sure will be limitations for some companies.

Collapse
 
leob profile image
leob

Most people already store their code in the cloud (Github, Gitlab, Bitbucket) ... there's not anything new here really.

Thread Thread
 
christian0cfg profile image
Christian Siemoneit

Right you are! Only very few companies with super sensitive data might have limitations (maybe even only by law) to stay away from the cloud...

Collapse
 
etienneburdet profile image
Etienne Burdet

We are leagues away from the level of customization that desktop editors offers : I have dozens of Atom packages and full custom config files. I don't see that happening to a cloud based editors anytime soon.

And cloud editors are slooooowwwww… I'd love to love glitch, codesandbox etc. but when you start opening more than a couple files, performances melt. Maybe yours is different… maybe not :p

Now that your dev environment runs in the cloud is another story, especially when you have a big app. An excellent article on subject can be found here : 

Collapse
 
eliasgroll profile image
Elias Groll

We are already way faster than glitch, gitpod, and codesandbox (lol), mainly because we designed specifically for a cloud env. Codesphere will hardly run on your desktop (though you can mount a fs and use your local IDE's).

It is not meant to replace your local environment but we aim to extend it with a cloud provider which is REALLY build for developers and the UI is a dedicated IDE which you might not have to leave.

Collapse
 
leob profile image
leob • Edited

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.

Collapse
 
romfrolov profile image
Roman Frolov

At Codesphere you can get an early access and a free VM when you sign up on the website! ❤️

 
leob profile image
leob • Edited

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.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

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.

Thread Thread
 
leob profile image
leob • Edited

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 ... :-)

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

Agreed.

Collapse
 
jonaszipprick profile image
Jonas Zipprick • Edited

This was just a personal experience and there are definitly ways to work efficiently on desktops.
For example, I remember having a good time with Java and IntelliJ.
But once I switched through a couple of projects with ~10 microservices and cutting edge technology it took me a long time to set everything up again and again.
Most of the team just settled for a mediocre workflow instead of doing the work of maximizing the benefit from every feature or tool available.
We would have been happy to be able to just click a link and start coding with all the available features.

Addressing your other concerns:

  • Most web apps I work with need internet connectivity to even start up, so I'm already dependant on internet access.
  • Agreed, modern machines are very fast. But those complex, sandboxed apps you are describing are exactly what the web apps I work on have become today.
Collapse
 
lamka02sk profile image
lamka02sk

To everyone using Jetbrains IDEs. Try switching from Jetbrains bundled Java runtime (JBR) to OpenJDK. It is lightning fast.

Collapse
 
bitforger profile image
Noah

Sounds like a problem of trying to use windows as you dev environment. Or you can use docker for you dev environments. I hate cloud IDEs. Every one that I've used has been mediocre and more trouble to work around the trouble of setting up a cloud workspace than it's worth.

Collapse
 
christian0cfg profile image
Christian Siemoneit

Can imagine what you experienced. Which cloud IDE was the worst you tried and why?

 
leob profile image
leob

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!

Thread Thread
 
leob profile image
leob

haha "Teflon undies" I like it :-)

 
eliasgroll profile image
Elias Groll • Edited

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 :)