We halved DNS build delay and cut memory use by 85%
blog.cloudflare.com
blog.cloudflare.com
Curious what the R&D / efficiency development ROI is on reducing memory footprint. I suppose we should both consider current ROI and near future ROI (as the price of memory will likely stay high for at least another 1-2 years).
One thing that I really hope we see out of the LLM revolution: a return to native applications. You could argue that Electron cross-platform apps made sense when you had to pay a team to maintain two or three (at least) native clients; you can't make that argument anymore when the marginal cost of a line of code is $0.00.
I guess developers really prioritize velocity or ease over everything. Or maybe it's business pressure or directives?
Yes, they're getting their bonus. No, we can't hire and onboard more people to deal with the insane demands being made as a result. Why do you ask?
Platform-specific views simply aren't. For simple applications they might make sense, but at a certain point devs just want the shit to work. Electron solved that.
I do agree that LLMs & co should contribute to reversing this trend, though. I don't really see why you couldn't try to ship (true) native now.
Maybe once we didn't dare surmount the challenge, but today, the landscape is a lot better (and a lot less chaotic) and while yeah it sort of sucks in some annoying ongoing ways I can't imagine every org is going to find this some insurmountable difficult strenuous activity. Like, get good.
The anti-will against doing this drives people away from the web as platform.
They do have an ongoing effort to replace all of this with CEF, but it's still not done.
Even this is annoying compared to how it used to work, before they killed the IRC gateway you didn't even need a browser tab because it worked just fine in a terminal tab.
Most of the projects that I have seen are trying to push past that and get towards actual native-native (non-webview) rendering because despite being an even bigger pain and more work, they come out a lot better than the webviews.
2. While browsers are pretty compatible nowadays, not having to deal with WebKit/Safari quirks is a plus.
3. The platform webview isn’t necessarily that much more efficient.
The sin is this ridiculous era of every program shipping its own runtime. I'm headed for real down votes, but this is the same lazy culture that's taken over everywhere: go and rust both ship these huge statically compiled binaries.
When you are a company, you're only running a handful of different workloads/apps on any given box, so the statically compiled price doesn't bite you. But as users, going back to dynamically linking and making the incremental cost of loading an app not also have to carry the entire world with it is such an obvious return, and one that alas seems to not be in progress at all.
The agentic age is, I hope, going to question a lot of old assumptions & needs about what we want to run. Having lots of small resident little user agencies, compiled small scripts that are attributed to a user, is something I believe will happen, but I'm less convinced we'll recognize the face of it as it happens, that the tales will be told.
Tools like agent-substrate, ax, scion, are this interesting mix between agents, serverless, and kubernetes. I find it fascinating. (For hire on this.) https://github.com/agent-substrate/substrate
> The sin is this ridiculous era of every program shipping its own runtime. I'm headed for real down votes, but this is the same lazy culture that's taken over everywhere: go and rust both ship these huge statically compiled binaries.
Go and Rust are pretty efficient too, if your architecture isn't trash. If it is, they still probably are more efficient than Electron
Rust and go are somewhere on the continuum, between dynlibs and chrome, for how much private world they build for themselves. It's vastly less than chrome. But it's a lot. A lot more than what Linux distributions did for years and years and years.
Especially if you think if multiuser systems with multiple people using programs, then you have some scaling factor. Then it matters a lot a lot more than each lib has to be loaded distinctly for each process.
It's not good. It's not good for Electron, there are vastly better ways to run many apps taking a more dynlib path, and it's not good for rust or go. As nice as it is to dev like that.
Of course it's another huge problem that dependency trees are rarely shared. Go look at Class Data Sharing in Java: building the libs you standardize on (your orgs stdlibs) and there's this beautiful idea here that you should just already have some common things expected to be there. That's harder to imagine since so many programs have such different dep stacks. But imagine having a Tokio or tokio+++ that everyone can use, good foundational tools (Grand Central dispatch and the never arrived NextBSD) Some common substrate, with just like async as one example. And the size of that shared good useful library/platform can grow, hopefully revive an interest in reuse vs bringing your own every time. https://docs.oracle.com/en/java/javase/17/vm/class-data-shar...
GP is stating that on such a system, static executables are expensive (and chrome is completely out of scope)
A Go binary can be scp'd as a single file to any server with the same processor architecture and just run. I've never encountered that in any other framework.
We've accepted this as a yes absolutely to try anything is folly excuse for decades. It was tired already and it's ridiculous today to just accept it as a hard stop wall.
The degree to which people have allowed laziness of scp anywhere to dominate reason and sense and improvement is gob smacking. Skill issue. There's more than just eternal convenience for this one extremely lazy use case at stake.
There's no reason to think that "the agentic age" will bring about any runtime efficiency. It may, perhaps, reduce development time but it doesn't introduce any new incentive to make software more efficient. It may happen, in a very roundabout way, by making consumer RAM massively more expensive which might induce customers to choose more efficient software, but it's too early to tell if this effect if happening.
It seems ridiculous, beyond imagining to me to imagine software runtimes won't change one iota as the world starts copariticpating a bit more in computing, as we have all these agentic systems spawning. You'd have to be mad to bet on stasis. I don't know why anyone would cling to such an assumption that it's just going to tick on same as ever. That's the goofiest shit.
Software has changed and evolved and shifted forms so many times already. This seems like a very big possible impact. Maybe most people don't see and remain in their disbelief for 6 months. For a year. For two years. For five years. But I think on retrospect it's going to be quite clear that software runs very differently and that we generally did change workload running, execution, runtimes massively, in direct support of the LLM age. There's some question of how long it's apparent. But on a long enough timeline all stasis leads for rebirth. And this is a pretty high dynamic energy age now. This idea that stasis is going to win. And keep winning..on and on: I am a skeptic. I already too too much contrary evidence.
But it's convenient. I can't really fault people for using it.
I'm sure exact pinning is sometimes the real intended case for certain apps, as it is a value in certain ways, but I'd bet at least half the Electron apps I have running now would happily be using the same shared instance of the same LTS Chromium+Node if it were the out of the box behavior to be able to do so.
Maybe, since Electron has evolved as a somewhat common standard... the major OS providers should get together and revive this idea. The OS provides, similar to say Java JRE, a base runtime of a browser and a JS interpreter with a specified set of helper APIs to use local functionality such as filesystem access, raw networking, notifications, yadda yadda, and apps just call that runtime.
But they dropped plans to support it on macOS and Linux so it's a bit useless as an Electron replacement. Not that it was exactly a drop in for Electron - it's web based but with a different set of extra APIs. I don't think things will move as fast to something else now that apps are already built on Electron and the savings is for the user rather than the developer. It really needs to be 100% Electron compatible, just with the difference in launch behavior.
It's a shame common frameworks like ActiveX died, and now everything you want to embed has to be embedded in a different custom way, too.
This is exactly what Palm created in the late '00s. Just like the Amiga, it was a bit too early and kneecapped by sub-par overpriced hardware (and a bad acquisition by HP).
We can and we should.
I dream of a day I can transpile a common view/controller language into executables for multiple platforms... without it sucking.
Feels like GUI frameworks have gone downhill after Windows Forms. Probably coinciding with everyone wanting a completely custom fancy GUI.
If it is about a Postman/Insomnia/Bruno alternative, the answer is yes.
I use it everyday now, it is called APIKulture. It may not look as pretty, but it is insanely faster than Bruno.
And Postman/Insomnia now require login to their systems which I just refuse to do.
In that case the toolkit I used is called wxWidgets. It has been my Electron alternative for two decades.
It is the effort of hundreds of people, so I find your comment of "just build one" as pretentious as it can be. No single person can do this. It's a collective effort.
This is basically the crux of what I have been thinking about. Will some of these inefficient programs start to get optimized while we are at a plateau of memory for our desktops/laptops?
Client-side: lol sucks to be you
Source: I was Cloudflare's CTO.
2) You're targeting to the wrong person. Blame the managers at Netscape for pushing Brendan Eich into creating JS, rather than letting him use Scheme as the scripting language. From there, it would've made sense to allow Scheme to be compiled into bytecode.
I'd also say that when you look at JITed language like Lua and JavaScript the performance is pretty damn impressive. As with so many things it depends what you're doing.
I don't know you from a grain of salt, but you've seemed to be pretty open and honest on HN about some of the inner workings (technically and politically) of Cloudflare, which is appreciated.
I worked with 2 of the cofounders at their previous company and some of the original prototype was written at my apartment at the time.
It is a pretty small niche of companies where compute resource efficiency on the server side has a meaningful business bottom line impact.
Everybody has a few tight loops here and there that would be beneficial but that is usually a very small selection of hot paths and it usually isn't about the money to run the code.
On the client side it's about customer delight and this is terrifically hard to measure and so many companies set themselves up such that disappointed customers are locked in so well it doesn't make a huge difference how happy they are unless they're VERY unhappy.
(In other words, you're not Google or Cloudflare)
> Why doesn't the Zone Builder just rebuild the setting that changed?
> It should, and that is where we ended up. However, proving when it was safe took most of the work. A record event identifies what changed. A zone event can come from many Cloudflare products, may not say why the zone changed, and can alter data shared by several zones with the same name. Choosing too much work wastes capacity. Choosing too little can leave stale or incorrect DNS data at the edge.
Re-reading the start of the post with that in mind, I'm fairly sure the article was generated by LLM.
With that said, curated it sure is. Aside from the smelly phrasing, the actual content is fairly dense and engaging. Not all of Cloudflare's LLM-generated posts are this good, but this one is fairly alright.
What does it measure?
> smelly phrasing
How so?
Even if linguistics doesn't really quantify observations (eg. percentage use of specific words in a text), it at least provides qualititative observations (eg. contemporary novels contain shorter sentences and fewer details). What are you trying to convey here? That you're not one to be fooled and everyone should heed your words?
700 changes per second implies 15% of all domains are changing daily, which is almost certainly not the case.
I imagine a renewal is a change event to, at least change the expiry, and renewals are constantly happening.
A domain renewal is an update at the registry, but there's no update in DNS at any level. If a domain expires, it would be removed (or at least changed) in the TLD DNS, but the authoritative DNS for the domain wouldn't necessarily update... it would just become orphaned.
700 changes per second is 1.8 billion changes per month. I guess 10 changes per top level domain per month is quite low, which suggests a very long tail distribution, which makes sense, given that most websites are just a static page a business sets up once, with DNS changes maybe once every few years.