What's the Future of IDEs?

- CI servers could do much more and their findings should be merged back into the IDE UI: integration tests, CVE analysis, tracking possible merge conflicts from concurrent feature branches<p>- Bake the distributed nature of the software process into the IDE. What environments and servers is the developed software running on? That information is currently spread out over multiple tools and should be synthesized and presented coherently from the IDE, so one could dive straight from it&#x27;s IDE into a problematic server and start debugging using the appropriate code without having to spend 2 hours reproducing the build configuration locally.<p>- Finally, _Team Workflow_ is especially taken for granted, ground rules being implicit in most organisation but having the most actual impact on team productivity. How long should a PR take? How is the software qualified for release? How should new git branches be named? Important, basic stuff that changes across teams and projects that should be formally documented to lower friction for newcomers and small-time contributors. This would turn perceived arbitrary &quot;gatekeeping&quot; into a rational, safe processes.

I&#x27;ve worked in 4 different software shops over the last 15 years. My general observation is the developers who rely on heavily automated&#x2F;magic tooling are significantly outclassed by those who use the terminal + a basic text editor.<p>Terminal + Vim or Emacs&#x2F;VSCode (depending on configuration) is not only all you need, it also produces developers who understand the systems they work with.<p>I know a lot of people will disagree but my advice to more junior guys is always get rid of the toys and learn the tools.

&quot;Can you selfhost the server-side?&quot; is the biggest question If not, you&#x27;re buying into dev platform-as-a-service.

Personally, I have gone from IDEs to vim + language-servers. I get all the benefits of an IDE that I want, and no useless clutter of features I never use or are better solved in CLI.<p>One reason is that IDEs&#x27; vim-plugins never work quite well. Another one is speed and resource usage. Resource-usage may be solved with thin clients, but not speed. Also I don&#x27;t want to give up control to some <i>platform</i>.

I really value being able to develop offline, without an Internet connection. That&#x27;s the deal breaker for me regarding remote dev environments.

There&#x27;s the future that is likely and then separately the future that would be ideal or preferred.<p>The latter:<p>* eliminate dependence on the cloud - the entire idea of &quot;everything through port 80&quot; was 100% wrong in the 1990s and it&#x27;s even MORE WRONG today. Centralization is never the answer except as an instance within some cycling change. Distributed tools are still the better answer under all reasonable circumstances!<p>* focus on implementation of both parsers and IDEs. New languages will always be created and anything that makes both parser AND IDE creation easier and more &quot;automatic&quot; is a good thing.<p>Most everything else good can come from these to start with.

Remote IDEs managed by the employer? A deal breaker for me. IMO that opens the gates of micromanagement. I consider myself a fair productive and successful guy, in my development job, with gaps of non productivity here and there during the day and I consider them physiological. IMO again, Developers should stay away from centralized coding collaborative platforms, despite all astonishing tech accomplishments I see burnout right around the corner. Plus since I have an M1 development machines that&#x27;s super performant, that I planned to use for at least 4 years, that&#x27;s just like paying 1euro&#x2F;day.

With a title like this I was hoping for something a little bit more grandiose, like discussing whether editing text files is the right way to describe computations.

What&#x27;s old is new again. We were doing this (and with <i>any</i> application, not just IDEs) back in the early 90&#x27;s with X-windows. X-server local, compute engine where-ever you could borrow&#x2F;steal&#x2F;hack it.

Hi Gianluca, great article, really. If you didn&#x27;t know him, this guy developed Uniwhere, an app for university students that had to compete with a much worse one, funded by taxpayers money. They really tried every shady trick to make Uniwhere fail, they even banned it at some point, but at the end Gian won and nowadays his app is helping thousands of students. You made a very motivational speech at the CLab meeting some years ago, really thanks for sharing with us your experience.

This is what I wish for in an IDE in the future: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;TaliaRinger&#x2F;status&#x2F;1365433319572185092?s=20" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;TaliaRinger&#x2F;status&#x2F;1365433319572185092?s...</a><p>The year is 2030. You&#x27;re a software engineer at a company, writing tests for your program. After you write a few tests, your IDE is like, &quot;hey, I noticed you were testing this; do you want this more general thing to hold?&quot; and spits back a specification for you. You&#x27;re not sure. You say, &quot;give me some examples,&quot; and your IDE generates more tests for you. One of them looks off, so you tell your IDE, &quot;no, not that one.&quot; Your IDE sends you another specification. This one looks better, so you approve it. Your IDE tells you to hang out for a bit while it tries to see if it actually holds. After ten seconds or so, it generates a failing test. You fix your code and try again. This time it&#x27;s like, &quot;I couldn&#x27;t find any counterexamples, but I&#x27;m also not positive it&#x27;s true. Can you help me prove it?&quot; You say yes, of course. It asks you a couple of specific questions about your code. Thinks for a bit, and then tells you that your code is verified. In fact if you are an advanced user you can go check out the proof yourself. No need to, though. A couple of days later, you change your code. Your IDE notices this and tries to check the specification again. It tells you that it is no longer true; but based on the change you made, there is an analogous change in the specification, so maybe you want this new specification? You&#x27;re not sure so you ask for some tests. It looks good. And this time the tool doesn&#x27;t need to ask you any questions to prove it; the proof is similar enough to the proof of the old specification, so you&#x27;re good. After a few more weeks of this, your IDE notices something else, though. You keep changing that function, and changing your specification to go with it. So it recommends a new abstraction for you that would have captured all of the past examples. It tells you, hey, if you use this, things might break less often to begin with . It looks good so you&#x27;re like, &quot;oh cool, yeah let&#x27;s do that.&quot; And it drops into a guided refactoring mode, helping you through the change, asking you just a few questions but automating all of the tedium. Does this for your program, then for your proof. And your proof doesn&#x27;t break again for months after that. Good shit.

Seems I am rather alone with using a boring code editor (Atom) with only necessary plugins (sometimes not more than syntax highlight for my current language)<p>And do everything else in a tiled terminal window, I have always open anyway.

I work on what you might call a &#x27;database IDE&#x27; and we have actually gone in the opposite direction, adding more features for offline development and maintaining state offline. We were pretty open either way but our users pulled us this way. Interestingly I think the enterprise may be more open to this remote environment thing, as long as it operates within their network.

For me, IntelliJ is pretty much already there except speed. Too long to startup (I can live with that since I can keep the windows open for a while) but then it starts to slow down after few days and becomes quite slow, say, after a week or more. My opinion is that they should take a release or two to not add any new features and basically only focus on speed.

I suspect there needs to be some newer patterns in open source build systems that help the cloud-based IDEs become a &quot;thing&quot;.<p>It&#x27;s the build systems that give me confidence that my IDE choice isn&#x27;t some permanent lock-in. I almost always add .gitignore rules to never check in preferences from anything made by JetBrains, and you know what? It always seems to work fine. For example, my Java project structures are defined by Maven and Gradle, not IntelliJ. IntelliJ uses those conventions.<p>For this to _really_ take off, I sense we just need to be able to bounce offline or online if we want to. And the way that&#x27;s going to happen is just via the build system defining the structure and workflow.<p>This could happen, but it requires a lot of build work that I don&#x27;t see happening right now. At least, not in the open

Remote dev environments certainly have a future, especially for larger teams working on cloud software, which usually is deployed to Linux servers. If you deploy on Linux then you should also develop on Linux. With regards to what will run remotely, the question is where do you draw the line? E.g. Will at least your editor run locally, aka (VS Code remote mode)? The additional latency of the network when typing could be very annoying. The big advantage of remote environments is IMHO not that they are easier to setup. E.g you can also achieve the same locally, but it is rather that you get access to potentially unlimited resources and you can potentially speed up builds, because you can have a high performance cache for build results close to where your development environment runs.

&gt; Software-wise, a fully remote environment helps avoid dual-boot madness and incompatible-drivers fighting: my dev environment sits on an Ubuntu server, making tooling dramatically easier.<p>This setup honestly sounds envigorating; I&#x27;m currently in a predicament where my course requires the use of Windows-only software, so I&#x27;ve got a dual-boot on the laptop. Whenever I forget to shut down Windows properly and boot into Linux, I find out the NTFS drive is read-only to prevent corruption. This means booting back into Windows, finishing up any work I might have on there, restarting to Linux, and getting personal development work done.<p>The author hasn&#x27;t specifically mentioned any Windows-specific setups here, but I&#x27;m sure it&#x27;s possible with QEMU, a VPN, and some other tricks.

Browser based IDE&#x27;s are not great for those that want a customised terminal or depend on applications that have key-bindings. For example Cloud 9 was good for getting started in the AWS account I was granted access to but was unable to run tmux or give me a full screen terminal. I am also conscious of the trap certain companies are laying where we end up paying ever increasing subscriptions for enhanced IDE sugar in the same way designers are dependent on paying Adobe for Creative Cloud.

Higher end local hardware (like MacBooks) also have really nice displays. If you go cheap on the laptop then expensive on the remote server, you end up with a terrible screen and keyboard.<p>I think remote IDEs make sense if you’re a massive company with an insane number of microservices that need to run for testing, but 99% of devs would be better off with local dev.

I was recently playing around with a bit of a self assembled version of this using VSCode dev containers and exploring what a “GitHub Codespaces first” workflow could look like.<p>I was honestly pretty happy with where I landed on it even in the context of a fairly complicated setup running a Flutter web app, a backend and an envoy sidecar proxy.<p>I was also able to set up a consistent IDE experience by specifying the various plugins I wanted to use along with other tooling I needed like gcloud SDK etc…<p>But just last week I did a remote pairing session with someone on a full stack web application entirely within a remote codespaces environment with zero other tooling (even the pairing was taken care of thanks to VSCode live share plugins). I thought that was a pretty cool experience overall. The thing I love most though is that I’m not specifically tied to a remote development environment I can get the exact same experience by just running the devcontainer locally on my machine.

To answer the question in a more practical sense than the plugging of a specific workflow and asking &quot;Is this the future?&quot;, that the article posits:<p>1. Back to easy indirection resolution (<a href="https:&#x2F;&#x2F;youtu.be&#x2F;baxtyeFVn3w?t=1786" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;baxtyeFVn3w?t=1786</a>, re: gtoolkit)<p>2. Comments that are not inline, but can point to various blocks&#x2F;parts of code and overlap (multiple comments can apply to single parts of code).<p>3. More support for unit testing. function call tracking (<a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;51901676&#x2F;get-the-lists-of-functions-used-called-within-a-function-in-python" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;51901676&#x2F;get-the-lists-o...</a>).<p>4. Conducting behavioral studies via opt-in submission of eye tracking data. A great deal of data is flowing through IDEs and not being leveraged to improve the daily tools of developers.

Honestly, I&#x27;ve been seeing the future of IDEs using GitHub Co-Pilot in the last few weeks. It has increased my productivity many-fold.<p>I was so positively shocked by its suggestions that I kept positing videos of it in action with the team.<p>It adapts to the structure and peculiarities of a specific project and you only really understand it once you are in a flow; you almost forget about it until one time you press return to write a new line of code and it correctly writes exactly what you wanted.<p>It&#x27;s creepy and absolutely incredible at the same time. Almost as if you&#x27;re pairing with someone that you never speak with.<p>Here&#x27;s Co-Pilot finishing a coding kata for me: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;ih32sCy.mp4" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;ih32sCy.mp4</a> (trimmed to 60s b&#x2F;c of imgur limit).

I keep coming back to emacs. Used to have a custom .emacs.d I kept in github, but eventually just gave that up and went with spacemacs :)<p>Employers that standardize on a single IDE (e.g., enterprise Java shops and eclipse - blech) are always terrible places to work.

And thus we are completing a huge circle that starts with the world where computation is concentrated on a handful of large computers and users having only thin clients and we will end up more or less in the same state with PCs being nothing more than thin clients to run a think client layer like projector client, web browser, rdesktop, ssh, etc.<p>The final step will be take away users&#x27; ability to do anything on the machine other than just reach cloud premises of their employers and service providers. This most likely will happen in the name of increased security and convenience.

Despite the developer pushback, I believe remote IDEs will be the standard in 5-10 years. There are many benefits to provide a standartised developer environment for productivity as well security point of view.

IDEs will likely increase their use of so-called AI, and Apple will finally not be the only one who understands the link between a platform, it’s standard libraries, and the IDE linking environment. I suspect that they will resolve this in the usual bloated manner of simply including everything all over again as the primary unnamed platform I am referring to won’t be able to merely merge some headers… now, I’ll go read the article and see how this was actually about racehorse fiber intake and rectal cancer prescreening, doh, horses for courses?

I was always wondering how it would be if IDE could treat curly braces blocks as virtual indentations. So you could work with language that uses curly braces as if it used indentations. Text file would still contain braces, but IDE would display them as indentation blocks.<p>I&#x27;m not completely sure if UX would work out. There would be less visual noise, so reading would be easier. Writing is harder to solve as IDE would need to be smart and convert indentations to pairs of braces underneath in appropriate contexts.<p>This feature would of course need to be togglable on&#x2F;off.

&gt; Chromebooks are going in the right direction, and not by chance. They’re an attempt to fulfill Google’s vision of “everything in the cloud”. I don’t think, though, that they could ever be a great machine to code on: terrible keyboard, terrible screen, terrible shell experience.<p>What? There are chromebooks by many different manufacturers, and they all have a terrible keyboard and screen? As for the shell experience, that&#x27;s not going to matter if development happens in the browser.

I find the author is missing the forest for the trees.<p>The magic of their experience was created by automatic environment configuration. It&#x27;s the magic that let them start working without spending a day preparing an environment to start working within.<p>It&#x27;s something that VSCode does quite well, not perfectly, but well. It installs a decent environment automatically for most popular languages and toolkits.<p>Emacs has _finally_ caught on, and lsp-mode will attempt to automatically install language servers for you.

I think that remote coding can obviously be practical in some cases but I also think that we should learn the lessons of Gmail&#x2F;Facebook.<p>If remote coding was the norm it would be an open door for corporate surveillance on a massive scale.<p>I don&#x27;t feel good about this idea, I think we should resist and fight back, this is not only a technical discussion.<p>On the other hand, the thin client idea is cyclical but is usually short-lived and is often the wrong solution to a real problem (bloatware).

It&#x27;s funny he mentions running on an iPad, because being able to use Vim or Emacs from on my iPad Pro with the Smart Keyboard via Blink is one of the big advantages of not using an IDE for me. Yes, web based IDEs&#x2F;editors are becoming a thing, but if you really want something portable to any work environment no matter the platform&#x2F;security concerns etc. there&#x27;s really only terminal based editors.

In most use cases I don&#x27;t see the benefit over a RDP access to that remote server. With RDP you as well have control over all the over things that you might want there, starting with a proper Terminal, File Manager, Process Monitor etc. Personally, I run my beefy Win&#x2F;GPU&#x2F;ML setup in the basement, while using it via RDP from my Mac. Awesome experience for me.

One really nifty thing one can do in VS Code if you use Bitbucket at least (possibly others) is to open pull requests in VS Code using the Atlassian plugin.<p>I&#x27;m no big Atlassian fan to put it mildly, but this is actually more brilliant than it sounds:<p>Reviewing a pull request from the comfort of your IDE&#x2F;editor, complete with ctrl-click navigation working, that is sometimes a game changer.

Domain-Specific Languages (DSLs) are a logical fit for browser-based and cloud-hosted IDEs.<p>Most recently I&#x27;ve been really impressed with the Remix IDE for Ethereum smart contracts. <a href="https:&#x2F;&#x2F;remix-project.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;remix-project.org&#x2F;</a><p>When working in cloud IDEs, I just need the safety net of backup&#x2F;versioning via git commits.

I think it&#x27;s about the thin client, I imagine something like double 4k displays on light-weight googles and advanced finger tracking sensors so that you can &quot;type&quot; anywhere, even laying down. And plugged into a network cable, giving you close to zero latency while interacting with a high powered machine - in a data center fairly local.

I’ve done all my dev work in a remote vm in azure for 3-4 years now and really like the model. I can start coding on one machine, pick back up on another, and zero dev-cruft on my local machine. I’m interested in container based ides for similar reason. The downsides he mentions are legit, but on the whole, I recommend trying the approach.

The one feature I think lacking from IDEs is a way to remote collaborate. I know VSC does have a plugin that works (after a bit of tinkering) but I think having something built in would be a killer feature for teams who are on boarding and training junior developers in today&#x27;s remote working &#x2F; post COVID society.

I would also mention code-server[0], created by Coder[1] for their hosted VSCode service. You can self-host it with Docker and login from outside your network.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;cdr&#x2F;code-server" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cdr&#x2F;code-server</a> [1]: coder.com

How about performance? The current paradigm seems to be either choose a huge bloated Java monstrosity like IntelliJ that has all the features you want, or settle for just a text editor. I would kill for something like Webstorm implemented in Rust or C++.

In the future all IDE&#x27;s will be using Comic Sans as their default font.

If you have root, great idea.<p>If not, terrible awful idea that will enslave us all.<p>Joking, but also not.

Eclipse Che has been doing this for a while as well. <a href="https:&#x2F;&#x2F;github.com&#x2F;eclipse&#x2F;che" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;eclipse&#x2F;che</a>

I am hoping that IDEs start adopting accessibility over design. Yes most have some way to make text larger and higher contrast but those function often make the experience unusable.

&gt; terrible keyboard, terrible screen<p>This sounds like a problem with one device, not the whole concept. I have used devices with great keyboards and screens. You just have to pay more.<p>&gt; terrible shell experience<p>In what way?

Feels like we are going in a giant circle, back to when I ran LSE under DECWindows displaying on my local X11 terminal. Makes me wonder if at some stage we took a wrong turn.

I think that most IDEs (with exceptions) are junk that do nothing but occupy disk space, it is far better to use only a text editor and command line compiler.

Rust and Rust-Analyzer shows that for program text editor, the language front end has to be kind of forth coming too.

Someone just rediscovered running IDEs over a modern version of X Windows.

I think it will be simple and simple, like vim!

Death.

IDEs were a mistake, and you can see why and how if you have ever worked on a project where everyone except you is using VScode.