Rationalizing Wrangler <> Pages

[irvinebroque]

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?

[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.

[geelen]

Hey @irvinebroque thanks for the question. I'm a tech lead on the Pages side and was lead dev on the Full Stack Pages feature. Been chatting to @threepointone about this a lot recently, and I second what he says above, we don't have specific plans to share, but we're definitely cognisant of the blurring of the lines with what we've both just shipped.

One thing I wanted to mention is that one of the next big features for us is allowing prebuilt Pages deployments to be uploaded, rather than generated on our infrastructure. That's going to make the platform a lot more flexible—you're no longer limited to 20 minute builds, code can be hosted somewhere that's not Github or Gitlab, and until we've shipped proper monorepo support you could use something like GH actions to publish multiple Pages projects from a single repo, that sort of thing.

The flipside of this is that a wrangler pages publish command might be the way we go to deliver that, and then the lines get real blurry indeed. So as part of that push we'll be considering the longer-term plans of both Wrangler and Pages and how users can use them both together, or migrate from one to the other.

Again, not sure what the outcome will look like, but I can assure you that the two teams internally are working together on getting this right.

[irvinebroque]

Thanks for the thoughtful replies @geelen and @threepointone!

allowing prebuilt Pages deployments to be uploaded, rather than generated on our infrastructure

This would solve my use-case of wanting to use Pages' file-based routing. And as services and environments mature, I'm sure there'd be a reasonably straightforward way to hack together preview deployments via Github Actions. I like this path - simple and straightforward, without having to force the projects to converge too much too early. I hear you that they're designed for different people and use-cases right now.

If the tooling for building a Pages project were open-source, I'd drop it into my existing worker right now and start using it today, and drop itty-router from my project. Happy to be the guinea pig for something like this.

Feel free to close this issue - wanted to drop this note in but didn't quite know where it should live with all the stuff coming out this week.

[geelen]

If the tooling for building a Pages project were open-source, I'd drop it into my existing worker right now and start using it today, and drop itty-router from my project. Happy to be the guinea pig for something like this.

Are you on the Discord? DM me (geelen#7503) and we can chat.

[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.

[Wallacy]

FWIW: Few things already changed.