14 ms·

The End of Localhost

126 points by swyx 4y ago

hoseja 4y ago
Vomitous. Bleak. Dystopian.
mutant 4y ago
>Fast gigabit internet is cheap and everywhere (5G or mesh wifi) Privileged much? What a high handed way to start an article. https://www.theverge.com/22418074/broadband-gap-america-map-county-microsoft-data https://www.theverge.com/22418074/broadband-gap-america-map-... I am very happy for you that you live in an area that is well connected, however, there are a shitload of people that do not have those kind of options. .
dottedmag 4y ago
> But surely you can see that the latency question is a question of letting the Moore's law equivalent of cloud commoditizing infrastructure take its course. If it's not good enough today, then wait 5 years and check back again. Wait, speed of light also improves exponentially?
- pantulis 4y ago
  Speed of light is negligible here. Latencies from your computer to its connected display are measured in ms, the same order of magnitude to move bits across the ocean. It's "only" a matter of moving more bits at the same time across the networking infrastructure as the cloud gaming industry is doing.
  - FredPret 4y ago
    I see you haven’t clicked on a GUI on a server a continent or two away
  - azeirah 4y ago
    I tried Jetbrains remote workstations with Jetbrains space. I had a pretty reliable ~150ms connection. It sucked SO BAD. 150ms + input latency before I see a response? It's a horrendous experience. Ask any pro gamer what they think about gaming with a ping higher than 20-30. Same thing for development.
    - scottlamb 4y ago
      > 150ms + input latency before I see a response? It's a horrendous experience. Definitely, but there are ways to mitigate that: * Better design. With VS Code Remote or Google Cider, the code is stored remotely and the language server runs remotely (so there's lag before the completion pull-down appears) but the UI is local. Characters you type should appear with no round trip required. That seems like table stakes for a good remote development environment in the world the author describes. You can also imagine some prefetching of near-future likely completions [edit to clarify: e.g. prefetch the completion menus that will appear if the user starts typing any of the locals in scope, including not only the names of the locals but also their methods] so that latency is hidden too. For CLI stuff, mosh predicts the characters you type will echo and corrects if not. etc. * Closer datacenters. Typical RTT from Los Angeles to New York is ~66 ms. 150 ms is far! * Lower index of refraction. Instead of traditional fiber, hollow-core fiber or bouncing off LEO satellites like Starlink. Not going to happen universally by 2030, but it will happen some day.
  - IHLayman 4y ago
    I work for a Japanese company from the east coast, and I can tell you from personal experience that latency matters and that you can't beat the speed of light. 1 light millisecond is about 186 miles. Communicate with a server halfway around the globe and you have a 277ms round trip. On a reaction test online my reaction time is 243ms, but I am pretty slow at reactions. My typing speed is about 70wpm (about 350cpm or a character every 100-150ms). Trust me when I say that people notice slowdown when response is >100ms. So ok, you'd think that 9300 miles is close enough (50 light-ms each way), but even that can show lag because your infrastructure needs to react to whatever you are typing (even Vim nowadays will connect to a language server to do tab completion and symbol lookups) and then send you a legitimate response. And all of this is ignoring the most obvious arguments: * Your local silicon is fast enough to do development and has been for 10 years now. Stop using a bloated IDE. * If you production environment is so different than your local simulation of that environment, then you have bigger problems. * Why rent your compute per month when you can own your compute and use it however the hell you want to use it?
- rajko_rad 4y ago
  hahah isn't the solution to this just edge computing? e.g. cloudflare workers, fly.io, or seaplane? Can't solve the speed of light, but can certainly reduce the distance... Like it or not, enabling many collaborative apps already requires solving this today, lots of work in that direction!
jaywalk 4y ago
> But I Need To Code on a Plane? Maybe stop flying so much. Or get a good audiobook and rest your eyes. Maybe even talk to your neighbor! (if they seem social) Get out of here. Airborne Internet access has gotten good enough that I spend most of my flight time RDP'd into my development machine over a VPN. It works surprisingly well, and other than occasional latency spikes I find the single, relatively small laptop screen and touchpad to be more of a hinderance than the Internet access.
- ravenstine 4y ago
  I agree. I've both done Zoom calls and watched YouTube videos in HD over plane wifi. There's only one zone towards the end of my trips to the other side of the country where it stops working, but hopefully more dead zones will be patched over the next decade. Internet access makes all the difference in my ability to tolerate long flights.
  - rajko_rad 4y ago
    There should be good models already or emerging soon that support temporary local dev and then merging envs when connected back... that seems like the inevitable model unless I am missing something here?
frizlab 4y ago
No thanks. I like having stuff on my machine.
- pantulis 4y ago
  It's not a matter of personal preference if your work for someone else. This stuff is bound to happen in the years to come. Local development of course will still be possible but will become the minority in the global workforce.
  - falcolas 4y ago
    The company I work for has enough services that the entire stack can't be run locally anymore. But we have found ways to make it local development work regardless. And so will other companies, since it's a definite productivity boon.
joshstrange 4y ago
One good work around for this that I've found (it's not perfect but it gets the job done) are Cloudflare tunnels. You could also use something like ngrok but you can use CF Tunnels for free. I just setup projectname.mydomain.com or projectname.local.mydomain.com and I have that use a CF tunnel to my local dev environment.
ravenstine 4y ago
> Github "left our macOS model behind and moved to Codespaces for the majority of GitHub.com development". Yikes. I wasn't planning on working at GitHub, but I definitely wouldn't if that quote is genuine. Imagine actually being forced to use VS Code to do your work. I love VS Code, but it seems wrong to center the team's workflow around it. I guess you're screwed if you want to use Vim or Sublime? "Oh, but there's plugins for that!", I can hear someone say. Yeah, f--- that sh--. And after all, who's to say that GitHub Codespaces won't someday drop VS Code when it's no longer in vogue? GitHub Classroom touted its Repl.it integration and then deprecated it almost immediately without an equivalent alternative (just use VS Code bruh), so it's not that farfetched.
- danielvaughn 4y ago
  I agree that being literally forced to use Codespaces is kind of shitty. On the other hand, establishing code consistency is important, and it all depends on your editor's linter/prettier. They have to produce the same output, and even managing that within the same editor is difficult because you might have different versions on each dev machine, or different user settings. Doing so across editors is even more difficult.
  - thebean11 4y ago
    Prettier / linter can just be run in a git hook and verified in a GitHub action / CD step though. Prettier config should be committed to the repo itself, then let devs decide how they want to apply it to their workflow (and prevent them from merging otherwise).
  - gscho 4y ago
    There's also the benefit of "dog fooding" their own product that they're selling to customers.
- thebean11 4y ago
  The "run the whole dev environment in the cloud" part actually sounds pretty nice. 10 seconds to have everything running?? And I assume you can switch between multiple environments you have saved, tied to branches? That's pretty sweet and opens up tons of opportunity for server side build caching to speed things up (don't need to compile the packages you aren't modifying). Is VS Code actually required, or is there some way you can edit source code locally then push to codespaces to actually run it?
twblalock 4y ago
There are a lot of weak overextended arguments in this piece which reduce its credibility and persuasiveness. One example: just don't code on airplanes. Or how about this one: > To argue against localhost eventually going the way of the Dodo is to do the developer equivalent of asserting that most people want to run their own generators or grow their own food. Come on. That's not a serious attempt to persuade. It's practically a rant.
- deleted 4y ago
  [deleted]
- yjftsjthsd-h 4y ago
  > asserting that most people want to run their own generators Also, lots of people specifically have generators to cover when the grid fails them. Like, I'm actually okay with the claim, because that's an argument in favor of local development.
  - doctor_eval 4y ago
    Yeah - my new house is about to get covered in solar panels, and I can’t wait!
api 4y ago
Also no privacy at all, ever. Every single keystroke is watched. Everything you run is profiled. All your data is logged, scanned, probably stored forever, and probably data mined. It'll start at work of course but eventually the whole ecosystem will shift and it will no longer be possible to develop software without the cloud watching every single thing you do. Someone doesn't like what you're building? It will suddenly vanish and take all your work with it. Price goes up? Tough. Pay the rent or all your work vaporizes. This whole trend is deeply, distressingly dystopian. It's a total inversion and reputation of the whole concept of personal computing and everything associated with it, a return to the mainframe era but worse because big data and AI make mass surveillance and automatic control so easy. It's equally distressing that most developers don't even understand the trend enough to push back on it. They don't grasp the fact that the difficulty of local system administration and the general over-complication of everything is driving this, so they don't address any of those problems. In fact they keep making them worse. Development environments keep getting more and more complicated and fragile, making a move to a shared centrally managed cloud environment more and more tempting.
- margarina72 4y ago
  This. I was wondering if anyone was going to mention it. All dev in the cloud is the dream for a full monitoring solutions. Finally able to bust the lazy and unproductive folks...
  - api 4y ago
    Even worse, I foresee a future where there are bots in the cloud that interrupt the development or execution of software that violates the ToS. I think these may already exist, though usually for very specific things like cryptocurrency mining. I could see this broadening. I could also see the government getting involved then and mandating it. "We're sorry, our system detected that you are developing end-to-end encryption software without the proper safeguards in place. Your account has been locked..."
longrod 4y ago
> Fast gigabit internet is cheap and everywhere (5G or mesh wifi) Right. Most of the world doesn't even have 5G yet. Besides no matter how fast you get with internet, its still internet. There is still latency which makes for a frustrating UX. I wouldn't want to be fully cloud based even if I had free internet for life. That's a recipe for disaster. The best thing about local stuff is...that it's local. I don't need an internet to access it. That's extremely convenient. But putting that aside there's still cost of running things live (outside the internet cost). And why would I want to pay extra for something I can easily run on my machine locally? Live is for production code that multiple people will access. Local is good enough for me. I would even prefer to self host most of the stuff locally on a Raspberry Pi or something instead of a cloud hosting. It's just so reliable.
- sigmonsays 4y ago
  to further this along, often i code without internet and just have VMs on my laptop. I think assuming internet is everywhere for development is wrong.
  - Lev1a 4y ago
    I'd go so far as to say that "Internet will always be available" is the new generation of "Works on my dev machine, thus it should work everywhere", which was a (common?) assumption over the last few decades.
    - satyrnein 4y ago
      Aren't people moving to cloud dev environments to solve the issue of "it works on my machine (using emulators, etc)"?
      - Lev1a 4y ago
        Sure, but by doing that they move under the above mentioned assumption that (fast) internet is always available to all the users, devs, etc. AFAIK the last big push to get out of "it works on my machine" was the JVM which has become a bloated, inefficient mess that a vast chunk of the industry uses anyway, because most often it's deemed "good enough" and Java, Kotlin etc. devs are relatively easy to find and/or train compared to "native" development in say C/C++, Rust, etc.
ary 4y ago
This is a ham-fisted attempt to get attention using controversy, and the arguments are so weak they can't even make me mad. Computing of any kind (including software development) moves around all the time. Sometimes it's more economical to do something with a bunch of servers over the internet, but less privacy preserving. Then user devices become more capable and it's suddenly possible to do everything you need on device and the platform(s) you're targeting all have enough lowest-common-denominator support to make it feasible. On, and on, and on. This "article" boils down to a myopic view of the industry that is almost solely supported by the solutions very large development teams have had to come up with to handle their human scaling issues.
- bbertelsen 4y ago
  Agree, 100%. I was about to comment that this must be a jest - but aiming for controversy is surely the more accurate interpretation.
  - daveloyall 4y ago
    Alternative interpretation: the author is having a stroke. See how they miscategorized the "soul-stifling metaverse" tweet as "extremely positive". ...That's not what the tweet is saying... :)
- dogleash 4y ago
  Arguing this point is all downstream from the fact software complexity has turned our general purpose machines away from general purpose use. Going with the path of least resistance is fine, often a commendable decision. Water flowing over rock can carve a canyon. But arguing that the canyon shape is where the river ought to be? Not for me.
- dx034 4y ago
  Absolutely, and there's never one true solution. Over the past decade, I've moved multiple times from working remotely (thin client) to locally and back again. It's only problematic if people think everyone now has to follow one model. As long as you accept that some work profiles/companies/industries work better with remote or local, we can all profit from increased choice. I believe local development will never go away, as well as thin clients will never go away. You just need to find what works best for your situation.
juancn 4y ago
Lightspeed is still an issue. I've done remote development and it sucks. Even with gigabit connections, ~150ms latency can kill you. Maybe you can keep the editor local, and have it hide the latency for you, but debugging? With anything over a few ms latency remote debugging is impossible (or at least extremely annoying). Step over? Wait a few seconds to a minute until the debugger issues one call to get each variable in scope and all the other goodies. Debuggers assume local environments, we would need new tooling that's latency aware to handle this, in every major language and platform. I don't see this being good enough for serious dev work in a long time. It will work for some niches though, specially if you're close enough to the datacenter hosting your infrastructure. In a sense, a local git repo with an IDE, and a cloud unit/integration testing pipeline is as close as we get now, but every once in a while, you need to run at least a little bit locally to be productive.
- zaptrem 4y ago
  Even with a crappy DSL connection I haven't routinely seen >70ms latency for years. Modern cable/fiber/LTE/NR connections are all well under 50ms. Even then, we have realtime games with lag compensation that make that connection instant. Your problem sounds like a badly written app, not a tech limitation.
  - sophacles 4y ago
    What definition of latency are you using here?
  - falcolas 4y ago
    > connections are all well under 50ms This depends entirely upon where you're connecting to, and from. For example, I can't connect to us-east-1 servers with under 50ms of latency, because I'm out in the rural west, and my connections run a thousand miles south before getting on a good east/west backbone. Spikes are not uncommon. > we have realtime games with lag compensation that make that connection instant When the prediction algorithms are correct. When they're not, you start seeing some uncanny behavior that you can't predict or compensate for (dead-on shots missing, actions being rolled back, etc).
barnabee 4y ago
Let’s not do this. It is a gross vision for the future. I hate the cloud. IMO we should be working towards self hosting appliances, federated and otherwise decentralised services, and local-first applications.
- amelius 4y ago
  The future looks cloudy.
no-s 4y ago
Futurists extend trends, but innovation defies trends. So this article is about futurism, not innovation. I would believe the blurring of cloud, edge, and localhost more than this. I think it’s reasonable to believe network splits (physical or political or economic) will always be with us and thus the need to support disconnected computing will continue...Serverless/FunctionsAsAService could work this way. So? Maybe provisioning to an edge is a reasonable thing. The article mentions edge workers; the edge worker can be at localhost. The provisioning system can incorporate localhost. But yeah, localhost becomes livestock instead of pets...local computing power will still be a thing. Anything that needs ultra-low-latency or disconnection tolerance will be reified to task, like smartphones or smart munitions, or developer tools, or spaceship computers...not really too different from what we have now.
ramesh31 4y ago
Localhost will always be free, and the cloud will always have a cost. For that reason alone, localhost isn't going anywhere.
- kaetemi 4y ago
  Yep. Most of the people I know don't want to pay subscription fees for cloud services, when their own desktops are powerful enough to run what they're working on. Just automate localhost development environment deployment.
- ozim 4y ago
  I think article is arguing that localhost still has cost when onboarding and maintenance cost that is not really that visible because maintenance happen while devs are doing other task - but usually it is included in some task to setup some config. So I would agree localhost can be basically free, only that company has to keep developers in-house and not burn through 10 juniors each quarter. If company wants to burn through people like Amazon in warehouses then having cloud dev-env is way to go.
- mnd999 4y ago
  Which is why it appeals to GitHub / Microsoft. Now you have to pay them for something you used to do for free.
- satyrnein 4y ago
  Localhost isn't free, we buy more expensive laptops for developers than any other teams.
rglover 4y ago
No. This is the absolute wrong direction. In effect, you're giving a third-party absolute control over your code and your ability to work on it. You're also disconnecting the developer's mental model of how all of this stuff works (arguably why there's so much bad code floating around). Eventually, that will devolve to people not knowing how any of this works and the industry will collapse. It's an abstract line of argumentation related to this, but Jonathan Blow nailed it on this idea a few years back: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk
- smoochy 4y ago
  I was reading your comment and thought of Jonathan Blow's talk. Without even clicking the link, let me guess, that's from Moscow's 2019 conference? EDIT: yes, it is. He has a very important point there. I recently went on Twitch to see what young devs where coding. One (rather smart, I must say) young lady was creating a simple sign in/sign up page, but there's a twist: with React. Upon me asking, why wouldn't she just code it in plain HTML, she responded with a question: "but how would it connect to the API?". So there you go, ladies and gentlemen. I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old.
  - rglover 4y ago
    Yup
  - rglover 4y ago
    > I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old. I'm working on it: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick. The tl;dr is that I'm offering a full-stack framework that takes advantage of vanilla JavaScript and HTML in a front-end framework combined with a plain ol' HTTP back-end using Node.js. The APIs abstract just enough to make you productive but not so much that you can't reason about how it'd work without the framework. The long shot of the project being to keep the mental model of "how the web works" intact while reducing the burden of doing everything from scratch.
trasz 4y ago
I'd argue the exact opposite: with each year the cloud makes less and less technical sense. Local computing power, storage, and networking are getting cheaper all the time, while cloud services really aren't, and won't because of their business model. Cloud is also risky for security, privacy, and business (hard dependency on a single vendor) reasons.
jrochkind1 4y ago
As a developer who works in very small teams/orgs, though: Will you need a "devops" team of 10+ just to create and keep the cloud-hosted development environment working? Cause that's why I currently prefer avoiding even docker for my dev env.
- habitue 4y ago
  This is what companies like Gitpod do, they are the devops team, and you just manage the dockerfile that determines what the dev environment looks like.
- satyrnein 4y ago
  In the ideal case, you stamp them out using basically the same docker/terraform/etc you use for managing production.
ranger207 4y ago
I am currently (literally waiting on a EC2 Image Builder pipeline to complete as I write this) rewriting our dev VM to work on EC2 rather than VirtualBox on our MacBooks. I'm doing this for two big reasons: One, the VM won't run well on future Macs. We're using Intel MacBooks on Big Sur because there's a bad interaction between Monterey and the VirtualBox kext that I can't figure out; and because making our VMs work across Intel and ARM would require a rewrite. Second, and more importantly, debugging why the VM isn't working on someone's laptop is a massive pain. My goal in moving the VM to the cloud is to reduce the surface of things that I have to troubleshoot. If ssh works on your laptop then (the hope is) I don't need to mess with your laptop any more. If the VM breaks, then when I fix it it'll be fixed for everyone at once. Believe me, that's not the case with the local dev VM despite the entire thing being scripts in a git repo. I'm trying my best to keep the new dev experience as painless as possible, but at the same time, moving the VM to work in a consistent and stable environment also improves the dev experience along with my operational experience. It'd be fantastic if we could run everything locally and nothing ever broke and everything that worked on my machine worked on prod too, but that's simply not the case
habitue 4y ago
dev/prod divergence isn't the reason to do dev in the cloud. The reason you do dev in the cloud is dev/other-dev divergence. I'm a big fan of doing dev in the cloud (at least for work, no way I'm doing that for personal projects). Currently we use Gitpod, it works pretty well. Spinning up new people is easy, and so is keeping everyone's environment up to date with each other. But even in the bright shiny future of 2030 the dev environment is always going to differ from the production environment because... developers need a bunch of stuff in their image that you don't want installed in production.
prmoustache 4y ago
Sounds like almost a week of additionnal days off from both cloud vendor and local power outages. :)
LinuxBender 4y ago
All the Cloud's A Staging Env, and All the Laptops Merely Clients This fantasy has been pushed since at least 1996 but that really died off when mainframes were no longer the only option. Sure, my old Wyse terminal fits the bill but I have not powered that thing on since ... actually I don't remember where I left it. Cloud providers will always be a thing and local software daemons will always be a thing. There is a time and purpose for both. Anyway, I tried to convince some development teams to go this route some time ago and use Chromebooks with Citrix farms so that their work remains in a safe location. That idea died faster than I came up with it. There were entire teams that would have outright quit had I forced the issue. We did use that concept for some sensitive customer data debugging but never for development or staging. General purpose computation on your own machine is probably going to be illegal in 20 years... Some companies would love for us to believe that. Maybe some day politicians will be lobbied into making some services cloud-only. Unless their business model already fits being cloud-only I would expect such legislation to bankrupt some businesses or hurt them enough that the SEC or someone else that cares about tax revenue intervenes. Microsoft has been trying to move Windows in this direction, to require an internet connection and connectivity to their cloud and accounts on their public AD servers. The latest IBM/Redhat Fedora Beta hints at moving in this direction as well. I do not participate in such things but that is my personal preference.
- nerdponx 4y ago
  The Wyse keyboards with Cherry mechanical switches are sometimes worth something. The keycaps are super cool too.
chazeon 4y ago
As a computational physics student, I am recently moving to fully embrace the model describing in the article. I work on multiple HPCs, and now I use a machine (m720q) as proxy that SSH onto HPCs and run code-server there. From my laptop, I just visit the website on this m720q machine, and everything is done via a browser. Besides code-server, I also run a JupyterLab instance on the machine because we are not allowed to run jupyter on HPC's login nodes. All scripting / terminal is now done through the code-server (similar to GitHub Codespace). Tailscale allows me to access this proxy server outside home. On embracing this this model avoids moving large files GB+ from remote to local machines via SFTP, and I can avoid typing SSH commands every time I go from home to school. Code-server allows me to run more things on HPCs instead of local machines. Previously I used VSCode Remote, the latency might interrupt the connection, and now with code-server this is no longer a problem.
throwaway787544 4y ago
I've noticed that if developers can't run their code in some hand-crafted one-off buggy inconsistent mutable local environment, they freak. To the point that they're fine with using some proxy to a remote K8s cluster as long as their application code is executing locally. My guess is they fear a lack of control, and a local environment makes them feel safer, like they aren't stumbling in the dark trying to figure out how to make an app work. Most developers don't really understand the cloud at all, and that lack of understanding combined with their local env baggage is half the reason DevOps people are necessary. If devs adopted cloud native workflows, a lot of shit would be easier for everyone. It would even lead to better designs. Devs think the cloud works like their desktop, when really it's a radically different model for system design. I mean, there still devs who assume their app will use a filesystem to store data, lol!
- majewsky 4y ago
  Poe's Law applies: I'm honestly not sure if you're being sincere or engaging in deliberate parody.
- ClumsyPilot 4y ago
  > Most developers don't really understand the cloud at all Most developers don't understand how their own computer works.
- nerdponx 4y ago
  I just want to be able to test my code. I've seen software projects go fully into cloud-hosted microservices, without even a consideration of testing. It sucked.
gatvol 4y ago
Bad idea. This leads to vendor lock-in, propietary systems.
muskmusk 4y ago
Yes and no. If everything needs 5 databases, 4 queues, 3 caches and all of this is written in 7 different languages, then yeah I guess cloud is the way to go. If you just shove shit into postgres and pull it out again using something like postgraphile then I don't think cloud does much for you. The Flipside of the "computers gets faster and faster"-argument is that more and more can be done on one machine. Compute supply is growing faster than demand. Today's apps are not that much more complex than the apps of 10 years ago, but computers are much faster. Human beings read and type at the same speed today than 10 years ago so I don't really see this changing massively. Obviously all the BigCos listed can't run on one machine, but a very large percentage of stuff can.
- mike_hearn 4y ago
  Agree. A lot of the movement to try and develop everything inside Linux containers is driven by a few factors, none of which are particularly fundamental and which may see a reversal for unrelated reasons in future: 1. The insistence on doing UI exclusively via web browsers. They aren't particularly well suited to it and at some point competition for them may arise. 2. The insistence on using complicated proprietary cloud services to allow scalability, without actually doing any scalability calculations to justify it. A modern dedicated server is a staggering piece of kit. NVMe SSDs are game changers. You can scale a bog standard ordinary RDBMS setup to very large amounts of load without needing any special cloud databases at all, and it'll be easier to program. People don't realize this because they tend to think about scaling in binary terms: "it scales infinitely"/"it doesn't scale and that's bad". That sort of mental shortcut can be OK when money is free, but, well, we're entering a period where it may not be. The sort of engineers who can actually do load tests and figure out plausible maximum QPS for their load can pay for themselves quickly. 3. The fact that the only competition for Linux on the server side is cloud APIs and services, and Linux badly needs the competition. 4. The popularity of toolchains/languages with extremely weak portability layers and convoluted packaging systems. Java nailed this. Python, Ruby, Go ... not so much. This inevitably pushes people who use those tools towards using their local OS as a glorified terminal window manager for dialing in to Linux VMs because nothing works right if they try to use Windows or macOS directly. If your app genuinely needs something only AWS can provide then yes, you have to develop in the cloud and not against a local implementation. But that's a bug not a feature, and if you're in that boat then you're exposed to all sorts of problems beyond needing to develop against production (e.g. opacity of failures, unexpected cost explosions). If you can run the bulk of your app on a JVM with a Postgres connection then that's a competitive advantage - your devs can use the environments they're most comfortable with, you've got full insight into the whole stack if anything goes wrong, outages can't shut down the whole development team and you're not racking up cloud charges for development purposes.
ur-whale 4y ago
> General purpose computation on your own machine is probably going to be illegal in 20 years... This - to me - is the worst part of the article, because as much as I loathe the idea, I fear this may be correct. I am very afraid that, at the very least, you'll likely need some sort of carry permit to be allowed to write code on a machine connected to the net and where everything the machine does is connected to that permit and your identity.
ur-whale 4y ago
The solution to many of the problem outlined in the article is not to move your work env. to the cloud (which has a boatload of problems in itself) but rather to be able to transparently install a perfect localhost copy of the environment the software you're building will run in, via - whatever - containers, vm's , etc...
- viraptor 4y ago
  That's my understanding too. The article mentions: > most of these items enable (even require) you to run things "live" on the cloud, not localhost But they really don't. If having them in the cloud helps you, you can replicate the experience by running that service locally.
rad_gruchalski 4y ago
I recently develop on cluster.local and I’m happy enough :) Regarding the article: what if the „cloud company” decides to suspend your account for „reasons”?
WesolyKubeczek 4y ago
Because the world is made of bandwidth and large cities and each ISP will gladly sell you a multigigabit pipe for peanuts, and there’s 6G wireless with absolutely no outages whatsoever. Also everyone just works at FAANG or is not worth talking to. I have this weird idea of selling a globe where the only land is Bay Area. For $9,999.99 apiece. It’s being reinforced by articles like this one.
bhewes 4y ago
Haha, people who never have worked with an IBM mainframe think all this is new. Shallow IT thinking.
dzonga 4y ago
you see people / companies advocating for the cloud thing have huge interests in you/me - joe average developer to using cloud tools. BigCo's development workflow is cloud based because they own the IP. IP - being the most important word. looking at world around me, IP is what makes things tick. IP is why America industrialized, IP is why American's are spooked by the Chinese. And if a average joe like me - moves to the cloud things - where i'm using a dumb terminal n hell the browser is being streamed to me. What IP would I own. I would simply be a renter. now me your average developer since realizing IP is the most important thing - I have resolved to go the opposite route. use text files for my notes / writings. create things locally and back them locally as well. SSD's and CD's are cheap. Desktop machines are cheap - an Alder Lake i5 is as fast. and even better maybe instead of making software for the browser making local software with C++ to make sure it's portable and runs fast who's data is stored in a text file.
- jacquesm 4y ago
  That, and cloud usage means they control you, the tools you use, when you can use them, from where you can use them and that's before we get into telemetry and so on.
Klonoar 4y ago
I think the author's got a kernel of an idea and does an absolutely horrible job outlining it, considering few here seem to be catching on. Localhost will likely never die for certain sectors of programming. There's a significant chunk of stuff that doesn't need to be custom localhost setups, though - and ultimately it can smooth out the differences between dev/production in teams where this is a stumbling block. You don't need localhost to be some server somewhere that kills your ability to work with an outage - stuff like StackBlitz (https://stackblitz.com https://stackblitz.com) effectively uses WebAssembly to run e.g Node directly in the browser sandbox. This model is the first one that makes me think it's possible. You no longer have that dangling issue of "which of my NPM packages is going to try and steal from me" since it's walled off in a sandboxed environment that spins up faster than you can blink. The caveat to all of this is that we should fundamentally never let localhost die, as ceding total control to services to build on is a pretty bleak future. There's a good middle ground to find here though. A final aside: an article telling me I'm wrong for wanting to code while flying is a junk take.
teeray 4y ago
Cloud development machines are great—-secure, consistent, etc.—-right up until you have a cloud outage and your entire team’s productivity goes to zero. That’s “zero productivity” as in an elementary school snow day. Even when Github has gone down for hours, I’ve still managed to do code reviews with good old-fashioned `git format-patch` in chat.
hexo 4y ago
Another thing designed to take my money. Nothing else. Won't use :)
prima-facie 4y ago
Yeah, no. I've seriously considered moving back to Sublime Text because VSCode has become annoyingly slow for me (like waiting for text to appear). And also the Python extension auto-complete only works some of the times lately. Now imagine further bogging it down by running it in the cloud.
whoomp12342 4y ago
you know what I love about working against localhost? its LOCAL. its mine. I know its mine and no one can see it until I push my code. I have ideas. Good ideas, bad ideas, and WHAT THE FLIPPING HELL WAS ThAT idea. In the wrong hands any of those half baked ideas can not be good
jacquesm 4y ago
That's really pretty dumb. I run plenty of stuff on my local machine that has nothing to do with development, it simply runs there because I only want it to run on my local machine. So localhost is my production environment. The idea that some bozo somewhere will decide what I can do with my local machine just because they don't have a usecase for it is really meddlesome. Go and disable localhost on your own box. Leave mine alone. And that goes for the endless number of usecases that haven't been tallied yet.
- spc476 4y ago
  You haven't been assigned a corporate managed laptop yet, have you? You don't have administrative rights, and it doesn't come with any development tools (because that's dangerous), but it does come pre-installed with all the Microsoft Office Tools that spend all the their time looking for updates.
  - jacquesm 4y ago
    If they don't outright blather every keystroke you type to the mothership.
ClumsyPilot 4y ago
> Fast gigabit internet is cheap and everywhere Check your privilidge! Generally our industry is phemomenally irresponsible, there will be some life-critical service that gets built with this attitude, and no-one will realise untill some shit hits the fan - whether it's a power cut or an internet cable being cut but a digger or the AWS datacenter burning down - and then people will die.
- jacquesm 4y ago
  I think we're already there. A hospital that loses it's internet connection would have a hard time functioning and depending on the length of the outage it may very well cause people to die. Between scheduling, medication conflicts, diagnostic tools, EPD exchange, cloud connected medical gear and so on this is no longer a theoretical thing.
- scottlamb 4y ago
  > > Fast gigabit internet is cheap and everywhere > Check your privilidge! Umm, what? This is part of "the ultimate developer experience wishlist for the average rich-country developer in 2030", not a statement expected to be universally true in 2022. I think it's wildly overoptimistic, but "check your privilege" doesn't seem like an appropriate response to optimism. > Generally our industry is phemomenally irresponsible, there will be some life-critical service that gets built with this attitude, and no-one will realise untill some shit hits the fan - whether it's a power cut or an internet cable being cut but a digger or the AWS datacenter burning down - and then people will die. The "average rich-country developer" doesn't build life-critical services. If someone extends the author's techniques to a domain where they're inappropriate, that's on them.
  - ClumsyPilot 4y ago
    > Umm, what? This is part of "the ultimate developer experience wishlist for the average rich-country developer in 2030", There is a newbuild going up near me where the best connection speed is ADSL. I am willing to bet my house some parts of the country won't have reliable 100mb/s by 2040.
doctor_eval 4y ago
“Treat your engineering team like cattle, not pets”
wyager 4y ago
> Fast gigabit internet is cheap and everywhere (5G or mesh wifi) I don't need to read farther than this; I am 98% certain that the rest of the article is hopium nonsense. "Mesh wifi" has never been and never will be the solution for any large-scale networking cost/performance issue.
marginalia_nu 4y ago
Ugh, I know right. You're tired of owning your house :-( That's what people did in the past. Eww. Leave the past behind! The past is bad! Instead, live in the cloud! Sign this easy form and transfer the property rights to me, and for a monthly bill, you will be entitled to visit the building. Need to use more than one room, need to turn on the lights or use the stove? No worry, you will be billed separately for abnormal usage.
- namaria 4y ago
  Oh and we deprecated toilets. Too much maintenance work.
  - marginalia_nu 4y ago
    Imagine having bodily functions! Horses have bodily functions! Get out of here, grandpa!
nathias 4y ago
are mainframes popular again?
borland 4y ago
This is a terrible idea. Understanding what's "underneath you" in the stack is a critical ability when things get complicated. In my experience, running the stack on your local machine as a developer gives you a huge boost in understanding the stack, being able to profile, inspect, and reconfigure it as needed. Sure, it's quick, convenient and easy if your dev stack is also the cloud stack, because you save time not trying to figure out why localhost mismatches the cloud. BUT, when things get messy, having that understanding of HOW EXACTLY your localhost mismatches the cloud gives you a great depth of knowledge, which you can then use for great benefit in the cloud. Also: remote debug tooling is crap.
Existenceblinks 4y ago
Could be done with Erlang hot code reload with pull request in between.
eatonphil 4y ago
I don't agree with this idea at all, at least not about using high-level cloud services as your development portal. But I do do almost all of my development in a server in Canada (I'm in NYC, though latency while traveling in Korea right now is worse). I control the server though.
aenis 4y ago
This is ignoring the speed of light cap. Its not going to be possible to keep all those increasingly complex, distributed systems in sync with low latency. Its not going to be possible to instantly run a series of tests that depend on each other if they run somewhere 10ms away. Not to mention all of this is energy inefficient. I am all for productity gains but this is just nonsense.
brobdingnagians 4y ago
You can make development more complex to match production and then layer more and more complexity on to to make it convenient (and brittle) or you could simplify production so that it is straightforward, replicable, and bulletproof. I know which one I prefer. It would be better to simplify and streamline the system than to layer abstraction upon abstraction is a bizarrely escalating tower that needs more complex "fixes" to counter the complexity, which increases complexity for the next round.
quest88 4y ago
Not one mention of cost. Money just goes on trees!
nunez 4y ago
Lol. Yes, let's tow our hitches to the most unreliable and expensive component in our stack and call that progress. An app in 2030 (or, hell, 2022) should be reflexive. If it works in production, it should work on your machine, without any code changes, and vice versa. Therefore, devs should _absolutely_ be able to iterate locally with this guarantee (enforced by CI). I do agree that the ability to quickly create an ephemeral, scaled-down version of the app's production environment in $CLOUD is important, particularly for integration testing. But using that for full-time dev isn't a good idea IMO. Slightly unrelated, this: > But I Need To Code on a Plane? > Maybe stop flying so much. Or get a good audiobook and rest your eyes. Maybe even talk to your neighbor! (if they seem social) is where I stopped reading. Absolutely appalling lack of empathy. I normally fly for work. The flight is the time I use to get shit done that I can't during the week. I hate small talk. So I'll continue coding on the flight, thanks.
GekkePrutser 4y ago
> "General purpose computation on your own machine is probably going to be illegal in 20 years" Yeah this is exactly my worry with these things. I don't mind the cloud being a thing. But I don't want to be forced to use it. Especially in my private life - work can decide what tools we should use there, that's their prerogative. Though I personally think it won't come that far but that the real barrier will be that we just won't be able to but decent PCs anymore because everyone will be using what amounts to thin clients (think Chromebook etc)
andrewprock 4y ago
And so the cycle repeats. Thin client, fat client, thin client, fat client, ...
vlovich123 4y ago
It’s not one or the other. It should be trivial to deploy to prod without complex configuration (modern edge compute platforms seem to do a good job of this). However, local testing should definitely still be a thing. You may have gigabit but you’re still potentially traversing the world - latency is going to lengthen the duration of your test suite. Plus when deployed you’re dealing with flakiness that’s totally outside your control (external internet connectivity of CI tends to be flakier than local connections). In terms of equity, I have not seen gigabit fiber be widely available. Nominally I have gigabit cable in San Francisco although real world performance is much wider variance than one might hope. And some junior members at the start of their career may be choosing to be as economical as possible (eg using just a cellular hotspot through their phone for all their connectivity needs). Heck, at the office I get maybe 50 mbit/s out of the wifi with no wired option (and that’s not talking about the quality of the wifi). It’s a nice idea and may work on small teams. For anything moderately complex, you’ll want local AND cloud, not OR. Also make sure to design for both from the get go. Source: I’ve seen the gamut of what works and keeps testing infra humming smoothly along for dev teams of all sizes/maturity. Everyone learns the lesson of being able to run tests locally at some point. Remote development on cloud servers can work and is an orthogonal thing. But if possible don’t use cloud services if possible (ie use local simulators/emulators if possible and they do a decent enough job).
xedrac 4y ago
And here I struggle with the latency of local programs built on Electron. I can't imagine developing in the cloud all the time. Maybe the next generation of developers can go down that path and eventually rediscover the wonders of localhost.
jhoelzel 4y ago
I strongly disagree and in my opinion the future approach should be dev containers. They run on macs just the same as windows and if you habe a potato for a work machine you might as well develop in the cloud. Localhost will not go away. Especially with containers and machines that have more than 16 cores it just does not make sense to deploy to the cloud. In the least least energy wise, its horrible. I have been taking this approach with a lot of clients over the years and the ability to just delete a container of my machine and be compliant with my nda when the project ends is a godsent. Also I would like to point out how well desktop cluster like rancher desktop actually bring k8s into your home effectively.
ramoz 4y ago
Lol.
ar-nazeh 4y ago
He meant positive as in "believe it will happen", not positive as in supportive. And in that sense, it was extremely "positive" (general purpose computing being outlawed after it becomes so fringe only a minority with little political power still wants it for personal use)
anothernewdude 4y ago
I worked on a project that gave up on local development because of reliance on some cloud database. Frankly sharing a DEV environment between three developers is something I'll never do again. Slowest development iterations I've ever seen. Waiting minutes for tests, builds and then deploys, only to find a trivial issue that localhost would have found in seconds. Now I'm on a project with serverless components, and it's all runnable locally. With containers there's no excuse for being unable to run on localhost. It may take time for this to play out across companies, but the ones adopting this way of working are going to lose.
namaria 4y ago
Is the argument here really "let's all go back to using dumb terminals and make The Cloud a remote mainframe"? How is this a net gain for individuals? We have these magnificent 16 core, 32 gb local environments and we should give up control because hype? Right
junon 4y ago
Hard, hard disagree with just about everything in this article.
ohCh6zos 4y ago
The cloud, the whole thing, was a mistake. I host everything locally, because AWS makes every action needlessly complex.

126 points by swyx 4y ago

Vomitous. Bleak. Dystopian.

>Fast gigabit internet is cheap and everywhere (5G or mesh wifi) Privileged much? What a high handed way to start an article. https://www.theverge.com/22418074/broadband-gap-america-map-county-microsoft-data https://www.theverge.com/22418074/broadband-gap-america-map-... I am very happy for you that you live in an area that is well connected, however, there are a shitload of people that do not have those kind of options. .

dottedmag 4y ago

> But surely you can see that the latency question is a question of letting the Moore's law equivalent of cloud commoditizing infrastructure take its course. If it's not good enough today, then wait 5 years and check back again. Wait, speed of light also improves exponentially?

pantulis 4y ago
Speed of light is negligible here. Latencies from your computer to its connected display are measured in ms, the same order of magnitude to move bits across the ocean. It's "only" a matter of moving more bits at the same time across the networking infrastructure as the cloud gaming industry is doing.
- FredPret 4y ago
  I see you haven’t clicked on a GUI on a server a continent or two away
- azeirah 4y ago
  I tried Jetbrains remote workstations with Jetbrains space. I had a pretty reliable ~150ms connection. It sucked SO BAD. 150ms + input latency before I see a response? It's a horrendous experience. Ask any pro gamer what they think about gaming with a ping higher than 20-30. Same thing for development.
  - scottlamb 4y ago
    > 150ms + input latency before I see a response? It's a horrendous experience. Definitely, but there are ways to mitigate that: * Better design. With VS Code Remote or Google Cider, the code is stored remotely and the language server runs remotely (so there's lag before the completion pull-down appears) but the UI is local. Characters you type should appear with no round trip required. That seems like table stakes for a good remote development environment in the world the author describes. You can also imagine some prefetching of near-future likely completions [edit to clarify: e.g. prefetch the completion menus that will appear if the user starts typing any of the locals in scope, including not only the names of the locals but also their methods] so that latency is hidden too. For CLI stuff, mosh predicts the characters you type will echo and corrects if not. etc. * Closer datacenters. Typical RTT from Los Angeles to New York is ~66 ms. 150 ms is far! * Lower index of refraction. Instead of traditional fiber, hollow-core fiber or bouncing off LEO satellites like Starlink. Not going to happen universally by 2030, but it will happen some day.
- IHLayman 4y ago
  I work for a Japanese company from the east coast, and I can tell you from personal experience that latency matters and that you can't beat the speed of light. 1 light millisecond is about 186 miles. Communicate with a server halfway around the globe and you have a 277ms round trip. On a reaction test online my reaction time is 243ms, but I am pretty slow at reactions. My typing speed is about 70wpm (about 350cpm or a character every 100-150ms). Trust me when I say that people notice slowdown when response is >100ms. So ok, you'd think that 9300 miles is close enough (50 light-ms each way), but even that can show lag because your infrastructure needs to react to whatever you are typing (even Vim nowadays will connect to a language server to do tab completion and symbol lookups) and then send you a legitimate response. And all of this is ignoring the most obvious arguments: * Your local silicon is fast enough to do development and has been for 10 years now. Stop using a bloated IDE. * If you production environment is so different than your local simulation of that environment, then you have bigger problems. * Why rent your compute per month when you can own your compute and use it however the hell you want to use it?
rajko_rad 4y ago
hahah isn't the solution to this just edge computing? e.g. cloudflare workers, fly.io, or seaplane? Can't solve the speed of light, but can certainly reduce the distance... Like it or not, enabling many collaborative apps already requires solving this today, lots of work in that direction!

jaywalk 4y ago

> But I Need To Code on a Plane? Maybe stop flying so much. Or get a good audiobook and rest your eyes. Maybe even talk to your neighbor! (if they seem social) Get out of here. Airborne Internet access has gotten good enough that I spend most of my flight time RDP'd into my development machine over a VPN. It works surprisingly well, and other than occasional latency spikes I find the single, relatively small laptop screen and touchpad to be more of a hinderance than the Internet access.

ravenstine 4y ago
I agree. I've both done Zoom calls and watched YouTube videos in HD over plane wifi. There's only one zone towards the end of my trips to the other side of the country where it stops working, but hopefully more dead zones will be patched over the next decade. Internet access makes all the difference in my ability to tolerate long flights.
- rajko_rad 4y ago
  There should be good models already or emerging soon that support temporary local dev and then merging envs when connected back... that seems like the inevitable model unless I am missing something here?

frizlab 4y ago

No thanks. I like having stuff on my machine.

pantulis 4y ago
It's not a matter of personal preference if your work for someone else. This stuff is bound to happen in the years to come. Local development of course will still be possible but will become the minority in the global workforce.
- falcolas 4y ago
  The company I work for has enough services that the entire stack can't be run locally anymore. But we have found ways to make it local development work regardless. And so will other companies, since it's a definite productivity boon.

joshstrange 4y ago

One good work around for this that I've found (it's not perfect but it gets the job done) are Cloudflare tunnels. You could also use something like ngrok but you can use CF Tunnels for free. I just setup projectname.mydomain.com or projectname.local.mydomain.com and I have that use a CF tunnel to my local dev environment.

ravenstine 4y ago

> Github "left our macOS model behind and moved to Codespaces for the majority of GitHub.com development". Yikes. I wasn't planning on working at GitHub, but I definitely wouldn't if that quote is genuine. Imagine actually being forced to use VS Code to do your work. I love VS Code, but it seems wrong to center the team's workflow around it. I guess you're screwed if you want to use Vim or Sublime? "Oh, but there's plugins for that!", I can hear someone say. Yeah, f--- that sh--. And after all, who's to say that GitHub Codespaces won't someday drop VS Code when it's no longer in vogue? GitHub Classroom touted its Repl.it integration and then deprecated it almost immediately without an equivalent alternative (just use VS Code bruh), so it's not that farfetched.

danielvaughn 4y ago
I agree that being literally forced to use Codespaces is kind of shitty. On the other hand, establishing code consistency is important, and it all depends on your editor's linter/prettier. They have to produce the same output, and even managing that within the same editor is difficult because you might have different versions on each dev machine, or different user settings. Doing so across editors is even more difficult.
- thebean11 4y ago
  Prettier / linter can just be run in a git hook and verified in a GitHub action / CD step though. Prettier config should be committed to the repo itself, then let devs decide how they want to apply it to their workflow (and prevent them from merging otherwise).
- gscho 4y ago
  There's also the benefit of "dog fooding" their own product that they're selling to customers.
thebean11 4y ago
The "run the whole dev environment in the cloud" part actually sounds pretty nice. 10 seconds to have everything running?? And I assume you can switch between multiple environments you have saved, tied to branches? That's pretty sweet and opens up tons of opportunity for server side build caching to speed things up (don't need to compile the packages you aren't modifying). Is VS Code actually required, or is there some way you can edit source code locally then push to codespaces to actually run it?

twblalock 4y ago

There are a lot of weak overextended arguments in this piece which reduce its credibility and persuasiveness. One example: just don't code on airplanes. Or how about this one: > To argue against localhost eventually going the way of the Dodo is to do the developer equivalent of asserting that most people want to run their own generators or grow their own food. Come on. That's not a serious attempt to persuade. It's practically a rant.

deleted 4y ago
[deleted]
yjftsjthsd-h 4y ago
> asserting that most people want to run their own generators Also, lots of people specifically have generators to cover when the grid fails them. Like, I'm actually okay with the claim, because that's an argument in favor of local development.
- doctor_eval 4y ago
  Yeah - my new house is about to get covered in solar panels, and I can’t wait!

api 4y ago

Also no privacy at all, ever. Every single keystroke is watched. Everything you run is profiled. All your data is logged, scanned, probably stored forever, and probably data mined. It'll start at work of course but eventually the whole ecosystem will shift and it will no longer be possible to develop software without the cloud watching every single thing you do. Someone doesn't like what you're building? It will suddenly vanish and take all your work with it. Price goes up? Tough. Pay the rent or all your work vaporizes. This whole trend is deeply, distressingly dystopian. It's a total inversion and reputation of the whole concept of personal computing and everything associated with it, a return to the mainframe era but worse because big data and AI make mass surveillance and automatic control so easy. It's equally distressing that most developers don't even understand the trend enough to push back on it. They don't grasp the fact that the difficulty of local system administration and the general over-complication of everything is driving this, so they don't address any of those problems. In fact they keep making them worse. Development environments keep getting more and more complicated and fragile, making a move to a shared centrally managed cloud environment more and more tempting.

margarina72 4y ago
This. I was wondering if anyone was going to mention it. All dev in the cloud is the dream for a full monitoring solutions. Finally able to bust the lazy and unproductive folks...
- api 4y ago
  Even worse, I foresee a future where there are bots in the cloud that interrupt the development or execution of software that violates the ToS. I think these may already exist, though usually for very specific things like cryptocurrency mining. I could see this broadening. I could also see the government getting involved then and mandating it. "We're sorry, our system detected that you are developing end-to-end encryption software without the proper safeguards in place. Your account has been locked..."

longrod 4y ago

> Fast gigabit internet is cheap and everywhere (5G or mesh wifi) Right. Most of the world doesn't even have 5G yet. Besides no matter how fast you get with internet, its still internet. There is still latency which makes for a frustrating UX. I wouldn't want to be fully cloud based even if I had free internet for life. That's a recipe for disaster. The best thing about local stuff is...that it's local. I don't need an internet to access it. That's extremely convenient. But putting that aside there's still cost of running things live (outside the internet cost). And why would I want to pay extra for something I can easily run on my machine locally? Live is for production code that multiple people will access. Local is good enough for me. I would even prefer to self host most of the stuff locally on a Raspberry Pi or something instead of a cloud hosting. It's just so reliable.

sigmonsays 4y ago
to further this along, often i code without internet and just have VMs on my laptop. I think assuming internet is everywhere for development is wrong.
- Lev1a 4y ago
  I'd go so far as to say that "Internet will always be available" is the new generation of "Works on my dev machine, thus it should work everywhere", which was a (common?) assumption over the last few decades.
  - satyrnein 4y ago
    Aren't people moving to cloud dev environments to solve the issue of "it works on my machine (using emulators, etc)"?
    - Lev1a 4y ago
      Sure, but by doing that they move under the above mentioned assumption that (fast) internet is always available to all the users, devs, etc. AFAIK the last big push to get out of "it works on my machine" was the JVM which has become a bloated, inefficient mess that a vast chunk of the industry uses anyway, because most often it's deemed "good enough" and Java, Kotlin etc. devs are relatively easy to find and/or train compared to "native" development in say C/C++, Rust, etc.

ary 4y ago

This is a ham-fisted attempt to get attention using controversy, and the arguments are so weak they can't even make me mad. Computing of any kind (including software development) moves around all the time. Sometimes it's more economical to do something with a bunch of servers over the internet, but less privacy preserving. Then user devices become more capable and it's suddenly possible to do everything you need on device and the platform(s) you're targeting all have enough lowest-common-denominator support to make it feasible. On, and on, and on. This "article" boils down to a myopic view of the industry that is almost solely supported by the solutions very large development teams have had to come up with to handle their human scaling issues.

bbertelsen 4y ago
Agree, 100%. I was about to comment that this must be a jest - but aiming for controversy is surely the more accurate interpretation.
- daveloyall 4y ago
  Alternative interpretation: the author is having a stroke. See how they miscategorized the "soul-stifling metaverse" tweet as "extremely positive". ...That's not what the tweet is saying... :)
dogleash 4y ago
Arguing this point is all downstream from the fact software complexity has turned our general purpose machines away from general purpose use. Going with the path of least resistance is fine, often a commendable decision. Water flowing over rock can carve a canyon. But arguing that the canyon shape is where the river ought to be? Not for me.
dx034 4y ago
Absolutely, and there's never one true solution. Over the past decade, I've moved multiple times from working remotely (thin client) to locally and back again. It's only problematic if people think everyone now has to follow one model. As long as you accept that some work profiles/companies/industries work better with remote or local, we can all profit from increased choice. I believe local development will never go away, as well as thin clients will never go away. You just need to find what works best for your situation.

juancn 4y ago

Lightspeed is still an issue. I've done remote development and it sucks. Even with gigabit connections, ~150ms latency can kill you. Maybe you can keep the editor local, and have it hide the latency for you, but debugging? With anything over a few ms latency remote debugging is impossible (or at least extremely annoying). Step over? Wait a few seconds to a minute until the debugger issues one call to get each variable in scope and all the other goodies. Debuggers assume local environments, we would need new tooling that's latency aware to handle this, in every major language and platform. I don't see this being good enough for serious dev work in a long time. It will work for some niches though, specially if you're close enough to the datacenter hosting your infrastructure. In a sense, a local git repo with an IDE, and a cloud unit/integration testing pipeline is as close as we get now, but every once in a while, you need to run at least a little bit locally to be productive.

zaptrem 4y ago
Even with a crappy DSL connection I haven't routinely seen >70ms latency for years. Modern cable/fiber/LTE/NR connections are all well under 50ms. Even then, we have realtime games with lag compensation that make that connection instant. Your problem sounds like a badly written app, not a tech limitation.
- sophacles 4y ago
  What definition of latency are you using here?
- falcolas 4y ago
  > connections are all well under 50ms This depends entirely upon where you're connecting to, and from. For example, I can't connect to us-east-1 servers with under 50ms of latency, because I'm out in the rural west, and my connections run a thousand miles south before getting on a good east/west backbone. Spikes are not uncommon. > we have realtime games with lag compensation that make that connection instant When the prediction algorithms are correct. When they're not, you start seeing some uncanny behavior that you can't predict or compensate for (dead-on shots missing, actions being rolled back, etc).

barnabee 4y ago

Let’s not do this. It is a gross vision for the future. I hate the cloud. IMO we should be working towards self hosting appliances, federated and otherwise decentralised services, and local-first applications.

amelius 4y ago
The future looks cloudy.

no-s 4y ago

Futurists extend trends, but innovation defies trends. So this article is about futurism, not innovation. I would believe the blurring of cloud, edge, and localhost more than this. I think it’s reasonable to believe network splits (physical or political or economic) will always be with us and thus the need to support disconnected computing will continue...Serverless/FunctionsAsAService could work this way. So? Maybe provisioning to an edge is a reasonable thing. The article mentions edge workers; the edge worker can be at localhost. The provisioning system can incorporate localhost. But yeah, localhost becomes livestock instead of pets...local computing power will still be a thing. Anything that needs ultra-low-latency or disconnection tolerance will be reified to task, like smartphones or smart munitions, or developer tools, or spaceship computers...not really too different from what we have now.

ramesh31 4y ago

Localhost will always be free, and the cloud will always have a cost. For that reason alone, localhost isn't going anywhere.

kaetemi 4y ago
Yep. Most of the people I know don't want to pay subscription fees for cloud services, when their own desktops are powerful enough to run what they're working on. Just automate localhost development environment deployment.
ozim 4y ago
I think article is arguing that localhost still has cost when onboarding and maintenance cost that is not really that visible because maintenance happen while devs are doing other task - but usually it is included in some task to setup some config. So I would agree localhost can be basically free, only that company has to keep developers in-house and not burn through 10 juniors each quarter. If company wants to burn through people like Amazon in warehouses then having cloud dev-env is way to go.
mnd999 4y ago
Which is why it appeals to GitHub / Microsoft. Now you have to pay them for something you used to do for free.
satyrnein 4y ago
Localhost isn't free, we buy more expensive laptops for developers than any other teams.

rglover 4y ago

No. This is the absolute wrong direction. In effect, you're giving a third-party absolute control over your code and your ability to work on it. You're also disconnecting the developer's mental model of how all of this stuff works (arguably why there's so much bad code floating around). Eventually, that will devolve to people not knowing how any of this works and the industry will collapse. It's an abstract line of argumentation related to this, but Jonathan Blow nailed it on this idea a few years back: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk

smoochy 4y ago
I was reading your comment and thought of Jonathan Blow's talk. Without even clicking the link, let me guess, that's from Moscow's 2019 conference? EDIT: yes, it is. He has a very important point there. I recently went on Twitch to see what young devs where coding. One (rather smart, I must say) young lady was creating a simple sign in/sign up page, but there's a twist: with React. Upon me asking, why wouldn't she just code it in plain HTML, she responded with a question: "but how would it connect to the API?". So there you go, ladies and gentlemen. I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old.
- rglover 4y ago
  Yup
- rglover 4y ago
  > I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old. I'm working on it: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick. The tl;dr is that I'm offering a full-stack framework that takes advantage of vanilla JavaScript and HTML in a front-end framework combined with a plain ol' HTTP back-end using Node.js. The APIs abstract just enough to make you productive but not so much that you can't reason about how it'd work without the framework. The long shot of the project being to keep the mental model of "how the web works" intact while reducing the burden of doing everything from scratch.

trasz 4y ago

I'd argue the exact opposite: with each year the cloud makes less and less technical sense. Local computing power, storage, and networking are getting cheaper all the time, while cloud services really aren't, and won't because of their business model. Cloud is also risky for security, privacy, and business (hard dependency on a single vendor) reasons.

jrochkind1 4y ago

As a developer who works in very small teams/orgs, though: Will you need a "devops" team of 10+ just to create and keep the cloud-hosted development environment working? Cause that's why I currently prefer avoiding even docker for my dev env.

habitue 4y ago
This is what companies like Gitpod do, they are the devops team, and you just manage the dockerfile that determines what the dev environment looks like.
satyrnein 4y ago
In the ideal case, you stamp them out using basically the same docker/terraform/etc you use for managing production.

ranger207 4y ago

I am currently (literally waiting on a EC2 Image Builder pipeline to complete as I write this) rewriting our dev VM to work on EC2 rather than VirtualBox on our MacBooks. I'm doing this for two big reasons: One, the VM won't run well on future Macs. We're using Intel MacBooks on Big Sur because there's a bad interaction between Monterey and the VirtualBox kext that I can't figure out; and because making our VMs work across Intel and ARM would require a rewrite. Second, and more importantly, debugging why the VM isn't working on someone's laptop is a massive pain. My goal in moving the VM to the cloud is to reduce the surface of things that I have to troubleshoot. If ssh works on your laptop then (the hope is) I don't need to mess with your laptop any more. If the VM breaks, then when I fix it it'll be fixed for everyone at once. Believe me, that's not the case with the local dev VM despite the entire thing being scripts in a git repo. I'm trying my best to keep the new dev experience as painless as possible, but at the same time, moving the VM to work in a consistent and stable environment also improves the dev experience along with my operational experience. It'd be fantastic if we could run everything locally and nothing ever broke and everything that worked on my machine worked on prod too, but that's simply not the case

habitue 4y ago

dev/prod divergence isn't the reason to do dev in the cloud. The reason you do dev in the cloud is dev/other-dev divergence. I'm a big fan of doing dev in the cloud (at least for work, no way I'm doing that for personal projects). Currently we use Gitpod, it works pretty well. Spinning up new people is easy, and so is keeping everyone's environment up to date with each other. But even in the bright shiny future of 2030 the dev environment is always going to differ from the production environment because... developers need a bunch of stuff in their image that you don't want installed in production.

prmoustache 4y ago

Sounds like almost a week of additionnal days off from both cloud vendor and local power outages. :)

LinuxBender 4y ago

All the Cloud's A Staging Env, and All the Laptops Merely Clients This fantasy has been pushed since at least 1996 but that really died off when mainframes were no longer the only option. Sure, my old Wyse terminal fits the bill but I have not powered that thing on since ... actually I don't remember where I left it. Cloud providers will always be a thing and local software daemons will always be a thing. There is a time and purpose for both. Anyway, I tried to convince some development teams to go this route some time ago and use Chromebooks with Citrix farms so that their work remains in a safe location. That idea died faster than I came up with it. There were entire teams that would have outright quit had I forced the issue. We did use that concept for some sensitive customer data debugging but never for development or staging. General purpose computation on your own machine is probably going to be illegal in 20 years... Some companies would love for us to believe that. Maybe some day politicians will be lobbied into making some services cloud-only. Unless their business model already fits being cloud-only I would expect such legislation to bankrupt some businesses or hurt them enough that the SEC or someone else that cares about tax revenue intervenes. Microsoft has been trying to move Windows in this direction, to require an internet connection and connectivity to their cloud and accounts on their public AD servers. The latest IBM/Redhat Fedora Beta hints at moving in this direction as well. I do not participate in such things but that is my personal preference.

nerdponx 4y ago
The Wyse keyboards with Cherry mechanical switches are sometimes worth something. The keycaps are super cool too.

chazeon 4y ago

As a computational physics student, I am recently moving to fully embrace the model describing in the article. I work on multiple HPCs, and now I use a machine (m720q) as proxy that SSH onto HPCs and run code-server there. From my laptop, I just visit the website on this m720q machine, and everything is done via a browser. Besides code-server, I also run a JupyterLab instance on the machine because we are not allowed to run jupyter on HPC's login nodes. All scripting / terminal is now done through the code-server (similar to GitHub Codespace). Tailscale allows me to access this proxy server outside home. On embracing this this model avoids moving large files GB+ from remote to local machines via SFTP, and I can avoid typing SSH commands every time I go from home to school. Code-server allows me to run more things on HPCs instead of local machines. Previously I used VSCode Remote, the latency might interrupt the connection, and now with code-server this is no longer a problem.

throwaway787544 4y ago

I've noticed that if developers can't run their code in some hand-crafted one-off buggy inconsistent mutable local environment, they freak. To the point that they're fine with using some proxy to a remote K8s cluster as long as their application code is executing locally. My guess is they fear a lack of control, and a local environment makes them feel safer, like they aren't stumbling in the dark trying to figure out how to make an app work. Most developers don't really understand the cloud at all, and that lack of understanding combined with their local env baggage is half the reason DevOps people are necessary. If devs adopted cloud native workflows, a lot of shit would be easier for everyone. It would even lead to better designs. Devs think the cloud works like their desktop, when really it's a radically different model for system design. I mean, there still devs who assume their app will use a filesystem to store data, lol!

majewsky 4y ago
Poe's Law applies: I'm honestly not sure if you're being sincere or engaging in deliberate parody.
ClumsyPilot 4y ago
> Most developers don't really understand the cloud at all Most developers don't understand how their own computer works.
nerdponx 4y ago
I just want to be able to test my code. I've seen software projects go fully into cloud-hosted microservices, without even a consideration of testing. It sucked.

gatvol 4y ago

Bad idea. This leads to vendor lock-in, propietary systems.

muskmusk 4y ago

Yes and no. If everything needs 5 databases, 4 queues, 3 caches and all of this is written in 7 different languages, then yeah I guess cloud is the way to go. If you just shove shit into postgres and pull it out again using something like postgraphile then I don't think cloud does much for you. The Flipside of the "computers gets faster and faster"-argument is that more and more can be done on one machine. Compute supply is growing faster than demand. Today's apps are not that much more complex than the apps of 10 years ago, but computers are much faster. Human beings read and type at the same speed today than 10 years ago so I don't really see this changing massively. Obviously all the BigCos listed can't run on one machine, but a very large percentage of stuff can.

mike_hearn 4y ago
Agree. A lot of the movement to try and develop everything inside Linux containers is driven by a few factors, none of which are particularly fundamental and which may see a reversal for unrelated reasons in future: 1. The insistence on doing UI exclusively via web browsers. They aren't particularly well suited to it and at some point competition for them may arise. 2. The insistence on using complicated proprietary cloud services to allow scalability, without actually doing any scalability calculations to justify it. A modern dedicated server is a staggering piece of kit. NVMe SSDs are game changers. You can scale a bog standard ordinary RDBMS setup to very large amounts of load without needing any special cloud databases at all, and it'll be easier to program. People don't realize this because they tend to think about scaling in binary terms: "it scales infinitely"/"it doesn't scale and that's bad". That sort of mental shortcut can be OK when money is free, but, well, we're entering a period where it may not be. The sort of engineers who can actually do load tests and figure out plausible maximum QPS for their load can pay for themselves quickly. 3. The fact that the only competition for Linux on the server side is cloud APIs and services, and Linux badly needs the competition. 4. The popularity of toolchains/languages with extremely weak portability layers and convoluted packaging systems. Java nailed this. Python, Ruby, Go ... not so much. This inevitably pushes people who use those tools towards using their local OS as a glorified terminal window manager for dialing in to Linux VMs because nothing works right if they try to use Windows or macOS directly. If your app genuinely needs something only AWS can provide then yes, you have to develop in the cloud and not against a local implementation. But that's a bug not a feature, and if you're in that boat then you're exposed to all sorts of problems beyond needing to develop against production (e.g. opacity of failures, unexpected cost explosions). If you can run the bulk of your app on a JVM with a Postgres connection then that's a competitive advantage - your devs can use the environments they're most comfortable with, you've got full insight into the whole stack if anything goes wrong, outages can't shut down the whole development team and you're not racking up cloud charges for development purposes.

ur-whale 4y ago

> General purpose computation on your own machine is probably going to be illegal in 20 years... This - to me - is the worst part of the article, because as much as I loathe the idea, I fear this may be correct. I am very afraid that, at the very least, you'll likely need some sort of carry permit to be allowed to write code on a machine connected to the net and where everything the machine does is connected to that permit and your identity.

ur-whale 4y ago

The solution to many of the problem outlined in the article is not to move your work env. to the cloud (which has a boatload of problems in itself) but rather to be able to transparently install a perfect localhost copy of the environment the software you're building will run in, via - whatever - containers, vm's , etc...

viraptor 4y ago
That's my understanding too. The article mentions: > most of these items enable (even require) you to run things "live" on the cloud, not localhost But they really don't. If having them in the cloud helps you, you can replicate the experience by running that service locally.

rad_gruchalski 4y ago

I recently develop on cluster.local and I’m happy enough :) Regarding the article: what if the „cloud company” decides to suspend your account for „reasons”?

WesolyKubeczek 4y ago

Because the world is made of bandwidth and large cities and each ISP will gladly sell you a multigigabit pipe for peanuts, and there’s 6G wireless with absolutely no outages whatsoever. Also everyone just works at FAANG or is not worth talking to. I have this weird idea of selling a globe where the only land is Bay Area. For $9,999.99 apiece. It’s being reinforced by articles like this one.

bhewes 4y ago

Haha, people who never have worked with an IBM mainframe think all this is new. Shallow IT thinking.

dzonga 4y ago

you see people / companies advocating for the cloud thing have huge interests in you/me - joe average developer to using cloud tools. BigCo's development workflow is cloud based because they own the IP. IP - being the most important word. looking at world around me, IP is what makes things tick. IP is why America industrialized, IP is why American's are spooked by the Chinese. And if a average joe like me - moves to the cloud things - where i'm using a dumb terminal n hell the browser is being streamed to me. What IP would I own. I would simply be a renter. now me your average developer since realizing IP is the most important thing - I have resolved to go the opposite route. use text files for my notes / writings. create things locally and back them locally as well. SSD's and CD's are cheap. Desktop machines are cheap - an Alder Lake i5 is as fast. and even better maybe instead of making software for the browser making local software with C++ to make sure it's portable and runs fast who's data is stored in a text file.

jacquesm 4y ago
That, and cloud usage means they control you, the tools you use, when you can use them, from where you can use them and that's before we get into telemetry and so on.

Klonoar 4y ago

I think the author's got a kernel of an idea and does an absolutely horrible job outlining it, considering few here seem to be catching on. Localhost will likely never die for certain sectors of programming. There's a significant chunk of stuff that doesn't need to be custom localhost setups, though - and ultimately it can smooth out the differences between dev/production in teams where this is a stumbling block. You don't need localhost to be some server somewhere that kills your ability to work with an outage - stuff like StackBlitz (https://stackblitz.com https://stackblitz.com) effectively uses WebAssembly to run e.g Node directly in the browser sandbox. This model is the first one that makes me think it's possible. You no longer have that dangling issue of "which of my NPM packages is going to try and steal from me" since it's walled off in a sandboxed environment that spins up faster than you can blink. The caveat to all of this is that we should fundamentally never let localhost die, as ceding total control to services to build on is a pretty bleak future. There's a good middle ground to find here though. A final aside: an article telling me I'm wrong for wanting to code while flying is a junk take.

teeray 4y ago

Cloud development machines are great—-secure, consistent, etc.—-right up until you have a cloud outage and your entire team’s productivity goes to zero. That’s “zero productivity” as in an elementary school snow day. Even when Github has gone down for hours, I’ve still managed to do code reviews with good old-fashioned `git format-patch` in chat.

hexo 4y ago

Another thing designed to take my money. Nothing else. Won't use :)

prima-facie 4y ago

Yeah, no. I've seriously considered moving back to Sublime Text because VSCode has become annoyingly slow for me (like waiting for text to appear). And also the Python extension auto-complete only works some of the times lately. Now imagine further bogging it down by running it in the cloud.

whoomp12342 4y ago

you know what I love about working against localhost? its LOCAL. its mine. I know its mine and no one can see it until I push my code. I have ideas. Good ideas, bad ideas, and WHAT THE FLIPPING HELL WAS ThAT idea. In the wrong hands any of those half baked ideas can not be good

jacquesm 4y ago

That's really pretty dumb. I run plenty of stuff on my local machine that has nothing to do with development, it simply runs there because I only want it to run on my local machine. So localhost is my production environment. The idea that some bozo somewhere will decide what I can do with my local machine just because they don't have a usecase for it is really meddlesome. Go and disable localhost on your own box. Leave mine alone. And that goes for the endless number of usecases that haven't been tallied yet.

spc476 4y ago
You haven't been assigned a corporate managed laptop yet, have you? You don't have administrative rights, and it doesn't come with any development tools (because that's dangerous), but it does come pre-installed with all the Microsoft Office Tools that spend all the their time looking for updates.
- jacquesm 4y ago
  If they don't outright blather every keystroke you type to the mothership.

ClumsyPilot 4y ago

> Fast gigabit internet is cheap and everywhere Check your privilidge! Generally our industry is phemomenally irresponsible, there will be some life-critical service that gets built with this attitude, and no-one will realise untill some shit hits the fan - whether it's a power cut or an internet cable being cut but a digger or the AWS datacenter burning down - and then people will die.

jacquesm 4y ago
I think we're already there. A hospital that loses it's internet connection would have a hard time functioning and depending on the length of the outage it may very well cause people to die. Between scheduling, medication conflicts, diagnostic tools, EPD exchange, cloud connected medical gear and so on this is no longer a theoretical thing.
scottlamb 4y ago
> > Fast gigabit internet is cheap and everywhere > Check your privilidge! Umm, what? This is part of "the ultimate developer experience wishlist for the average rich-country developer in 2030", not a statement expected to be universally true in 2022. I think it's wildly overoptimistic, but "check your privilege" doesn't seem like an appropriate response to optimism. > Generally our industry is phemomenally irresponsible, there will be some life-critical service that gets built with this attitude, and no-one will realise untill some shit hits the fan - whether it's a power cut or an internet cable being cut but a digger or the AWS datacenter burning down - and then people will die. The "average rich-country developer" doesn't build life-critical services. If someone extends the author's techniques to a domain where they're inappropriate, that's on them.
- ClumsyPilot 4y ago
  > Umm, what? This is part of "the ultimate developer experience wishlist for the average rich-country developer in 2030", There is a newbuild going up near me where the best connection speed is ADSL. I am willing to bet my house some parts of the country won't have reliable 100mb/s by 2040.

doctor_eval 4y ago

“Treat your engineering team like cattle, not pets”

wyager 4y ago

> Fast gigabit internet is cheap and everywhere (5G or mesh wifi) I don't need to read farther than this; I am 98% certain that the rest of the article is hopium nonsense. "Mesh wifi" has never been and never will be the solution for any large-scale networking cost/performance issue.

marginalia_nu 4y ago

Ugh, I know right. You're tired of owning your house :-( That's what people did in the past. Eww. Leave the past behind! The past is bad! Instead, live in the cloud! Sign this easy form and transfer the property rights to me, and for a monthly bill, you will be entitled to visit the building. Need to use more than one room, need to turn on the lights or use the stove? No worry, you will be billed separately for abnormal usage.

namaria 4y ago
Oh and we deprecated toilets. Too much maintenance work.
- marginalia_nu 4y ago
  Imagine having bodily functions! Horses have bodily functions! Get out of here, grandpa!

nathias 4y ago

are mainframes popular again?

borland 4y ago

This is a terrible idea. Understanding what's "underneath you" in the stack is a critical ability when things get complicated. In my experience, running the stack on your local machine as a developer gives you a huge boost in understanding the stack, being able to profile, inspect, and reconfigure it as needed. Sure, it's quick, convenient and easy if your dev stack is also the cloud stack, because you save time not trying to figure out why localhost mismatches the cloud. BUT, when things get messy, having that understanding of HOW EXACTLY your localhost mismatches the cloud gives you a great depth of knowledge, which you can then use for great benefit in the cloud. Also: remote debug tooling is crap.

Existenceblinks 4y ago

Could be done with Erlang hot code reload with pull request in between.

eatonphil 4y ago

I don't agree with this idea at all, at least not about using high-level cloud services as your development portal. But I do do almost all of my development in a server in Canada (I'm in NYC, though latency while traveling in Korea right now is worse). I control the server though.

aenis 4y ago

This is ignoring the speed of light cap. Its not going to be possible to keep all those increasingly complex, distributed systems in sync with low latency. Its not going to be possible to instantly run a series of tests that depend on each other if they run somewhere 10ms away. Not to mention all of this is energy inefficient. I am all for productity gains but this is just nonsense.

brobdingnagians 4y ago

You can make development more complex to match production and then layer more and more complexity on to to make it convenient (and brittle) or you could simplify production so that it is straightforward, replicable, and bulletproof. I know which one I prefer. It would be better to simplify and streamline the system than to layer abstraction upon abstraction is a bizarrely escalating tower that needs more complex "fixes" to counter the complexity, which increases complexity for the next round.

quest88 4y ago

Not one mention of cost. Money just goes on trees!

nunez 4y ago

Lol. Yes, let's tow our hitches to the most unreliable and expensive component in our stack and call that progress. An app in 2030 (or, hell, 2022) should be reflexive. If it works in production, it should work on your machine, without any code changes, and vice versa. Therefore, devs should _absolutely_ be able to iterate locally with this guarantee (enforced by CI). I do agree that the ability to quickly create an ephemeral, scaled-down version of the app's production environment in $CLOUD is important, particularly for integration testing. But using that for full-time dev isn't a good idea IMO. Slightly unrelated, this: > But I Need To Code on a Plane? > Maybe stop flying so much. Or get a good audiobook and rest your eyes. Maybe even talk to your neighbor! (if they seem social) is where I stopped reading. Absolutely appalling lack of empathy. I normally fly for work. The flight is the time I use to get shit done that I can't during the week. I hate small talk. So I'll continue coding on the flight, thanks.

GekkePrutser 4y ago

> "General purpose computation on your own machine is probably going to be illegal in 20 years" Yeah this is exactly my worry with these things. I don't mind the cloud being a thing. But I don't want to be forced to use it. Especially in my private life - work can decide what tools we should use there, that's their prerogative. Though I personally think it won't come that far but that the real barrier will be that we just won't be able to but decent PCs anymore because everyone will be using what amounts to thin clients (think Chromebook etc)

andrewprock 4y ago

And so the cycle repeats. Thin client, fat client, thin client, fat client, ...

vlovich123 4y ago

It’s not one or the other. It should be trivial to deploy to prod without complex configuration (modern edge compute platforms seem to do a good job of this). However, local testing should definitely still be a thing. You may have gigabit but you’re still potentially traversing the world - latency is going to lengthen the duration of your test suite. Plus when deployed you’re dealing with flakiness that’s totally outside your control (external internet connectivity of CI tends to be flakier than local connections). In terms of equity, I have not seen gigabit fiber be widely available. Nominally I have gigabit cable in San Francisco although real world performance is much wider variance than one might hope. And some junior members at the start of their career may be choosing to be as economical as possible (eg using just a cellular hotspot through their phone for all their connectivity needs). Heck, at the office I get maybe 50 mbit/s out of the wifi with no wired option (and that’s not talking about the quality of the wifi). It’s a nice idea and may work on small teams. For anything moderately complex, you’ll want local AND cloud, not OR. Also make sure to design for both from the get go. Source: I’ve seen the gamut of what works and keeps testing infra humming smoothly along for dev teams of all sizes/maturity. Everyone learns the lesson of being able to run tests locally at some point. Remote development on cloud servers can work and is an orthogonal thing. But if possible don’t use cloud services if possible (ie use local simulators/emulators if possible and they do a decent enough job).

xedrac 4y ago

And here I struggle with the latency of local programs built on Electron. I can't imagine developing in the cloud all the time. Maybe the next generation of developers can go down that path and eventually rediscover the wonders of localhost.

jhoelzel 4y ago

I strongly disagree and in my opinion the future approach should be dev containers. They run on macs just the same as windows and if you habe a potato for a work machine you might as well develop in the cloud. Localhost will not go away. Especially with containers and machines that have more than 16 cores it just does not make sense to deploy to the cloud. In the least least energy wise, its horrible. I have been taking this approach with a lot of clients over the years and the ability to just delete a container of my machine and be compliant with my nda when the project ends is a godsent. Also I would like to point out how well desktop cluster like rancher desktop actually bring k8s into your home effectively.

ramoz 4y ago

Lol.

ar-nazeh 4y ago

He meant positive as in "believe it will happen", not positive as in supportive. And in that sense, it was extremely "positive" (general purpose computing being outlawed after it becomes so fringe only a minority with little political power still wants it for personal use)

anothernewdude 4y ago

I worked on a project that gave up on local development because of reliance on some cloud database. Frankly sharing a DEV environment between three developers is something I'll never do again. Slowest development iterations I've ever seen. Waiting minutes for tests, builds and then deploys, only to find a trivial issue that localhost would have found in seconds. Now I'm on a project with serverless components, and it's all runnable locally. With containers there's no excuse for being unable to run on localhost. It may take time for this to play out across companies, but the ones adopting this way of working are going to lose.

namaria 4y ago

Is the argument here really "let's all go back to using dumb terminals and make The Cloud a remote mainframe"? How is this a net gain for individuals? We have these magnificent 16 core, 32 gb local environments and we should give up control because hype? Right

junon 4y ago

Hard, hard disagree with just about everything in this article.

ohCh6zos 4y ago

The cloud, the whole thing, was a mistake. I host everything locally, because AWS makes every action needlessly complex.