Funny, it's the opposite for me: Would someone please host the serverside so I don't have to? I'd love to pay for an IDE-as-a-service that updates itself, syncs itself everywhere, has all the right extensions, auto-configures Docker and data stores and secrets and Git and linting and Webpack interation and and and... etc. Something like Vercel but for the IDE.
I hate fighting IDEs (whether it's IntelliJ or VSCode) before I can write useful code. Javascript has gotten so bloated that half the challenge of any new project is setting up tooling. God, I'd love a 1-click "create new project" and then a GDocs-like IDE in the cloud, and would happily pay to never have to configure that again myself.
Because laziness, frankly. I'm just too jaded to care about optimizing the toolchain anymore, when more often than not it results in 30% more performance, one cool new feature, and ten new bugs.
If you enjoy that sort of tinkering, more power to you... you're probably a better dev & devops person than I am.
Doesn’t IntelliJ sync most of that? I use IntelliJ on 3 computers and all my extensions and even themes are synced.
And are you aware of platforms like Cloud9 that have been available for 10 years that give you an online developer environment?
Honestly the only two reasons I personally don’t use them is because (1) I’ve never been at any company or place in the world where the Internet was truly 100% available with dependably low latency and near zero jitter and (2) nothing beats IntelliJ for me.
I've used IntelliJ for a decade (including several hours today) and it's never very seamless. The sync features are hit or miss, especially across platforms -- I've used it on various Windowses, Linuxes, and macOS. The hotkeys aren't the same, the interpreters aren't the same, the containers (Docker or Python) don't function the same, the linters don't present the same, the NPM modules don't always compile on different architectures (sigh, M1), the memory settings don't always persist, some are synced to Jetbrains and others are stored per-repo... it's a nightmare to untangle. The syncing is there, sort of, but it's far from seamless. There is still a lot of complexity and points of failure between the bare metal and my code (whether it's PHP or Python or Javascript). And if you can't afford IntelliJ ultimate and use separate products (like PyCharm and PHPStorm), the integrations are even worse, along with trying to figure out which product offers which feature (like Javascript support, or SQL).
What I'm hoping for is an easily reproducible dev environments with common-sense images that can be maintained and edited in the cloud, almost like Docker images, with all that stuff preconfigured... the latest interpreters, node, yarn, xdebug, webpack, blah blah all just preconfigured and ready to go. Next.js does some of that, the dev tool Lando tries to do that (but is pretty buggy), but all of it still requires a lot of manual configuration. And coding across platforms (like Windows desktop + Mac laptop) is still a huge PITA even though it all gets deployed to bog-standard LEMP stacks in the end.
It's just such a far cry from, say, being able to seamlessly use the Adobe Suite or Slack or Zoom or Microsoft Office across platforms and projects. I guess it's a bit unfair to compare first-party vendor software to messy open-source ecosystems, but that's what I'm ultimately griping about... I don't want to spend time doing devops instead of coding visitor-facing features. Some companies have dedicated people for that; our org can't afford that, so I just have to figure it out as I go, doing a piss-poor job most of the time. Wish there was a vendor + service to take care of that, and present just a usable IDE in the end, with all the internals abstracted away and maintained in the cloud. Ideally it would be a thin local client with native GUI but offloaded processing, vs a laggy screenshare.
I haven't tried Cloud9 in particular but have tried other cloud IDEs, which just felt like remote desktops running on someone else's machine that I still have to do all the same tooling and maintenance for myself. If Cloud9 or others DOES do what I want and I just missed it, please let me know.
shrug Maybe I'm just getting too old for this stuff. I miss the simple jQuery days when there was the DOM and that was it, not a bazillion layers of tooling and the super complex packagers and containers and other enterprise tech required to support them.
I have had some luck with working across Linux and MacOS. I prefer MacOS shortcuts and use https://github.com/rbreaves/kinto to use MacOS shortcuts on an Ubuntu machine.
I also use JetBrains’s products extensively. I used to have on intellij settings repository for all products (PHPStorm, PyCharm, Webstorm), but I found the same issue that the settings wouldn’t sync in the way I wanted. I now have separate settings repositories for each product. This seems to be working better, although, it does require copying new shortcuts to each product.
I haven’t tried solely using IntelliJ Ultimate, so maybe I will see if I can configure that to work for different programming languages. I have been reluctant to do so, because the appeal of IntelliJ for me is that it makes it easy to work with a programming language. I don’t want to have to configure IntelliJ Ultimate when I want to use Kotlin or want to use Python. Maybe it has a nice way of handling that?
> I don’t want to have to configure IntelliJ Ultimate when I want to use Kotlin or want to use Python. Maybe it has a nice way of handling that?
Hmm, that's actually the point of the Ultimate version, I believe: it supports multiple languages quite nicely, from what I can tell. Finally convinced my work to pay for Ultimate so I no longer have to switch between PHPStorm and PyCharm.
To add support for a new language, you just download the first-party plugin pack (like Python plugin by Jetbrains for Python). Then point it to the interpreter/compiler, which can be set as a per-machine default and then overridden on a per-project basis as needed (like if you needed to use NumPy for a specific project, or a different NPM version). Most of the time it's just auto-detected and works out of the box... it only gets tricky if you have, say, macOS Python 2.7, homebrewed 3.x, and some strays in a Docker container. It'll detect all the ones it can and ask you to choose.
But other than that, projects can use multiple languages simultaneously with no additional configuration. You can even (in the IDE) combine multiple repos into one project, each with a separate git but presented together in the editor. Or use SQL/GraphQL inline in a JS file, for example. It all works pretty seamlessly if you DO have the right license (Ultimate).
In fact I believe the language-specific products are, for the most part*, stripped-down versions of Ultimate. It's all built on a relatively modular plugin system, with each language or module (like the database browser) as a plugin -- but they can't all be activated on every product, like you can't add the DB plugin to PyCharm Community Edition. Ultimate just allows you to enable every plugin.
*That's not 100% the case, maybe only like 90-95%. I have noticed some minor GUI differences between the products, such as being able to collapse buttons... but they are very minor compared to the benefit of being able to use all the languages in one IDE.
I think VSCode works like that too, but you'll need to install a lot more plugins to reach near-feature-parity with IntelliJ.
I think that the 1-click (or 1 command) create-react-app style of development is part of the reason that JS has become so bloated. It encourages thinking in terms of framework and bundling of tons of dependencies as well as closely tying software with any underlying bundle/development/analysis process. The problem with this is that it doesn’t compose well…
However, it is a catch-22. As more things want to become frameworks and wrap the entire process (for ease of use), there’s more monolithic stacks created, and it ends up with making it even more inaccessible without 1-click/command solutions.
I think there's many advantages to it. Whole one company might be stuck in slower webpack/Babel hell, nextjs, remix, those that don't let the developer muck with the toolchain have been able to switch out for much faster & smaller bundlers. CRA is in a decent position to do similar.
It's really unfortunate that JS won out in the web wars, another instance of the lowest common denominator winning out against technically superior options. If Microsoft hadn't been so evil, .NET is really a much better framework... but it didn't get enough traction.
By contrast, PHP has actually evolved quite gracefully over the last decade, incorporating more and more desired features into the baseline language. Sadly it has no browser clientside option.
Javascript is a victim of its own rapid success :(
Yes, this. I wouldn't ever dare to put my development in the hands of some third party service. It's just far too risky. But self-hosting such a system is something that I'd at least consider.
Also, self-hosted or not, if the system is web-based, that's a dealbreaker.
I'm sure you could set up a VPN on your home WiFi, forward its ports, and login from an external WiFi, assuming the relevant ports aren't blocked on the external network you're on (in that case, I hear stunnel works wonders).
I too would rather do this. Trusting Amazon with my personal development setup doesn't sound like a good idea; they have the power to shut that down completely at the click of a button.
It definitely counts for me! I set up something similar a couple of years back when I wanted to do GPU-accelerated programming from my couch on my anaemic Chromebook (while connected to a 1st get Threadripper in my office). Initially I was using Jupyter, then realized I could work on my other projects using VS Code remotes (Virtualized Linux on Chromebook is great!).Immediately after, I realized I could VPN from the coffee shop or meetups, instead of doing the git push/git pull dance on the heavier Macbook
These types of services are mostly not aimed at established tech shops. Similar to Wix or Squarespace or Appian, if you already have an in house tech team, you don't need this, probably.
But if you're just starting out, with a small and quite possibly partly outsourced team, this could be a cheaper and faster way to spin things up. Just like many companies don't have their own datacenter anymore, and even fewer have them literally onsite in a server closet.
In the beginning, you can. Then as code size, build times, testing requirements increase, they will upgrade the server. After a couple of years it will be impossible to run the server on your laptop.
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.
Not a massive fan of Blueprints, as a game developer who is also a long time software developer/security engineer. I think for non-coders it's a great system and can be helpful to view data flow/execution paths in a visual way. I wish the C++ and blueprints systems where better integrated. For example being able to generate one from the other or directly import and use each other (you can sorta do that but with limited access and some boiler plate). I'm not disparaging it, it is really a great attempt at visual coding but as a developer it's not a setup I'd choose to use pretty much ever. For me the best use would be for a non-coder game designer to use it to script levels and for me to integrate seemlessly from C++ as a dev and since I'm a single person indie dev it's of less use to me. It doesn't seem quite ready for that. Most games and examples I've seen with it are either blueprints or C++ not a lot of mixing yet that I've seen, though there is certainly some.
To be clear on my opinion you can integrate blueprints and CPP code but it's not as seemless as I'd like. Given that blueprints run in a VM and your CPP code doesn't there are certainly blocks. They are working on fixing that (https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScrip...) for example. I'm impressed with the quality of blueprints but would still rather approach software from a text based approach and a low level approach. I also hate working in JS frameworks and big collections of libraries all bundled together.
Battlefield 2042 has a portal mode (their name for it) that allows gamers to "design" a mixup of a variety of older and current battlefield game assets, maps, and modes to create a new game experience with other gamers. For a similar concept in platformers look at Super Mario Maker 1/2 which are AMAZINGLY good games and software for designing mario levels. Here is a link to the Battlefield 2042 documentation: https://help.ea.com/en/help/battlefield/battlefield-2042/bat...
- 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
- 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's IDE into a problematic server and start debugging using the appropriate code without having to spend 2 hours reproducing the build configuration locally.
- 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 "gatekeeping" into a rational, safe processes.
Just a addition to the _TeamWorkflow_ it would be great if there was a standardized Way to have a kan-ban pipeline mapped into the IDE. Like Icebox -> First Implementation -> Review -> etc -> Deploy & DevHops
I always found that "assign" to person of gitlab to be clunky and the use of CI/CD Piplines to map the concept even clunkier.
If every pipeline station becomes something abstract, and the people just check in with their station, in the IDE, with the IDE even pre-configured to the current Station (basically pipeline-modal) that would be real neat.
Some of us already have that, as IDE Presets, switching manually, but having that baked in, would be a benefit.
I have to say I really disagree with the thought that one should bake a whole bunch of custom functionality into their ide. My company did this. A special, custom version of eclipse was required to even build or deploy their applications. What happened? It was abandoned, and since that build / deploy functionality never existed as independent utilities it was completely lost. I had to piece together how to build my application by pulling build files off of our old ass legacy cicd server and even that process is pretty horribly broken. As things stand, the legacy app I'm tasked with keeping alive is held together with bailing wire and chewing gum and almost all requests for new features are turned down. This is not a unique problem to my team, it's org wide. Tons of legacy apps are limping along because 'the knowledge' of how to do things properly was bundled up into eclipse plugins we no longer have access to.
That's no different to requiring an arcane incantation of shell scripts that call maven, git, curl, docker, , etc. The advantage of having it built into IDEs or CI servers (and by built in I mean TeamCity/Jenkins providing it, not a self inflicted third party plugin) is that you can build around these steps. Imagine if all CI servers supported merge previews or mergebots - that workflow gets unlocked for everyone!
at least with the shell scripts I can quickly see what it does. I much prefer the unix philosophy of small bits of code that do one thing, and do it well. Such things can be combined to make bigger things. Want to make a plugin out of those individual scripts? Knock yourself out! Meanwhile, a decade from now, some engineer can actually reconstruct if needed. Much better than a 'binary blob' plugin that gets abandoned.
I used to do this, on and off, with vim. Hey customize this, and that, and add some special key bindings and plugins. Then you go to ssh somewhere and you're totally lost. Ya, I know there are ways to manage your config for vi but it's not perfect. I find it's sort of like keyboard layouts like Dvorak. Sure it might be more efficient, which is debatable, but there is a huge value in being able to sit down at just about any keyboard and knowing the layout.
At one point it takes longer to implement a simple feature then it takes to rewrite the whole program, that's when you rewrite the whole program (using a sane amount of dependencies - as few as possible)
I totally agree a specific IDE shouldn't be _required_ to operate the software platform. The IDE should ever remain a catalyst, accelerating a process that could be done by hand from the CLI whenever required. The good IDE should know about these different tools and present them in a a coherent manner. The I in IDE should mean more than integrating a compiler and debugger with a text editor.
addendum: the "team rules" being kind of novel, these should be encoded in a human-readable file, actionable from the CLI as well as the IDE. I've been pondering for a while how such a workflow tool could be like.
There’s a lot of interesting thoughts here. Especially in points 2&3, around integration between dev and deployed environments and workflows being integrated into the tooling.
Our company Coherence(withcoherence.com) is pre-launch but is working on these exact problems if anyone is interested in helping to solve them!
As someone on a team heavily reliant on CI, I think we really need better support for running things locally without CI, though having integration with the server for looking at results is great too.
For example, I want a workflow where I can click on a failing test from the CI and have it pull up the source code of the test in the IDE and run said test locally with a debugger.
It'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/editors are becoming a thing, but if you really want something portable to any work environment no matter the platform/security concerns etc. there's really only terminal based editors.
In most use cases I don'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/GPU/ML setup in the basement, while using it via RDP from my Mac. Awesome experience for me.
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.
One reason is that IDEs' 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't want to give up control to some platform.
I've given Emacs a handful of good tries, but it always lets me down. I've tried out "vanilla", Spacemacs and Doom (the last one being my favorite so far), but it's not working for me. I keep going back to good old Vim.
For example, when I was learning Clojure I used Doom Emacs for a few months, but gave up because:
- Emacs is slow. There's no way around that. It's even slower than VSCode or other IDE-ish editors. If you're used to Vim speeds, that's pretty annoying.
- The Vim keybindings are not available everywhere, for example in some plugins you would fall back to pinky-breaker, wrist punishing Emacs standard keybindings.
- There's some uncanny valley where keybindings are mostly like Vim but you have constantly paper cuts from small differences here and there, among the occasional Emacs-mode fallback.
Don't take me wrong, I can see how Emacs is a great editor, but for me, it's way too late it seems. Seems like I'm going to keep on vimming until the end.
> Also we are talking here about Emacs "distributions" (Spacemacs, Doom Emacs) which come with a lot of code, and ELisp is not particularly fast.
I've just tried Doom Emacs on 27.1, with the default stuff plus some minor additions, and it starts within 900 ms on my laptop (Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz).
It can be, because it is :) If you want a really technical explanation, you can profile the application. If that is too much work, I'll generalise and say that the tendency for the UI to lock when performing CPU heavy computations makes it feel slow. Because of the things you will be asking it to do (i.e. solve modern problems), sometimes such computations exist and lead to blocks of 1s or more. That will never feel fast.
It isn't. I still use it once in a while on an old netbook with a couple of gigs of memory, and it flies for any editing task. In comparison, no IDE can even hope to run on that unit.
HOWEVER, a heavily and naively reconfigured emacs, possibly with uncompiled elisp code and copy-pasted invocations that wait for network responses could take ages to open.
If you are finding emacs to be slow, try it vanilla first ("--no-init-file") before deciding it's the program and not your configuration.
Wish I started out with Emacs, but after 10 years of curating my vimrc, I don't have time to replace all my custom plugins/bindings by figuring out elisp.
I liked Doom as a vanilla editor, but I went back to vim.
For what it's worth `vim-iced` is pretty cool for Clojure. I didn't like Fireplace at all.
Less is more. Tools should do one thing and do it well. I don't want to install a huge package and dependencies just to get one feature. Generally feel pessimistic about the "future" of IDEs. The phrase brings bloat to mind.
If I need the feature, let me add it to emacs. In most cases someone else has already provided a config.
> If I need the feature, let me add it to emacs. In most cases someone else has already provided a config.
That sounds like a good approach when you need 5 features. But for development the number is probably in the hundreds and I have no time to try to manage all that.
Besides many features are simply not available for editors like emacs. As an example, data flow analysis warns you about logical mistakes in your code (e.g. dereferencing nullable variable without a check first). This happens as you type, the closest you can get without an IDE is probably running it on some static analysis tool in your CI => getting feedback an hour later.
I agree. Even more: I saw vim users who manually edited dozens of files which could be done by running inspection by name on the entire project in IntelliJ. Even (questionably) superior text editing capabilities of vim won’t help here.
I think many vim/emacs users are not aware of the functionality of modern IDEs and development speed is mostly defined by text editing speed. Sadly, many users of sophisticated IDEs also are not using these functions, so the experienced vim user will likely be more performant than inexperienced IDE user.
As long as your LSP server support it, you can rename it with LSP and it's the same than your rename function in IntelliJ on Neovim. Actually in most languages I use the same LSP server than vscode.
I switched from Vscode/Intellij to Neovim +1 year ago and I couldn't be happier. I get why Neovim/Vim/Emacs is not for everyone tho.
Well, this is exactly what I meant: you need to know your tools. Rename is very basic functionality. What makes real difference is, for example, automatic removal of unused variables/classes (quickly search for all occurrences, review the list, and then apply). Or rewrite some deprecated construct with a new one. Or structural search and replace (works on a code structure, not text).
There is way more to a fantastic language support in an IDE than symbol rename.
I mean, all the features you're mentioning here are part of the LSP server, in the future I think this will be even more consistent across editors because the new languages like Go, Rust, etc. provide better integration tools and LSP servers so the IDEs and editors just use this server instead of implementing one for each language by themselves. If you use the same LSP it will be the same more or less but yeah, the average IDE user doesn't even know what is LSP because they don't need to.
This is similar to MacOS/Windows vs Arch Linux. If you love building and tweaking things, custom builds to suit your needs, knowing every tool that is present in your editor and/or extending it, terminal editors and arch linux is for you, if you prefer something pre-configured that just works out of the box then IDEs and MacOS/Windows is way better ofc. But I don't think that we, the vim/emacs/neovim users, stick to our editors because we are not aware of the capabilities of other IDEs. We are very aware, we are very advanced users in most cases.
I have a love hate relationship with vim. It's super fast and efficient to edit huge quantities of text, but as a tool to really understand a code base? IDEs reign supreme. This is coming from someone who steadfastly refused to use an ide until his last year of college, and then switched, being able to see call hierarchies, having smart completion, etc made my life much easier. I still fall back to the term and vim if I need something quick and dirty.
I don't think you can easily do this in vim, but search over the entire code base ignoring anything ignored by git. You can obviously do this with git itself, but it is nice having an interactive list of results.
I don't know if they are a mistake, but they certainly cover up a lot of cruft, which should have been handled.
We now have languages which can't really be used without an IDE, like C# or Java. That in turn result in programmers who can't actually program very well. I started seeing it way back in 2007, where some coworkers basically just used tab-completion in Visual Studio until types matched what a method required, rather than sitting down and doing actual design.
This point is exactly what I mean, IDE bloat keeps creeping into the codebase and other tools, making parts of IDE a hard dependancy. I'm seeing that happen with VSCode where people are polluting the codebase so VSCode can work.
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's remote working / post COVID society.
But tbh, I've never found those tools to be useful. In my experience, Pair Programming is not only about code but also about processes (git, pull requests, the CI, IDE features, company internal tools ...). It's also inefficient if the involved team mates have different IDEs or habits ...
As of today, I've found nothing better than screen sharing. And screen sharing could totally be improved because, afaik, you have to choose between correct interaction (ability seamlessly to take control of the distant screen) or correct image quality (Zoom is pretty impressive).
Also, I'm open if you know collaboration tools with good screen sharing quality AND intuitive collaboration tools / distant control.
IntelliJ's "Code With Me" plugin still has a long way to go but is really good already: On the "client side", it feels like working in your own IDE (sometimes, you run into "not implemented yet" spots, but for the most part it just works) with zero latency, HiDPI resolution and a color scheme of your liking. Plus, you can work independently (all participants can type at the same time), look stuff up if your pairing partner scrolls too quickly (or too slowly) and you can even share a terminal (if you want) and run tests on the "host". There is also built-in port forwarding, so that you can run a webapp in your local browser.
I don't understand why you are trying to convince me that Code With Me is a solution since I precisely mentioned it in my post with everything that, imo, lacks in it (and in all the "live edit" collaboration tools).
Those tools cannot work, IMO, because programming never happens only in the IDE.
Netbeans had just this about 10 years ago (or was it more?) You could share editing, build, debugging live via a stock XMPP server. Until Sun killed it in favour of some half-arsed imitation that was supposed to make them money.
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.
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.
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…
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.
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.
I'm no big Atlassian fan to put it mildly, but this is actually more brilliant than it sounds:
Reviewing a pull request from the comfort of your IDE/editor, complete with ctrl-click navigation working, that is sometimes a game changer.
> 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.
This setup honestly sounds envigorating; I'm currently in a predicament where my course requires the use of Windows-only software, so I'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.
The author hasn't specifically mentioned any Windows-specific setups here, but I'm sure it's possible with QEMU, a VPN, and some other tricks.
If you treat a local VM as a remote server, this can also work well, without relying on working in a «remote desktop» style. This tends to cause UI lag which is more annoying than sending the run unit test» command to the remote server which anyway will take a few seconds to run.
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's super performant, that I planned to use for at least 4 years, that's just like paying 1euro/day.
Remote IDEs will not prevent theft, of course. But they certainly can do things that make it more difficult than simply dragging and dropping a folder onto a flash drive.
On the other hand, if a company wants to micromanage its employees there isn't much that will stop them. It's possible to get the advantages of remote IDEs without the managerial snooping, you just need to work for a company that trusts its employees.
Not saying I prefer remote IDEs, just that they are more a symptom here and not the root cause.
Right - an employer who is willing to use cloud based IDEs for that is willing to install something like Teramind to just record your screen and webcam.
there are plenty of good reasons to use cloud ides. Biggest one being onboarding. New guy joins the team, we can spin up a ready to go system for them to hop in on and start browsing the codebase.
The last job I had I was thrown head first into things. Here's a guide on how to set up things. Use your ide of choice and you're off and running. You learn quite a bit on day one about the common flow you will be using immediately
Or you spend two days thrashing around because someone forgot to document a hidden dependency and nobody can remember what it is but everyone remembers that they hit it on their first day.
I need around two days to set up a machine with all the necessary components and settings for our development environment. I wouldn't mind not having to do this for myself or new people.
I work in games, where it's unlikely that you'll have the prerequisites installed for even setting up the dev environment, and where CLI usage is not common. Visual Studio licenses require interactive logins to microsoft accounts, perforce isn't installed by default (and is configured by the GUI often times, requiring things to be set up before syncing) and then syncing the content can take hours - my current projects' workspace is 42GB, and my last project was >150GB.
and then I'll just write a script to use GitHub Copilot to write a bunch of crap during my down times and when I get back I'll just make another commit that says, "Changed my mind, refactoring...wheeeee".
Dev A writes a lot of small commits and then re-orders them before pushing. Dev B has hours where his environment seems idle and then has a typing spree in between 9PM and 2AM. Dev C knows a lot more than A and B about the debugger.
I agree with you. I always turned down companies that do micromanagement and I was lucky enough to not get in touch with many during interviews. My point is my current employer trust me and I trust them. It took a while to build that trust however and I fear that, if remote IDEs becomes the norm, the abundance of data points would be abused and building trust for new hires could be more difficult.
Seems like you think your employer should trust you but you don't trust them? Not every employer is a nightmare. If you think of it as a partnership (and you have the right employer), work is much more rewarding.
If only it works like that. Maybe you find yourself lucky with a manager that looks at your productivity stats with all warm and fuzzy feelings, but the manager above that sees only ROI, and in your review that productivity dip a 3 o'clock stands out. If you don't have this now, then YAGNI.
An employer is a soulless construct that exists for the purpose of extracting as much value from the world as possible in order to deliver it to shareholders. I hesitate to call it 'psychopathic' but it's not at all bound by human morals.
Trusting any given company is akin to trusting a snake not to bite you if your hand smells like a mouse. You might like to think there is some affection there, but you're simply anthropomorphizing something which is incapable of more than its nature.
Isn't then an employee a soulful being that exists for the purpose of extracting as much value from the employer as possible with the least amount of work delivered to only provide value to itself in a form of an end-of-month salary?
Employers and companies are built of people. Calling them a soulless construct and pretending everyone in the world is out there to get you is not a healthy attitude.
To ease on the toxicity, I think I would replace the grandparent's argument by this:
The employee is one person, which you can choose to trust or not.
The employer are multiple people. Of these, maybe dozens or hundreds can impact employee's work. You can trust all of them or not. This is the crucial difference.
I see it as realistic, not toxic. A single employee is a human that has greed as one of their drives. Not everything is about money. I'm quite certain I could earn more if I applied elsewhere, but my current company is a nice place to be.
On the other hand, a company is an entity almost singularly driven by the need to maximize profit for shareholders. I have seen multiple teams work months of crunch time, only to be cut loose shortly after they delivered for the sake of 'streamlining'. Now, did the management who did the firing agree with that course of action? Heck no! They were livid. Many walked. But the C suite decision makers found cost savings that would give them fat bonuses and decisions were made.
I often wonder why the same people who are so hesitant to trust government turn right around and blindly trust corporations. The snake is not evil. The snake is a snake. Calling this view toxic or unhealthy does not change the facts on the ground.
What’s the difference between company-provided notebook and remote IDE in regard to micromanagement? Employer may provide you shiny new M1 MacBook with all necessary spyware. Even if you use your own machine, you should check every script in the project if it is not installing anything if you don’t trust your employer.
Actually, if you decide to use your own computer for work then remote IDE is probably better solution in terms of security and privacy of your own computer. You don’t have to worry that something nasty will be installed (be it malicious NPM package or spyware from employer).
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)
And do everything else in a tiled terminal window, I have always open anyway.
Same, but replace Atom with Sublime. Vim is too much of a time suck (I will customize until the end of time and get nothing done), VS Code is a bit busy and hectic for my tastes. Sublime is just lean and solid, I love it.
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.
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.
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.
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.
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.
Browser based IDE'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.
I work in games, and my applications require beefy hardware to compile (but much less to run). Using projector would let me use my own hardware locally (e.g. my Macbook) and remotely ruin the 32 core, 128GB ram behemoth to compile the damn app. _this_ would let me work on train rides!
What's old is new again. We were doing this (and with any application, not just IDEs) back in the early 90's with X-windows. X-server local, compute engine where-ever you could borrow/steal/hack it.
Sun Microsystems went all in on this approach. I never worked there, but as I understand it everyone simply had a dumb graphical terminal at their desk.
You might(?) be thinking of the SunRay stuff, which was certainly not X-windows based, though similar in concept/architecture. There was never a time when "everyone simply had a dumb graphical terminal".
(I never worked directly for Sun, though I did have a hell of a lot of dealings with both the Church and State sides of their business.)
As recently as the mid-2000's, my personal computer had virtually nothing in terms of development setup, except for a terminal and an IDE. Even our files were stored remotely (although within a local datacenter, not on the Internet) and we either edited them directly on the terminal in VI, or in an IDE, with the repository working directory Samba-mapped. All builds, tests and deployments were on remote servers. Compared to those days, today's build and test setups seem nightmarishly complex.
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.
I'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.
This feature would of course need to be togglable on/off.
What is the gain of deriving the braces from the indentation instead of deriving the indentation from the braces?
You still have one character to start (tab?) and end (backspace?) a block, but now they are overloaded with the edition keys, and still need to keep track of the block with the same visual aid (indentation).
The small changes I see are to the worse, that is overloading the keys and not letting you see the text verbatim.
Braces by itself are very poor visual indicators of a block, so they are almost always (except in one liners) coupled with indentation of the code inside the block. So, in a raw text form (ignoring newline and space chars) it's two characters to start a block (brace and a tab).
Sure, a good IDE will automatically create indentation when you type '{', so you need to only type a single character to start the block. We could actually say '{' is a shortcut key to start a block. IDE creates an indentation and draws a vertical line to enhance visual presentation of the block. Visually, braces are more or less just a noise, so removing them would improve "signal to noise ratio" and enhance reading experience.
However, logically braces are better at defining blocks of code than tabs. With braces we have start '{' and end '}' characters, but with tabs each line needs to be indented by a correct number of chars (tabs/spaces).
I am wondering, if we can have best of both worlds.
In some cases we are trying to draw visual indications with text. Wouldn't be better, if we let the IDE do the drawing? Eg.: two vs four spaces of indentation? It doesn't matter, if you can configure visual indentation depth on the fly in the IDE.
I've made a web based editor (https://webide.se/) that does automatic indentation. You can copy any JavaScript code into it and it will parse and indent. When using other editors i find it annoying to have to manually manage indentation and I do not miss the syntax errors that comes when there is a block mismatch and you have to figure out where that missing } should be...
There are languages like Python that uses "significant white space" where there are no curly braces and instead you use indentation to decide where a block ends.
The problem with Python is that my editor has no way to know
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.
Everything goes in circles, but at the same time gets better -- or, "better" -- so when we get back to the same point "on the ground", it's "at a higher level": Evolution is a helix.
AKA, a screw -- so in the long run, we're all screwed.
229 comments
[ 4.2 ms ] story [ 204 ms ] threadI hate fighting IDEs (whether it's IntelliJ or VSCode) before I can write useful code. Javascript has gotten so bloated that half the challenge of any new project is setting up tooling. God, I'd love a 1-click "create new project" and then a GDocs-like IDE in the cloud, and would happily pay to never have to configure that again myself.
Not sure why this needs to be something developers can’t fine tune for themself.
If you enjoy that sort of tinkering, more power to you... you're probably a better dev & devops person than I am.
And are you aware of platforms like Cloud9 that have been available for 10 years that give you an online developer environment?
Honestly the only two reasons I personally don’t use them is because (1) I’ve never been at any company or place in the world where the Internet was truly 100% available with dependably low latency and near zero jitter and (2) nothing beats IntelliJ for me.
What I'm hoping for is an easily reproducible dev environments with common-sense images that can be maintained and edited in the cloud, almost like Docker images, with all that stuff preconfigured... the latest interpreters, node, yarn, xdebug, webpack, blah blah all just preconfigured and ready to go. Next.js does some of that, the dev tool Lando tries to do that (but is pretty buggy), but all of it still requires a lot of manual configuration. And coding across platforms (like Windows desktop + Mac laptop) is still a huge PITA even though it all gets deployed to bog-standard LEMP stacks in the end.
It's just such a far cry from, say, being able to seamlessly use the Adobe Suite or Slack or Zoom or Microsoft Office across platforms and projects. I guess it's a bit unfair to compare first-party vendor software to messy open-source ecosystems, but that's what I'm ultimately griping about... I don't want to spend time doing devops instead of coding visitor-facing features. Some companies have dedicated people for that; our org can't afford that, so I just have to figure it out as I go, doing a piss-poor job most of the time. Wish there was a vendor + service to take care of that, and present just a usable IDE in the end, with all the internals abstracted away and maintained in the cloud. Ideally it would be a thin local client with native GUI but offloaded processing, vs a laggy screenshare.
I haven't tried Cloud9 in particular but have tried other cloud IDEs, which just felt like remote desktops running on someone else's machine that I still have to do all the same tooling and maintenance for myself. If Cloud9 or others DOES do what I want and I just missed it, please let me know.
shrug Maybe I'm just getting too old for this stuff. I miss the simple jQuery days when there was the DOM and that was it, not a bazillion layers of tooling and the super complex packagers and containers and other enterprise tech required to support them.
I also use JetBrains’s products extensively. I used to have on intellij settings repository for all products (PHPStorm, PyCharm, Webstorm), but I found the same issue that the settings wouldn’t sync in the way I wanted. I now have separate settings repositories for each product. This seems to be working better, although, it does require copying new shortcuts to each product.
I haven’t tried solely using IntelliJ Ultimate, so maybe I will see if I can configure that to work for different programming languages. I have been reluctant to do so, because the appeal of IntelliJ for me is that it makes it easy to work with a programming language. I don’t want to have to configure IntelliJ Ultimate when I want to use Kotlin or want to use Python. Maybe it has a nice way of handling that?
Hmm, that's actually the point of the Ultimate version, I believe: it supports multiple languages quite nicely, from what I can tell. Finally convinced my work to pay for Ultimate so I no longer have to switch between PHPStorm and PyCharm.
To add support for a new language, you just download the first-party plugin pack (like Python plugin by Jetbrains for Python). Then point it to the interpreter/compiler, which can be set as a per-machine default and then overridden on a per-project basis as needed (like if you needed to use NumPy for a specific project, or a different NPM version). Most of the time it's just auto-detected and works out of the box... it only gets tricky if you have, say, macOS Python 2.7, homebrewed 3.x, and some strays in a Docker container. It'll detect all the ones it can and ask you to choose.
But other than that, projects can use multiple languages simultaneously with no additional configuration. You can even (in the IDE) combine multiple repos into one project, each with a separate git but presented together in the editor. Or use SQL/GraphQL inline in a JS file, for example. It all works pretty seamlessly if you DO have the right license (Ultimate).
In fact I believe the language-specific products are, for the most part*, stripped-down versions of Ultimate. It's all built on a relatively modular plugin system, with each language or module (like the database browser) as a plugin -- but they can't all be activated on every product, like you can't add the DB plugin to PyCharm Community Edition. Ultimate just allows you to enable every plugin.
*That's not 100% the case, maybe only like 90-95%. I have noticed some minor GUI differences between the products, such as being able to collapse buttons... but they are very minor compared to the benefit of being able to use all the languages in one IDE.
I think VSCode works like that too, but you'll need to install a lot more plugins to reach near-feature-parity with IntelliJ.
However, it is a catch-22. As more things want to become frameworks and wrap the entire process (for ease of use), there’s more monolithic stacks created, and it ends up with making it even more inaccessible without 1-click/command solutions.
By contrast, PHP has actually evolved quite gracefully over the last decade, incorporating more and more desired features into the baseline language. Sadly it has no browser clientside option.
Javascript is a victim of its own rapid success :(
Also, self-hosted or not, if the system is web-based, that's a dealbreaker.
I too would rather do this. Trusting Amazon with my personal development setup doesn't sound like a good idea; they have the power to shut that down completely at the click of a button.
Not that client is your browser, but locally installed VSCode.
But if you're just starting out, with a small and quite possibly partly outsourced team, this could be a cheaper and faster way to spin things up. Just like many companies don't have their own datacenter anymore, and even fewer have them literally onsite in a server closet.
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.
> terrible shell experience
In what way?
We're moving towards a world where ML can generate code that compiles from a single comment.
We have games like Battlefield now providing no-code options to FPS gamers.
There are literal super computers that can spin-up environments in seconds, run a test suite and report back, all to give a little tick on a PR.
Yet the IDE still just gives a messy error message if you forget a semi-colon or quote in the wrong place.
Can you elaborate on that or drop some keywords that will help with a web search?
- 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's IDE into a problematic server and start debugging using the appropriate code without having to spend 2 hours reproducing the build configuration locally.
- 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 "gatekeeping" into a rational, safe processes.
I always found that "assign" to person of gitlab to be clunky and the use of CI/CD Piplines to map the concept even clunkier.
If every pipeline station becomes something abstract, and the people just check in with their station, in the IDE, with the IDE even pre-configured to the current Station (basically pipeline-modal) that would be real neat.
Some of us already have that, as IDE Presets, switching manually, but having that baked in, would be a benefit.
addendum: the "team rules" being kind of novel, these should be encoded in a human-readable file, actionable from the CLI as well as the IDE. I've been pondering for a while how such a workflow tool could be like.
Our company Coherence(withcoherence.com) is pre-launch but is working on these exact problems if anyone is interested in helping to solve them!
For example, I want a workflow where I can click on a failing test from the CI and have it pull up the source code of the test in the IDE and run said test locally with a debugger.
One reason is that IDEs' 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't want to give up control to some platform.
For example, when I was learning Clojure I used Doom Emacs for a few months, but gave up because:
- Emacs is slow. There's no way around that. It's even slower than VSCode or other IDE-ish editors. If you're used to Vim speeds, that's pretty annoying.
- The Vim keybindings are not available everywhere, for example in some plugins you would fall back to pinky-breaker, wrist punishing Emacs standard keybindings.
- There's some uncanny valley where keybindings are mostly like Vim but you have constantly paper cuts from small differences here and there, among the occasional Emacs-mode fallback.
Don't take me wrong, I can see how Emacs is a great editor, but for me, it's way too late it seems. Seems like I'm going to keep on vimming until the end.
If you really want to fix it, running the nativecomp version solves that issue.
Booting up is normally not done so often, but also doing other stuff takes way too long for my taste (over the perceivable 300ms threshold).
> Emacs ran on hardware from the 1980’s. How can it be too slow on modern hardware?
Since then they've added millions of lines of ELisp code. The comparison is moot.
Also we are talking here about Emacs "distributions" (Spacemacs, Doom Emacs) which come with a lot of code, and ELisp is not particularly fast.
I've just tried Doom Emacs on 27.1, with the default stuff plus some minor additions, and it starts within 900 ms on my laptop (Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz).
It can be, because it is :) If you want a really technical explanation, you can profile the application. If that is too much work, I'll generalise and say that the tendency for the UI to lock when performing CPU heavy computations makes it feel slow. Because of the things you will be asking it to do (i.e. solve modern problems), sometimes such computations exist and lead to blocks of 1s or more. That will never feel fast.
HOWEVER, a heavily and naively reconfigured emacs, possibly with uncompiled elisp code and copy-pasted invocations that wait for network responses could take ages to open.
If you are finding emacs to be slow, try it vanilla first ("--no-init-file") before deciding it's the program and not your configuration.
Which maybe I will, because I hate Vimscript.
I liked Doom as a vanilla editor, but I went back to vim.
For what it's worth `vim-iced` is pretty cool for Clojure. I didn't like Fireplace at all.
Org-capture, tramp mode, ansi-term. Tight integration with any workflow. Flycheck, flyspell, it’s all so good.
Much love for emacs. I would refuse to work where I can’t use it. Steep learning curve, but the view is beautiful after the climb.
https://marketplace.visualstudio.com/items?itemName=asvetlia...
Less is more. Tools should do one thing and do it well. I don't want to install a huge package and dependencies just to get one feature. Generally feel pessimistic about the "future" of IDEs. The phrase brings bloat to mind.
If I need the feature, let me add it to emacs. In most cases someone else has already provided a config.
That sounds like a good approach when you need 5 features. But for development the number is probably in the hundreds and I have no time to try to manage all that.
Besides many features are simply not available for editors like emacs. As an example, data flow analysis warns you about logical mistakes in your code (e.g. dereferencing nullable variable without a check first). This happens as you type, the closest you can get without an IDE is probably running it on some static analysis tool in your CI => getting feedback an hour later.
I think many vim/emacs users are not aware of the functionality of modern IDEs and development speed is mostly defined by text editing speed. Sadly, many users of sophisticated IDEs also are not using these functions, so the experienced vim user will likely be more performant than inexperienced IDE user.
I switched from Vscode/Intellij to Neovim +1 year ago and I couldn't be happier. I get why Neovim/Vim/Emacs is not for everyone tho.
There is way more to a fantastic language support in an IDE than symbol rename.
This is similar to MacOS/Windows vs Arch Linux. If you love building and tweaking things, custom builds to suit your needs, knowing every tool that is present in your editor and/or extending it, terminal editors and arch linux is for you, if you prefer something pre-configured that just works out of the box then IDEs and MacOS/Windows is way better ofc. But I don't think that we, the vim/emacs/neovim users, stick to our editors because we are not aware of the capabilities of other IDEs. We are very aware, we are very advanced users in most cases.
I have a love hate relationship with vim. It's super fast and efficient to edit huge quantities of text, but as a tool to really understand a code base? IDEs reign supreme. This is coming from someone who steadfastly refused to use an ide until his last year of college, and then switched, being able to see call hierarchies, having smart completion, etc made my life much easier. I still fall back to the term and vim if I need something quick and dirty.
https://github.com/nvim-telescope/telescope.nvim
We now have languages which can't really be used without an IDE, like C# or Java. That in turn result in programmers who can't actually program very well. I started seeing it way back in 2007, where some coworkers basically just used tab-completion in Visual Studio until types matched what a method required, rather than sitting down and doing actual design.
But tbh, I've never found those tools to be useful. In my experience, Pair Programming is not only about code but also about processes (git, pull requests, the CI, IDE features, company internal tools ...). It's also inefficient if the involved team mates have different IDEs or habits ...
As of today, I've found nothing better than screen sharing. And screen sharing could totally be improved because, afaik, you have to choose between correct interaction (ability seamlessly to take control of the distant screen) or correct image quality (Zoom is pretty impressive).
Also, I'm open if you know collaboration tools with good screen sharing quality AND intuitive collaboration tools / distant control.
Those tools cannot work, IMO, because programming never happens only in the IDE.
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.
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…
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.
I'm no big Atlassian fan to put it mildly, but this is actually more brilliant than it sounds:
Reviewing a pull request from the comfort of your IDE/editor, complete with ctrl-click navigation working, that is sometimes a game changer.
This setup honestly sounds envigorating; I'm currently in a predicament where my course requires the use of Windows-only software, so I'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.
The author hasn't specifically mentioned any Windows-specific setups here, but I'm sure it's possible with QEMU, a VPN, and some other tricks.
Fully agree, this direction sounds like nightmare fuel to me.
Not saying I prefer remote IDEs, just that they are more a symptom here and not the root cause.
That said, I can't speak for the Mac users of the world. I've watched people make $30 an hour hunting down DMGs online...
- IT doesn't have the hardware ready
- New team member is inexperienced in using an IDE, but the entire development environment setup is GUI based
- New team member is inexperienced in a CLI, but entire dev environment setup is CLI based
- New team member is working from home and hasn't received hardware for new start date on their first day
- New team member is a fresh graduate, and needs actual mentoring and training
- Link rot/outdated documentation on setting up a dev environment.
- New person may not be technical (I work in games, we have artists)
- Working from a location where internet speeds to download a toolchain, OS updates, docker images are slow.
You can just take a look at the pull requests and commits.
Dev A writes a lot of small commits and then re-orders them before pushing. Dev B has hours where his environment seems idle and then has a typing spree in between 9PM and 2AM. Dev C knows a lot more than A and B about the debugger.
Trusting any given company is akin to trusting a snake not to bite you if your hand smells like a mouse. You might like to think there is some affection there, but you're simply anthropomorphizing something which is incapable of more than its nature.
Isn't then an employee a soulful being that exists for the purpose of extracting as much value from the employer as possible with the least amount of work delivered to only provide value to itself in a form of an end-of-month salary?
Employers and companies are built of people. Calling them a soulless construct and pretending everyone in the world is out there to get you is not a healthy attitude.
The employee is one person, which you can choose to trust or not.
The employer are multiple people. Of these, maybe dozens or hundreds can impact employee's work. You can trust all of them or not. This is the crucial difference.
On the other hand, a company is an entity almost singularly driven by the need to maximize profit for shareholders. I have seen multiple teams work months of crunch time, only to be cut loose shortly after they delivered for the sake of 'streamlining'. Now, did the management who did the firing agree with that course of action? Heck no! They were livid. Many walked. But the C suite decision makers found cost savings that would give them fat bonuses and decisions were made.
I often wonder why the same people who are so hesitant to trust government turn right around and blindly trust corporations. The snake is not evil. The snake is a snake. Calling this view toxic or unhealthy does not change the facts on the ground.
IME employers can actually sense this when it happens and a lot of the ridiculous bullshit you would otherwise have to put up with melts away.
You ain't ever being a partner working on the checkout tills at walmart ;-)
Actually, if you decide to use your own computer for work then remote IDE is probably better solution in terms of security and privacy of your own computer. You don’t have to worry that something nasty will be installed (be it malicious NPM package or spyware from employer).
And do everything else in a tiled terminal window, I have always open anyway.
[0]: https://github.com/cdr/code-server [1]: coder.com
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 never worked directly for Sun, though I did have a hell of a lot of dealings with both the Church and State sides of their business.)
I'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.
This feature would of course need to be togglable on/off.
You still have one character to start (tab?) and end (backspace?) a block, but now they are overloaded with the edition keys, and still need to keep track of the block with the same visual aid (indentation).
The small changes I see are to the worse, that is overloading the keys and not letting you see the text verbatim.
Sure, a good IDE will automatically create indentation when you type '{', so you need to only type a single character to start the block. We could actually say '{' is a shortcut key to start a block. IDE creates an indentation and draws a vertical line to enhance visual presentation of the block. Visually, braces are more or less just a noise, so removing them would improve "signal to noise ratio" and enhance reading experience.
However, logically braces are better at defining blocks of code than tabs. With braces we have start '{' and end '}' characters, but with tabs each line needs to be indented by a correct number of chars (tabs/spaces).
I am wondering, if we can have best of both worlds.
In some cases we are trying to draw visual indications with text. Wouldn't be better, if we let the IDE do the drawing? Eg.: two vs four spaces of indentation? It doesn't matter, if you can configure visual indentation depth on the fly in the IDE.
There are languages like Python that uses "significant white space" where there are no curly braces and instead you use indentation to decide where a block ends. The problem with Python is that my editor has no way to know
And that's why better languages use the keywords "begin" and "end" in stead.
AKA, a screw -- so in the long run, we're all screwed.