Rendered at 02:50:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
thephyber 10 hours ago [-]
I have been wondering if the memory scarcity would lead to a desire to optimize software to be more efficient.
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).
jgrahamc 9 hours ago [-]
Cloudflare always had a pretty strong culture around optimisation. If you go back and read the blog there are a lot of blogs about reducing CPU, latency, RAM, etc. through software. It's one of the key features of how Cloudflare has been successful and an important part of succeeding in today's world.
Source: I was Cloudflare's CTO.
kevin_thibedeau 2 hours ago [-]
Why the heavy reliance on Javascript when native code would bring performance and energy savings?
cowlevel 12 minutes ago [-]
isn't that their job? you can't deliver native code to web browsers.
rancar2 5 hours ago [-]
And Cloudflare is making money on infrastructure margins not eyeballs (ie advertising like Google), so the incentives are well aligned for this to continue.
placatedmayhem 10 hours ago [-]
Coincidentally, I just got angry this weekend about my Mac with 64GB of RAM going OOM because of poorly optimized applications. Use of web tech, especially Electron, was common among basically all of the offending applications. Whether Electron itself or just poor coding, I'm not sure, but there's a pattern.
Shorel 16 minutes ago [-]
The use of Electron is poor coding.
cowlevel 11 minutes ago [-]
Easy to say, and probably true, but this is "armchair quarterbacking". Did you make a better one without Electron that I can use instead, or do I still have to use the Electron one?
Feels like GUI frameworks have gone downhill after Windows Forms. Probably coinciding with everyone wanting a completely custom fancy GUI.
renehsz 10 hours ago [-]
Electron needs to die.
But it's convenient. I can't really fault people for using it.
zamadatix 7 hours ago [-]
I think the biggest fault in Electron is not just that it's inefficient web tech but that it has no provision for shared instances between apps, instead foricing every app to be the one which only ever wants to use the EXACT locally bundled copy of Chromium+Node which should launch in isolation of any others. This isn't even something Electron needs to die and be replaced for, just an optional feature other similar tools have jumped on for years now.
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.
mschuster91 5 hours ago [-]
Back in the Windows era... you could embed Internet Explorer as an ActiveX control in your VB6 app and interface with it, albeit very rudimentary.
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.
cowlevel 10 minutes ago [-]
That's not really any different from what Electron does with Chrome except that it includes its own copy of Chrome instead of loading it from system32.
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.
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.
andyferris 5 hours ago [-]
The OS's do provide webviews pretty uniformly, and the browser engines they ship with behave more similarly than in the days of IE.
whh 4 hours ago [-]
I'd donate nails for its coffin. Sadly, making unique apps for each platform is just too hard when you're considering the minimum output to create value.
I dream of a day I can transpile a common view/controller language into executables for multiple platforms... without it sucking.
cowlevel 9 minutes ago [-]
This is probably a good use for a carefully monitored LLM.
ragall 5 hours ago [-]
> I can't really fault people for using it.
We can and we should.
Aperocky 9 hours ago [-]
claude-code is using a suspicious amount of memory and doesn't seem to care about optimizing it nearly as much as the others.
MisterMunchkin 8 hours ago [-]
The source for Claude code leaked and it is total slop. They don’t even look at their own code.
lenerdenator 10 hours ago [-]
Electron's more-or-less just Chrome without... erm... chrome, so it makes sense that it's bloated and uses too much RAM. Even well-constructed and efficient JavaScript executed through it will do so on top of a bunch of stuff your application might not even need.
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.
floydnoel 10 hours ago [-]
What I don’t understand is, why not just use a platform native webview? Mac has it at least, I think Windows does as well. You'd think it would be the same amount of work (roughly) but use a lot less memory.
I guess developers really prioritize velocity or ease over everything. Or maybe it's business pressure or directives?
Klonoar 10 hours ago [-]
There's a comment somewhere on HN from a Slack dev who was the one responsible for moving away from platform-specific webviews to Electron. The core reason is that Electron is the same on all platforms it ships on, generally speaking.
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.
jauntywundrkind 6 hours ago [-]
In the evergreen (and generally broadly much better) browser age this is an assumption / concern that I think could really use some reconsideration, lol.
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.
Daedren 2 hours ago [-]
Tauri is still pretty problematic, mainly because of WebKit vs Blink, nothing has changed to improve that.
They do have an ongoing effort to replace all of this with CEF, but it's still not done.
freedomben 9 hours ago [-]
There's Tauri, but (at least when I tried it last) it had bugs that made building functioning RPM packages extremely difficult. Bug(s) had been there for over a year at least with no momentum, so if you need to support rpm-based distros you're in for a rough time.
skrtskrt 8 hours ago [-]
I mean if you look at all the frameworks that are trying to push towards native support across platorms, the ones that are took a pit stop at platform-native webviews, before going full native all have negative opinions of platform-native webviews. Besides all the tons of effort and buggy sharp corners there are across platforms, a lot of them just make really crappy UIs.
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.
paulddraper 7 hours ago [-]
1. Cross platform.
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.
lenerdenator 10 hours ago [-]
Business pressure. Always business pressure. Sales sold a bill of goods and now you need to deliver ASAP. Hardware was cheaper than dev time. Was.
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?
jauntywundrkind 8 hours ago [-]
Chrome is pretty efficient, as far as per page costs go! If your architecture isn't trash!
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
saghm 8 hours ago [-]
> Chrome is pretty efficient, as far as per page costs go! If your architecture isn't trash!
> 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
jauntywundrkind 6 hours ago [-]
If we want a system like, say, sdf, it would be so much worse to make each program have to host its own world, its own runtime.
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...
saghm 6 hours ago [-]
I'm not sure at all what you're talking about at this point. The most relevant thing I can find with the abbreviation "sdf" is https://sdf.org/, but I don't understand what hypothetical version of that you're talking about where would be entirely contained within a Chrome instance.
shwouchk 2 hours ago [-]
sdf.org is the one. it’s a shared computing environment with thousands of users, mostly volunteer and donation based.
GP is stating that on such a system, static executables are expensive (and chrome is completely out of scope)
cowlevel 5 minutes ago [-]
Sure but they can do that because they own most of the system. It's the same with e.g. Debian - all the binaries you get from the repo work with all the libraries you get from the repo because they're built as part of one big project. When a separate party wants to ship something that works on most Linux systems they have to minimize dependencies as much as possible. They don't get the luxury of being the same person who controls most of the rest of the system.
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.
ragall 4 hours ago [-]
> The agentic age is, I hope, going to question a lot of old assumptions & needs about what we want to run.
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.
jauntywundrkind 2 hours ago [-]
There's no reason to think anything might change, that process execution and what we run is going to stay the same on and on and on. Got it. Stasis forever. Let's not consider anything else!
ragall 23 minutes ago [-]
That's a rather stupid reply. The economics of the production have changed, but not the incentives.
smallnix 5 hours ago [-]
The hottest kpi to optimize against is now freed tb of memory
colechristensen 5 hours ago [-]
>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).
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)
nikanj 10 hours ago [-]
Server-side: sure
Client-side: lol sucks to be you
mhovd 10 hours ago [-]
Cloudflare doesn't get enough credit for their series of overall great technical blog posts.
schainks 10 hours ago [-]
They also read like actual human curated content, to boot.
LoganDark 9 hours ago [-]
My LLM detector started going off around here:
> 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.
whoanoway 9 hours ago [-]
[dead]
enjoyyourlife 5 hours ago [-]
What's it like working at Cloudflare?
cowlevel 4 minutes ago [-]
Sometimes a dog walks in front of the lava lamps and everyone's secret key is 0 for a few minutes.
9 hours ago [-]
InsidiousWombat 10 hours ago [-]
Isn't 700 changes a second like... really low, considering their scale and amount of domains they manage ?
straygar 10 hours ago [-]
There's about 360 million domains (according to Verisign as of March 31, includes inactive sites as well) and if Cloudflare manages about 1/3 to 1/2 of them, that's like 180 million domains at most.
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.
mvkel 10 hours ago [-]
412M domains registered worldwide
700 changes per second implies 15% of all domains are changing daily, which is almost certainly not the case.
enedil 10 hours ago [-]
It's well possible that some people update DNS records for their own domain every minute.
Don't need to assume maliciousness - it's also used for scaling and load balancing.
6 hours ago [-]
zoeysmithe 10 hours ago [-]
I can see 15% changing daily. There's all sorts of stuff being done with dkim and other anti-spam technologies that require a txt or cname or whatever change in DNS. Companies are always whitelisting vendors and mass mailers to send as them, validating domain ownership, adding new sub-domains, changing things for Exchange/365/Google/AI stuff, changing things due to a security audit, etc.
I imagine a renewal is a change event to, at least change the expiry, and renewals are constantly happening.
toast0 9 hours ago [-]
> 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.
cyberax 5 hours ago [-]
Quite possible, especially with Let's Encrypt DNS challenges.
LoganDark 9 hours ago [-]
It's probably more like most domains barely change at all but some of them change a lot.
JulianPaul 9 hours ago [-]
I'm very curious about the bugs (before vs. after relational) that come from an improvement like this over time
5 hours ago [-]
lanmu 45 minutes ago [-]
[flagged]
likoya 7 hours ago [-]
I used to use cloudflare dns, but the same cloudflare harassed me the entire day testing if I'm a robot. The harassment ended after I switched the dns server. See you never again, clouflare
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).
Source: I was Cloudflare's CTO.
Feels like GUI frameworks have gone downhill after Windows Forms. Probably coinciding with everyone wanting a completely custom fancy GUI.
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.
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.
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.
I dream of a day I can transpile a common view/controller language into executables for multiple platforms... without it sucking.
We can and we should.
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?
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.
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.
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?
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.
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 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)
Client-side: lol sucks to be you
> 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.
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.
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.