> 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.
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.
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.
> 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.
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?
> 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.
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.
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?
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.
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.
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.
> 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.
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.
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).
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?
What about JetBrains IDEs though? What if I want to run some one-off script on my local terminal that's interacting with source code files? Emacs and vim plugins don't go far enough IMO, it needs to fully support the local filesystem.
They covered that in the original blog post, as a ton of their internal devs liked their current setup. They ended up writing a little command line utility that would let you SSH into your codespace (spinning it up if necessary), so you could use whatever editor you want (including JetBrains IDEs now that they have good SSH support).
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.
> 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.
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.
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..."
> 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.
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.
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.
It is extremely difficult to actually get good internet on short notice, at least in the UK.
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).
I think the move to WFH has accelerated this shift (a worthwhile tradeoff IMO)
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
Because they have enough staff to detect and fix vulnerabilities within hours, if necessary. For a company without these resources (and maybe even larger ones), hiding servers from the internet can greatly reduce your attack surface.
Not the OP, but I'm fairly certain that is the point: Fast gigabit internet cheap and everywhere won't happen by 2030. 5G isn't even everywhere yet, so making it fast and cheap everywhere happening by 2030 is highly unlikely.
I very much agree with this and did exactly the same thing not too long ago. I have a few small apps running on my Raspberry Pi. I converted it to run from a flash drive and it has been very, very solid for about a year now.
It's extremily frustrating how little thought many dev teams give to the idea that users won't always have super fast internet available. It really undercuts the grandiose corporate talk about inclusion and equity when users in rural and poor areas are effectively told to pound sand.
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.
I do think that cities should all have high quality internet available but the notion that every inch of the glode should have high speed internet, and software should be developed to that baseline, I totally disagree with.
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.
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.
> You cannot simply say "it should be different" and then pretend that reality is what you think it should be.
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.
I work on buses, trains and airplanes, in cafés, Biergarten, parks and hotels with bad wi-fi. There's no fast internet there. Even things loaded from a CDN brought my development speed to a crawl.
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.
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.
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... :)
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)
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.
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.
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.
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.
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).
Where you live, sure. But I can drive just a couple hours north of San Francisco and lose all cellular connectivity, entirely. In fact I am doing just that tonight and my friend and I have made contingency plans for meeting up at a festival going on in the mountains off the 101, where we expect to have no cell service.
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.
Latency is affected more by geographical location than your local internet connection.
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.
Debugging won't be a problem if the dev environment is on the cloud. 100ms latency works fine with Remote Desktop Protocol when typing. However, I don't agree with the article for other reasons.
It really doesn't work well. As in, people who touch type are slowed down if there's 100ms delay. Moving the cursor around is also awkward, because you're often pressing a key multiple times per second or rely on repeat rate which does the same.
I do it once a week or so (for a very short time) and would rage quit any job requiring this every day.
I have to fill in a "time card" each week. The old system was a simple web page that I could navigate primarily via keyboard, tabbing from field to field. I think it was a company-developed web app, so the people who made it also had to use it. Then that was scrapped for an "enterprise solution."
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.
At work we have a support portal, to help customer support folks out. It relies on queries through a legacy service to a legacy DB. Increased row counts in the DB (ish because this isn't SQL) have caused high query latency resulting in frequent timeouts, and the legacy service that manages the queries keeps constantly timing out.
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.
> 100ms latency works fine with Remote Desktop Protocol when typing.
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.
>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.
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?
I have done enough debugging using graphical debuggers on X Windows sessions.
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.
> 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.
Usually those machines are mostly managed by IT and anything related to configuration changes usually requires some form of IT change request, or using a cut down version of root, project specific.
Personally I have only had proper root access, when I am part of infrastructure team.
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.
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.
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.
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.
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.
> 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.
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.
Thanks. If I do, it won't be supported beyond the compiler/build tool (no official recommendation of using it w/ limited support).
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).
I think the best solution to this is to eliminate the division of labor between back-end and front-end, for the majority of applications that don't actually require deep specialization in either. As DHH put it, integrated systems for integrated programmers [1].
I think this is a question about becoming dependant on abstraction rather than where the abstraction is run.
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.
Considering how many web developers get that particular tag wrong I'm not sure that's actually as unreasonable as it first appears. The number of forms out there on the web that are really just used as a way to group collections of input elements, with no consideration for an action, a method, browser native validation rules, fieldsets, a legend, etc makes me wonder if people actually know HTML at all. Every React, Vue, etc form I look at the source for gathers up input into state and then submits it with a fetch, replicating, but also often breaking, the accessibility and functionality built into the browser.
So yes, maybe being able to implement a form tag in HTML is the mark of a senior dev.
I'm very much on the "this shit's too complicated, we should fix whatever's making us not use the standard features and tools instead of piling this garbage on top" train, but I think a valid defense of doing things in Javascript that could be done in HTML is that, as soon as you need to do any e.g. form validation in JS, it may be simpler to just do all of it there.
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. :-/
I see web development is still trying to make something fundamentally ill-suited for its task work by stacking shoddy layer after shoddy layer on top of it, just like it did when I left web development 10 years ago and went back to system programming.
System programming also has its warts, but at least most of the time you don't feel like you're working against the machine.
We're finally getting lots of things (HTML native validation, date and time pickers, etc.) that make JavaScript unnecessary for the things it was commonly used for in the 2000s. Unfortunately, in the mean time, client side scripting has metastasized throughout web applications to the point that things that browsers and HTML actually do implement well (history, keeping your place in the page, accessibility) are generally re-implemented, poorly, by web applications.
Not knowing about it can also qualify you as a very senior dev (though not very up to date with recent improvements) as the form tag was apparently added to the (then informal) HTML format around 1994 ;)
I had a similar experience with my sister in law who is getting her programming degree this month. When I asked her what was her final project and some details about it, she told me the entry point to her frontend was Angular. When asked how it was served and how it got to the browser, all i got was confused looks. When I showed her that the first thing that gets to the browser is an HTML file that then loads Angular and her application, her mind was blown.
I had a similar experience with a family member. When I asked them how their keyboard strokes appeared on the screen, all I got was confused looks. When I showed them that the first thing that happens is a hardware interrupt, her mind was blown.
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.
I think your analogy would be valid if the previous commenter had, for example, asked their sister-in-law how the browser interprets the JavaScript it receives, or how it builds the display from the DOM. Now that would be asking about irrelevant and unnecessary levels of detail which are best abstracted away. However, knowing that the process starts with the browser receiving HTML over HTTP is essential to understand what's going on, even if you know nothing about the details.
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.
I would categorize things as "does someone on the team need to know this":
* 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.
> * How is an HTTPS connection created: generally no
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.
In 2022 that person is ops not dev. None of my devs have any knowledge [1] about TLS, DNS, or even TCP. The only interaction devs have with the messy outside world is Rack/WSGI, their DB ORM, their Queue/Job abstraction, and the AWS client libs.
[1] Not like they literally don’t know but that their code has no interaction with it.
That veil of abstraction gets pierced very quickly the moment you need to debug an issue or regression in your application. I'm working on an internal application that's using Django in my current job, and there are plenty of instances where we've had to run an EXPLAIN on the generated MySQL query to identify performance bottlenecks.
> 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.
> 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.
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.
Let me settle this debate: as I originally stated, the young developer was not stupid at all. She knew about HTML and forms and everything. She just didn't know how to work with it and, more importantly, she didn't want to get into that at the time, explaining that she didn't "want the site to look ugly" and that it was "a project for the portfolio" (implying that she needed to demonstrate her React skills).
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.
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.
Not knowing how Angular bootstraps is how you get super huge SPAs that take forever to load on anything that is not a gigabit connection. Technical details matter.
That may say more about her than CS in general. I remember my very first encounter with Angular I made my seniors investigate how the hell double way binding could even work that way to have them confess to me that yes, we had 40k repeating functions running every n seconds to check variable states... for a static website whose double binding was just a first render time convenience. No wonder our mexican clients with shit phones couldnt load the site as well as our iphone-heavy Hong Kong ones. And it was my very first day on Angular.
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
Man that is really sad, but I suspect these code in the cloud schemes will be targeted toward hordes of developers with such a superficial grasp on what’s happening.
I like an SPA pile on as much as the next person, but I've seen similar ignorance from asp.net webform developers many years ago. Some of those were even "experienced" developers.
I started in 2008 and I would be hopeless at certain things that I am sure were essential 20 years prior.
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've met such (male) frontend developers before, totally clueless when it comes to the DOM and how it works. Not putting any judgment in that really, tbh, because the React development model is superior for anything non-trivial (like a signin form).
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.
Same here, maybe GitLabs "web IDE" will one day support this by, e.g., pairing a vm or container to each session, and adding extensibility. Though given the massive monster that GitLab is already it might take some time (and $).
One argument that I hear is that all these abstractions allow the developer to focus on delivering products and not worrying about the nuts and bolts of the underlying system, but in my experience the best and most efficient developers have been the ones who know how the systems work.
They are not indeed, just sharing my anecdata that the best ones I have come across happen to know much more about the details.
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.
Thank you for posting this. I know that is expressed most succinctly with an upvote, but I wanted to reiterate, because you were able to express something I wasn’t able to quite put my finger on but have felt for a long time. I was hoping that the feeling that many new coders didn’t know what they were doing could be attributed to me just telling them to get off my virtual lawn; I can see that my fear is possibly justified.
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.
I just spin up a VM at Hetzner (or another low cost cloud provider) and code on that. I don't give up any control but can still use a much more standardized environment and easier switch between machines.
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.
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.
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.
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
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.
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.
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.
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!
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.
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.
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.
> 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.
218 comments
[ 2.8 ms ] story [ 269 ms ] threadWait, speed of light also improves exponentially?
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.
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?
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!
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.
And so will other companies, since it's a definite productivity boon.
I just setup projectname.mydomain.com or projectname.local.mydomain.com and I have that use a CF tunnel to my local dev environment.
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.
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.
Is VS Code actually required, or is there some way you can edit source code locally then push to codespaces to actually run it?
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)
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.
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..."
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.
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.
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).
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
> Make the ultimate developer experience wishlist for the average rich-country developer in 2030
It can be a bit of a mind shift for urban people to internalise that the internet is not always there.
[0] https://lewiscampbell.tech/blog/220205.html
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.
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.
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.
Explain that.
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.
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 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.
>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?
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.
It also has the advantage that setting up a new developer account is relatively fast.
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.
IMO we should be working towards self hosting appliances, federated and otherwise decentralised services, and local-first applications.
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.
Just automate localhost development environment deployment.
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.
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.
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).
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...
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.
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.
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.
* 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.
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.
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
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.
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.
https://www.gitpod.io/blog/opensource
At least Android and iOS taking over the consumer computing world has given me job security until I retire!
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.
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
Cause that's why I currently prefer avoiding even docker for my dev env.
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'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.
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.
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.
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.
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.
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.