The End of Localhost
dx.tips
dx.tips
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
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.
Seriously, it's okay that people don't know the ins and outs of every little detail. Abstractions are useful, until they're not. And then when they're not, you go figure out the level below.
Even the most advanced, most skilled front-end devs spend 99.99% of their time not caring that the browser loads an HTML page.
If I may, a truly similar experience regarding keyboards would be this:
I had a similar experience with a coworker. When I asked him how the code that he types appears on the IDE on his screen and not on that of any of our colleagues' screens, all I got was confused looks. When I showed him that his keyboard is wirelessly connected only to his computer, which runs the IDE, and his computer is then specifically connected to his own monitor via a cable, his mind was blown.
Sometimes it becomes necessary to know how the level below works. That doesn’t mean it’s a requirement to be affective at the level above.
Not necessarily, but it did have a material effect in the original example. A web developer drug in a complex, unnecessary framework because she didn't realize that HTML forms have the ability to submit post and get data natively.
To me that's like a civil engineer building a suspension bridge over a tiny creek because they never heard of an arch design.
You're making a massive assumption that she didn't already need to use React and may have been confused at how she would make the two systems work together correctly.
So that's what's really troubled me. The companies responsible for producing this piece of garbage are actually getting into the heads of the younger generation, rendering them helpless without said garbage. I repeat, this is indeed garbage, especially React: in early 2000s we used to laugh at people mixing JavaScript and HTML, but some of them, apparently, decided it was their time to strike back.
The more important issue is, of course, that we have a generation of young people working with these "tools" which isolate them from learning things that actually matter. These levels of abstraction DO NOT add any value. These are "cargo cults" of abstractions, which without their authors knowledge (because those who invented them weren't very smart anyway) serve the purpose of keeping potentially talented and intelligent people ignorant and average. This is probably good news for somebody out there, but certainly not for us as a society.
Man I think you're thinking wayyyyy to deep into stuff.
I would add that even good old, rock solid assembler isn't a straight entry point into controlling the CPU, but is now just an abstraction over µOPs. Abstractions surround us these days, and for each of us, we find differing levels of what's tolerable vs what should be known about the next layer below.
I'm personally (kinda) ok with not knowing too much about the sub-assembler processes that happen inside the literal black box called a CPU, but I know that for branch optimisation, it's important.
* Why does a key appear on the screen when I push a button on my keyboard: no
* How is an HTTPS connection created: generally no
* How is the JavaScript library deployed: 100% yes
You might be able to throw something together that works without understanding that it is a JavaScript library with a bootstrap HTML page but if no one on your team understand that you will eventually need to find someone that does to solve a problem.
I would think that people doing web development probably benefit from a working knowledge of DNS, TLS, and PKI. Without those, I would expect a lot of readily avoidable problems with HTTPS.
In general I advocate that software engineers should have a functional, if abstract, understanding of how computers work on various levels. They might not need a detailed understanding, but people often benefit in unexpected ways from understanding the systems they work with.
[1] Not like they literally don’t know but that their code has no interaction with it.
How can she not be curious, Angular is so wrong and magical, it blows the mind to understand how it builds all that magic. Maybe your sister in law is the kind of persons who laughs at magic tricks ? I d be raging mad myself, I prefer to avoid them or Ill just be obsessed until I understand them
So yes, maybe being able to implement a form tag in HTML is the mark of a senior dev.
The accessibility issue is, of course, a solid counter-argument to running too far with that line of reasoning, and is part of why I'd much rather we put 1/10 the effort we do to constantly re-implementing basic HTML features into unfucking HTML standardization so we can finally have elements good-enough that we don't need to pile JS on top to get what ought to be built-in functionality. But, that's a whole different skillset from programming, and requires far more organization than thousands of devs all independently, or in small teams, working on yet another NIH version of an image upload input. :-/
System programming also has its warts, but at least most of the time you don't feel like you're working against the machine.
Suddenly she needs to change stuff on both backend and frontend, and she might only be allowed to touch one of those ends.
[1]: https://m.signalvnoise.com/integrated-systems-for-integrated...
In this case though, I believe she isn't confused as to how to call the APIs, maybe not even as to how to handle the response with JS and update the DOM. I think the question sounded more like you're not allowed to use Javascript at all.
Thinking React is essential to make an API call is a bit scary, but a future where we just click a few buttons and connect to a hot reloading syncing dev env with all the dependencies and transpiles obfuscated, seem inevitable, and it will be so reliable that we forget or never even learn how it works under the hood.
I don't think that being "in the cloud" makes abstraction that much more pronounced. You can have manually configure dev VMs in the cloud or automatically configured dev VMs locally, the later will probably use more abstraction.
I'm working on it: 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.
It's an unpopular opinion, but I view TypeScript in the same light as I do the OPs assertion about cloud-only development. It's adding yet-another-layer that has some merits but often leads to overcomplicated messes that reduce productivity/add confusion.
I'd rather petition for some sort of structs/arg typing to be included in ECMAScript proper (in a similar fashion as to what happened with a lot of Jon Resig's jQuery DOM selection APIs making their way into ES6).
At least Android and iOS taking over the consumer computing world has given me job security until I retire!
The video is great too; I hadn’t seen that before, and it gives some examples of what happens when that generational transfer of knowledge is not carried out, not just within a discipline but also across a civilization.
"Brevity is for the weak." - Maciej Cegłowski
I am sure one can find good and efficient devs that know very little about the underlying system and are very capable of using the available abstractions and frameworks. I just happen to find the first group better.
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.
It can be a bit of a mind shift for urban people to internalise that the internet is not always there.
One example that gets me is that Google Maps broke the ability to save points on the map without internet. It had worked fine for years since it could easily be saved locally, but now the regression has been around for a year+ and they clearly don't care. If you live your life in a modern city it's no biggie, but it cripples some of the main functionality for everyone who lives or travels to areas with poor connectivity.
We need to fix those places. Not permanently anchor the rest of the world to a decade ago.
For one, it's extremely fragile. There's only so much redundency that can be built into this infrastructure and I'd rather not see society completely grind to a halt because internet got knocked out.
Secondly, I don't even want to be connected to high speed internet every second of my life. Some people in tech find this hard to believe, but there are benefits to unplugging at times that many people appreciate.
Lastly, I shudder to think what privacy would look like in this world. Not having any escape from surveillance would lead to a grim society.
Then don't. Disconnect your device. The rest of us shouldn't do without something because you don't like it.
I'm in a team developing software for people in areas with rubbish internet. It's a bit above my pay grade to fix infrastructure problems in foreign lands. It's probably more cost effective to let the software deal with it gracefully.
And in my case.. the infrastructure was fine, but a sheep literally chewed through it. Do we ban sheep? Granted he should have been better fence... but the point is shit happens and help out in the country can take weeks to materialize.
But you guys agree anyway: but handling "gracefully" slow speeds you dont anchor the fast and still provide to the slow. The keyword is gracefully.
And yes, we probably should be doing that. But in the meanwhile those places still exist, and will continue to exist for quite some time.
I was responding to a similar attitude. We can pretend caring about shit internet is important for software makers. Sometimes it is. Usually it isn't. Simply saying "it should be different" and then pretending that it is, is equally silly.
We are firmly in "wishing for a better world" territory. Others wish that other people cater to their shitty connections. I feel that that would anchor us to shitty connections, so I wish for fewer shitty connections.
It's all pipedreams anyway.
You don't need it until you do.
Mobile, while technically capable of this, does not fit the bill because their business model depends on locking people into long-term contracts or using it as a marketing platform (I've tried launching a startup that does away with all this, it's impossible).
Right now nobody will sell you a SIM with unlimited data (excluding Three because their "unlimited data" is so oversubscribed that it's unusable) or a large enough data cap no matter how much you are willing to pay. Your only option is to either sign up for a yearly contract (which involves wasting time with support if you ever need to make a change or need to increase your data cap) or use Pay & Go SIMs and top them up regularly which involves using an IVR and listening to minutes of upselling random bullshit - there's no API and the billing is intentionally complex (depositing money isn't enough - you have to use that balance to buy a "bundle" of data, and you can't stack these bundles meaning you need to do this every time it runs out).
You seem to be looking for a no-contract unlimited data plan? Isn’t that just PAYG?
Kind of - I did mention PAYG and why it's not ideal and that it feels like you're still fighting the provider. Topping it up is a nightmare and the billing system doesn't allow the scenario of "here's a few hundred bucks, give me internet consistently until this runs out". Instead, you have to fight with it every time your "bundle" expires and you can't stack them in advance even if you deposit enough cash on the account.
EE's biggest bundle on PAYG is 100GB for 30£ which is reasonable from a pricing point of view but unfortunately doesn't last long and forces you to top-up and reset the bundle via the IVR every time it runs out. I want to be able to put 300£ on the account and get 1TB of data in one go so it lasts a couple weeks before I need to top-up again (topping up relies on the IVR which means taking the SIM out of the 4G router and putting it in a phone then sitting though minutes of bullshit upselling).
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.
> Make the ultimate developer experience wishlist for the average rich-country developer in 2030
Previously when working with a company (small startup or large company) you'd have an office LAN and a few servers, or a corporate VPN which your office network was on, and Openstack, or other 'local' services available.
Now that a large number (the majority?) of devs are working remote, if you want local/internal services you need to get everyone's buggy VPN software configured correctly
If it can't run offline on my machine, I don't use it.
Another aspect is portability. If the only requirement is "some sort of linux box", it's easier to deploy code anywhere, and to share it with anyone.
It also encouraged me to develop websites that work well on bad connections. Small websites that load the important bits early, and that communicate async request states properly.
Cheapest gigabit I can find around here is $100+/month. Yeah, "cheap".
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.
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.
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.
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.
It is so ironic to see the pendulum swing back to how I used to code in UNIX environments 30 years ago, while being told it is impossible to have worked like that.
Not only that, using development VMs has been a constant for me since 2011, either via Citrix or RDP.
I do most development out of a baremetal hosted server in Canada. But I think the original article is talking more about using cloud services like cloud editors, cloud databases, rather than using a VM or server hosted by someone else where you have root access and run all your stuff (editor, databases, etc.) there.
Personally I have only had proper root access, when I am part of infrastructure team.
It also has the advantage that setting up a new developer account is relatively fast.
>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.
Feel like this is similar to how Dropbox started. In that, the reasons given for why it wouldn't work were based on how previous solutions sucked. So yeah, if your debugger takes a minute to work then it'd suck. But what if it didn't?
This may be the crux of the issue. I've been confused when proponents of the idea indicate the experience is fine or preferable to local use as if the latency wasn't there.
I don't think we can agree if one side thinks 100ms latency when _typing_ is ok. Meanwhile other people are giving some of the new terminals flac for having 40ms vs 10ms latency (https://danluu.com/term-latency/). I tend to agree with the second group more.
I do it once a week or so (for a very short time) and would rage quit any job requiring this every day.
This is is also a web app, but it's slow. You have to click in a field, watch as the selection menus are filled in in a second or two (as the gigabytes of Javascript pulls data in via a database query in real time), and if it's a text field, you have to click in it, type real slowly, and click out of it. Don't tab to the next field because the tab key doesn't work as expected. What used to take a few seconds to fill out a days' worth of time now takes a few minutes. The C-suite, who bought into this crap, don't have to use it because that's what secretaries^Wassistants are for.
If this is the future of computing, I want off at the next stop.
Our team owns it but management will never sign off on resources to fix it. None of the technical staff or upper management at the company uses the support portal so they don't care. Support folks don't have any way of offering feedback to us or our management in a way that threatens our careers. The result is that it never gets worked on and support continues complaining without anything ever happening. I spent my free time coming up with fixes but ran out of time to tie up loose ends. I'll be tasking an intern with doing that, so the support people can finally use the portal and not want to rip their hair out. This is what happens when you aren't forced to use a system and customer feedback has no effect on you, as is the case for most enterprise software.
Have you tried to use Puppeteer or Selenium to automate the timecard entry? That might help reduce the pain.
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).
I really wish people would set aside their "well it's always worked for me, surely it must work for everyone" attitude, because it is tragically and obnoxiously false.
If you're in San Francisco connecting to a server in London, it's a physical impossibility to get under ~60 ms, and that's assuming a direct signal going across the surface of the planet at the speed of light. In reality, it's not direct, and there will be at least a couple dozen routers between.
Explain that.
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.
All dev in the cloud is the dream for a full monitoring solutions.
Finally able to bust the lazy and unproductive folks...
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..."
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.
https://github.blog/2021-08-11-githubs-engineering-team-move... (and if you want to try it, I think it's "gh cs ssh" in the github cli)
Is VS Code actually required, or is there some way you can edit source code locally then push to codespaces to actually run it?
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.
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.
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.
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.
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.
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) 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.
IMO we should be working towards self hosting appliances, federated and otherwise decentralised services, and local-first applications.
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.
Wait, speed of light also improves exponentially?
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!
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?
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.
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.
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.
> 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.
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.
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.
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)
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.
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.
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.
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.
And so will other companies, since it's a definite productivity boon.
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.
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.
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.
Just automate localhost development environment deployment.
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.
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
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.
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.
> 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.
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.
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
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).
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.
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.
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.
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.
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.
Thin client, fat client, thin client, fat client, ...
Privileged much? What a high handed way to start an article.
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.
.
I just setup projectname.mydomain.com or projectname.local.mydomain.com and I have that use a CF tunnel to my local dev environment.
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
Cause that's why I currently prefer avoiding even docker for my dev env.
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!
Most developers don't understand how their own computer works.
Regarding the article: what if the „cloud company” decides to suspend your account for „reasons”?