Hacker News Reader

Comment by aperture147 | Hacker News Reader

It’s good that CF is actually trying to improve its platform instead of blaming others for smearing its product. Still, the breakneck pace is a mixed blessing. Things change so fast it’s hard to keep up, and launches often outrun polish. The R2 Data Catalog still lacks Iceberg v3 support; Wrangler has shifted dramatically in just a few months; and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate. Configs that worked in Wrangler 3 didn’t carry over cleanly to Wrangler 4, and it feels like Wrangler 5 will introduce yet another interaction model.

View on HN

> Configs that worked in Wrangler 3 didn’t carry over cleanly to Wrangler 4, and it feels like Wrangler 5 will introduce yet another interaction model.

There were no changes to the config format in Wrangler 4. The reasons for the major version bump didn't affect 99.99% of users. They are listed here:

https://developers.cloudflare.com/workers/wrangler/migration...

Personally I pushed back on bumping the major version at all, because I know even a no-op major version update creates pain. But the team wasn't comfortable given the obscure edge cases. We have resolved, though, that in the future we'll build ways to manage all these issues without requiring a major version bump (e.g. support multiple versions of esbuild, so that you can upgrade wrangler without updating esbuild).

Incidentally, on the runtime side especially, we're pretty maniacal about backwards compatibility: https://blog.cloudflare.com/backwards-compatibility-in-cloud...

> Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.

Pages are not "on the way out". Workers Assets are just a new, more flexible implementation of Pages, which makes it easier to use other Workers features together with Pages. If you don't need those other features, you do not need to migrate. Eventually, we will get to the point where we can auto-migrate everybody, we just aren't there yet.

> and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.

According to this community post CF isn't going to deprecate pages until workers achieve parity: https://community.cloudflare.com/t/static-web-site-in-worker...

That said I can't actually find a place where CF says pages are deprecated. pages.cloudflare.com seems all-in on it, as does developer.cloudflare.com/pages. I see a reddit post where somebody implies they're deprecating pages, but the page they link to [1] doesn't mention anything about pages going away.

That doesn't take away from the rest of what you're saying, it's just the part that made my heart skip a beat.

[1] https://www.reddit.com/r/webdev/comments/1mme85y/cloudflare_...

It's not deprecated. There's confusion because the implementation is changing to be better-integrated with Workers, and currently it's manual migration to get the new implementation, but eventually it'll be automatic. It'll still be called "Pages" when that happens.

Where do you see that "pages seems to be on the way out"? I use pages for a few projects...

CF used to encouraged people to move to Workers instead of using Pages. They recently removed the message in their landing page that said so (just checked, you could visit Wayback Machine to verify), so I guess Pages will still be available anyway. Btw the best thing that Pages gives out is allowing people to use different domain from another domain registry when Workers force user move their domain to CF.

Workers require you to use CF as a domain registry? Where is that written and what possible reason do they give for it? That's quite an imposition.

Not the domain registry but CF wants to manage the DNS to make it work. If you do not want them to manage your DNS and want to work by simply pointing your CNAME, they ask you start with their business plan ($250 / per month)

Right, but that's not the same thing and is intrinsic to how CF works - routing DNS requests from different areas to different IPs. Is there any good reason not to just let them serve your DNS if they're serving your website?

(will they accept a delegated subdomain?)

They don't accept delegated subdomains, at least not for .net and .com domains (I haven't tried others).

I don't see how it's "intrinsic to how CF works" that they need to host your DNS records, especially when they don't require it on more expensive plans.

That being said, I don't mind them hosting my DNS records, but it would have been nice if they supported importing zone files from Azure DNS.

The migration guide contains this:

> Workers will receive the focus of Cloudflare's development efforts going forwards, so we therefore are recommending using Cloudflare Workers over Cloudflare Pages for any new projects

https://developers.cloudflare.com/workers/static-assets/migr...

I didn't find it hard to migrate. Pages are workers, so might as well just use a worker.

It's hard if you don't use a JavaScript based SSG, well I didn't find how to do it with Hugo so I'll stay in cloudfare pages

Generate the files locally and then push them to the worker? Even with a JS based SSG that's the only way to do it and the difference between worker and pages. (workers have no build step)

https://gohugo.io/host-and-deploy/host-on-cloudflare/

https://discourse.gohugo.io/t/hugo-support-in-cloudflare-wor...

https://discourse.gohugo.io/t/hosting-a-hugo-site-on-a-cloud...

Just to note because I was confused by this:

I was under the impression that workers are just lambda functions, and therefore would fall under different billing rules than pages which serve static files (with unlimited bandwidth).

But workers apparently have a 'Static Assets' feature that just serves static assets (like pages) and comes with free unlimited requests, unlike worker function invocations, so as you say it seems to be essentially the same as pages.

https://developers.cloudflare.com/workers/static-assets/

What I meant the same as worker, is that under the hood, pages are just workers. The Static Assets feature was probably added because the by-request billing wouldn't make any sense for static assets.

Fun thing is that this started because somebody claimed that Cloudflare is faster than Vercel. Then somebody who knows what they are doing did benchmarks that showed the opposite. And then worked with Cloudflare to make it faster

Theo knowing what he’s doing died for me when he did a dive into this fancy new data format OpenAI started using to stream responses from the server and how wasteful it is (SSE) (and this was in 2025)

I don’t except everyone to know everything but it made me very careful about differentiating Theo-the-engineer from Theo-the-social-media-dude.

And nobody on the benchmarks mentioned that Vercel runs it on 2 gb. Instances ( and much more expensive) while Cloudflare is competitive with 128 mb. instances.

I guess that's the difference between building on top of AWS and actually building your own infrastructure.

They might flip the emergency switch that burns a little more money to improve the cold start, schedule more CPUs to each V8 process or remove the `sleep(100)` somewhere in the code. I kinda doubt that they have actually made any code improvement but just a marketing stunt that make everything seems to be faster for a month then everything will be just as slow as it is, or they are buying time to actually improve the code.

Reminder to use boring tech when building something important that should last for some years.

Reply on news.ycombinator.com