Rationalizing Wrangler <> Pages

From day one of using Cloudflare Workers, it’s been hard to choose whether to use workers via Wrangler or Pages. I started on Pages, moved to Wrangler because I wanted everything (API, frontend, etc.) in one worker, and now the beta release of full-stack Pages has me tempted to use Pages.

I’d love to not have to pick between the two platforms - it seems like there’s an opportunity with wrangler2 not just to support Pages functionality, but to rationalize duplicate/missing functionality. For example

	Workers (via Wrangler)	Pages
Cron triggers	yes	no
File-based routing	no	yes
Preview deployments	no	yes
Real-time logs / wrangler tail	yes	no
Services	yes	no
Environments	2 implmentations - service environments and wrangler environments, custom names	Pages-only implementation, production and preview environments
Git integration / deploy hooks	no	yes
wrangler dev	yes, miniflare or wrangler	miniflare only (via wrangler2)
Billing	yes	free but limited

Right now, if you want to build a full-stack application, you have to tradeoff nice developer experience (Pages) against features necessary for building real full-stack software (Cron, logs, analytics/debugging, secrets, billing). Pages comes across as a separate product, rather than an extension of Workers that gives you all the same good stuff, wrapped up in a sensible and standardized framework.

Some of this is addressed in the Cloudflare Pages full-stack blog post - it sounds like logging, analytics and encrypted secrets are coming. But more broadly, I’d love to have some confidence that workers and wrangler features will be available on Pages, and that if I use Pages, I won’t miss out on good local dev functionality being built into Wrangler.

Specific to Wrangler, to me one if it’s absolute biggest selling points is that wrangler dev actually runs code in a Cloudflare Worker, while in development. Live debugging in dev, with code running on a real Cloudflare Worker, is a killer feature. I’d hate to lose this in order to get access to the file-based routing of Pages. And as long as that kind of compatibility uncertainty exists as new features are developed for each, it’s hard to know which path to bet on and invest in.

It seems like the current iteration of Wrangler does three jobs:

	Workers	Pages
1. Local development (wrangler dev)	Used	Can be used (wrangler2, local-only)
2. CLI to manage settings (wrangler secret put, wrangler kv:namespace)	Used	Not used (but might be one day?)
3. Deployment (wrangler publish)	Used	Not used (and will not be used, handled by deploy hooks / Github integration)

Is there an effort underway to rationalize this, or possibly clarify the purpose/boundaries/scope of wrangler, workers and pages? Are there aspects of this that are or aren’t part of the Roadmap to v2?

[myhro]

Disclaimer: I’ve been using Workers for more than 3 and a half years and did a presentation about it in the company I work for a few months ago.

Hi. There are a few Pages features that made me spend 12+ hours last Saturday migrating five different personal projects from Workers:

• File-based routing: that’s not just a killer feature, given how easy it is to use, but also a huge usability improvement by not having to worry if routes are properly defined for individual Workers nor URL paths.
• Abstracted storage: instead of almost unreadable automatically-named KV namespaces, static assets storage is abstracted away. Although I have no idea how much space is actually used by the built artifacts (right now only requests count is shown), having a cleaner KV UI is definitely a nice-to-have.

Even though, there are a few things I miss from Workers:

• Faster deployments: the announcement blog post itself mentioned that this is being worked on, but the time it takes for a build to start after a git push is non-negligible. Just checked a recently built project: 2m30s waiting on Initializing build environment while Building application took 30s and Deploying to Cloudflare's global network less than 5s.
  • Allow developers to build and deploy themselves, like we are used to do with Workers, would be awesome. Nice to know, as mentioned in a comment above, that this is in the works.
• 404 Not Found errors by default: I was a bit confused when non-existing URLs were showing other pages. Fixed by adding a default 404.html file, but it would be nice to not having to do that for every project and only customizing the error page if needed.
• Cron triggers: possible to work around with deploy hooks + GitHub Actions scheduled triggers.
• Custom domain for the preview environment: haven’t found a workaround for that yet. Possibly doable with Workers + Pages API.

For someone who started deploying by copy/pasting code in a browser in the Workers UI, later called the Workers API with curl, moved to wrangler publish and now just git push to Pages, I can attest: there were multiple and considerable improvements in the platform’s usability over the past few years. My impression is that Pages have significantly lowered the Workers learning curve and are here to stay. It’s crazy to think that one doesn’t even need to assemble a wrangler.toml file to start using Workers anymore.

The future of “start with Pages and customize it in depth as needed” makes total sense to me. This flexibility would be ideal, as one could make use of of its zero-config nature without losing its routing/storage abstractions when later tuning it.

Regards, Tiago.

[threepointone]

Thanks for bringing this up, and being so specific about it! I expect other folks on the teams will jump in here with their thoughts, but let me share mine. (A big disclaimer - these are my opinions, and I expect to be corrected by my colleagues haha. This is also not specific insight into our product roadmap, and as such, cannot be counted as insight into cloudflare’s execution plans.)

For context, I’m a tech lead on the Workers Developer Productivity team, wrote most of wrangler2, and we work closely with the Workers Pages team. Both our teams are broadly focused on solving the same problem: empowering developers to build ambitious systems.

Some history first - wrangler shipped a while ago with the goal of making Cloudflare Workers usable by developers. The usecases were much simpler back then; revolving around manipulating and modifying responses from another origin server, simple scripts for powering APIs, and so on. Enhancements landed at a good pace, notably wrangler dev. wrangler’s strong integration with Cloudflare services like KV (and of this week, Durable Objects) makes it a pretty compelling experience for building applications from scratch.

The focus has also shifted; instead of using it to build smaller parts of your application, we’re now using it to build larger systems. Cloudflare would like you to start using Workers from Day 1, for your frontend/backend/api/whatever. Workers will always be able to connect to external services and APIs, but by leveraging its massive network and unique features like KV and DO (and eventually R2 and more), you can build a whole lot more than just a simple API, and with architectures that were previously too hard to execute for mere mortals.

Pages shipped late last year with a different starting point: of building an opinionated stack that takes a lot of configuration and code out of the hands of developers, allowing them to focus on ‘delivering value’, as it were. Notably, removing the complexities of ‘builds’ and ‘versioning’ and allowing creators to instead build regular websites and get a one-click experience to leveraging massive Cloudflare’s network. Until this week, it was closer to ‘jamstack’ style applications, but now you can write full fledged workers applications, and get a lot more out of it.

A couple of other notable announcements this week: Database connectors, which lets you connect to databases (don’t forget to signup to get on the waitlist), and Services, which takes on the complexities of the “software development life cycle” onto our network.

At this point I would have made a table comparing wrangler (or rather, ‘raw’ workers) to Pages, but you’ve already done that part for us 😅. So let’s cut to the chase, here’s some bullet points:

• imo, wrangler is for folks who have very specific needs, and will probably have ‘newer’ features from cloudflare earlier than Pages does.
• that said, Pages, will continue to gain features, but always from the perspective of keeping the experience as low/no-configuration as possible.
• You can imagine the two of them converging towards the same goal; in the ideal future, Pages becomes the ‘default’ experience of wrangler, and you could dive into the depths to configure stuff that you need for bespoke/expert needs. (It’s not an accident that wrangler2 hosts the pages dev experience, expect a lot of code reuse and common features in the future)
• For example, yes, Pages will likely get cron triggers at some point, as well as logs, but not in the looser format that plain workers currently have.
• Similarly, wrangler will start getting more Pages-like features; for example, --public lets you server static assets without configuration, andw it’ll likely get Pages-style _headers and _redirects support.
• But ALSO, and I think this is important: there’s a story here where you can use Pages for part of your project, and a custom worker (or workers) alongside it for more complex usecases. So for example, you can make a Pages project, but also build a cron trigger worker that gets deployed separately. Pages+Workers=🚀. We’ll do a better story here by documenting it more, and having better starter kits/tools, integrate with Services, a better monorepo development story, etc.

So, to answer your questions:

• Is there an effort underway to rationalize this, or possibly clarify the purpose/boundaries/scope of wrangler, workers and pages?
  • Yes.
• Are there aspects of this that are or aren’t part of the Roadmap to v2?
  • None of this is really reflected in the roadmap to v2, and is an effort parallel to it. We don’t have specific plans to share today (in fact, we’re figuring out the details ourselves), but we’re working on it.
• What should I pick?
  • wrangler for bespoke/custom stuff, or for features Pages doesn’t have just yet, Pages for a more opinionated approach. Importantly, you could try using both of them together.