workers-sdk VS kawipiko

Workers

https://github.com/cloudflare/workers-sdk/blob/main/packages...

The Wrangler, Cloudflare's Developer Platform command-line interface (CLI), allows you to manage Worker projects and has an in-built Miniflare, which runs an HTTP server.

/** * Welcome to Cloudflare Workers! This is your first worker. * * - Run `npm run dev` in your terminal to start a development server * - Open a browser tab at http://localhost:8787/ to see your worker in action * - Run `npm run deploy` to publish your worker * * Learn more at https://developers.cloudflare.com/workers/ */ export interface Env { // Example binding to KV. Learn more at https://developers.cloudflare.com/workers/runtime-apis/kv/ // MY_KV_NAMESPACE: KVNamespace; // // Example binding to Durable Object. Learn more at https://developers.cloudflare.com/workers/runtime-apis/durable-objects/ // MY_DURABLE_OBJECT: DurableObjectNamespace; // // Example binding to R2. Learn more at https://developers.cloudflare.com/workers/runtime-apis/r2/ // MY_BUCKET: R2Bucket; // // Example binding to a Service. Learn more at https://developers.cloudflare.com/workers/runtime-apis/service-bindings/ // MY_SERVICE: Fetcher; // // Example binding to a Queue. Learn more at https://developers.cloudflare.com/queues/javascript-apis/ // MY_QUEUE: Queue; } export default { async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise { return new Response('Hello World!'); }, };

$ npm create cloudflare@latest using create-cloudflare version 2.9.0 ╭ Create an application with Cloudflare Step 1 of 3 │ ├ In which directory do you want to create your application? │ dir ./apps/worker │ ├ What type of application do you want to create? │ type "Hello World" Worker │ ├ Do you want to use TypeScript? │ yes typescript │ ├ Copying files from "hello-world" template │ ├ Retrieving current workerd compatibility date │ compatibility date 2023-12-18 │ ╰ Application created ╭ Installing dependencies Step 2 of 3 │ ├ Installing dependencies │ installed via `npm install` │ ├ Installing @cloudflare/workers-types │ installed via npm │ ├ Adding latest types to `tsconfig.json` │ skipped couldn't find latest compatible version of @cloudflare/workers-types │ ╰ Dependencies Installed ╭ Deploy with Cloudflare Step 3 of 3 │ ├ Do you want to deploy your application? │ no deploy via `npm run deploy` │ ├ APPLICATION CREATED Deploy your application with npm run deploy │ │ Navigate to the new directory cd apps/worker │ Run the development server npm run start │ Deploy your application npm run deploy │ Read the documentation https://developers.cloudflare.com/workers │ Stuck? Join us at https://discord.gg/cloudflaredev │ ╰ See you again soon!

Except that there is. Cloudflare is pretty great for free SSL certificates and DNS management, but they also offer a free Workers plan. A Cloudflare worker is basically JavaScript code that runs on Cloudflare's edge network and handles HTTP traffic. You can do a lot with workers, including modifying/rewriting HTML responses. You can probably see where this is going: If a worker can modify HTML responses, then it can inject the umami script into every HTML response.

Cloudflare Workers

And what about the DX of using Workers with Pages?

I tried to use that recently and it was a disaster. I wrote about my experience here:

https://twitter.com/pierbover/status/1641474067013271552

I then opened these two issues:

https://github.com/cloudflare/workers-sdk/issues/2962

https://github.com/cloudflare/workers-sdk/issues/2964

I ended up moving the project over to Netlify + Edge functions. I had it all working in like 5-10 mins as it should. Took me two hours to figure out why Workers weren't working in my Pages project, and could never get Workers working properly with my Astro project.

I think you're working exclusively on the engine of Workers which is really top notch, but Cloudflare really needs to improve the outer layer which affects DX considerably.

If you think this is a bug, please open an issue at: https://github.com/cloudflare/workers-sdk/issues/new/choose ```

[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is <https://redbean.dev/> which I find just so intriguing, and not far from my own <https://github.com/volution/kawipiko> proposal.)

Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.

It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.

The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:

* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)

* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;

The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.