Thread by @yacinehmito

It's confirmed: Linc has been bought by Cloudflare! You might not know what Linc is, so let me share with you what I think this means for Cloudflare, and the frontend infrastructure landscape in general. 🧵

https://twitter.com/Cloudflare/status/1341368144041025537

The shortest way to define Linc.sh would be to say "It's a #JAMStack provider, like @vercel or @Netlify, but on your own Cloudflare account". (It also works with AWS, but I'll stick with Cloudflare for the rest of the thread.)

It's not doing Linc justice though (nor @vercel and @Netlify, which evolved beyond the simple JAMStack offering). One of the many things it does differently is that it understands what a frontend bundle is. In typical JAMStack providers, there's no such concept.

Typically, when you push a new commit (identified by its hash) or change a build config, a new deploy is triggered; and, part of the deploy is the build itself. So much so that @Netlify uses the terms deploy and build interchangeably.

But what are we building exactly when we deploy? We build the assets that make the provider work, either as code that runs on their server or assets that are served by them (to be used by the visitor's browser). That whole bunch is a frontend bundle.

By making frontend bundles first-class, using the FAB standard (@fab_spec), Linc can do stuff that no other provider can do. For example, say you want to test your frontend on a specific backend environment. With typical providers, you would push a commit on a branch.

Pushing that commit triggers a build and deploys the code. Once you're done, you then need to put that code in a mainline branch, which agains builds and deploys. If that mainline branch is only hooked to a pre-production environment, you'll need to do it again for production.

With Linc, bundles are stored independently of the commit and branch they originate from. They are identified by a hash of the code at the time of the build. Then, config is injected at runtime. This means that, if no other change occurs, you only need to build once.

The bundle is deployed on the test environment. Once everything is clear, it can be deployed _without rebuilding_ on the pre-production environment, instantly. And ultimately, it is deployed in production, almost instantly again.

This enables new workflows. Because the config is injected at runtime and not at build time, you don't even need to do the three deploys distinctly. You could just deploy on all three environments at the same time, gating this new bundle with a special URL!

You don't need to pronounce any git incantation and wait 5 minutes to test your code in development. It is always running, everywhere! Then, when comes the time to put that new code in the hands of the users, Linc can do an atomic deploy (without rebuild!) to Cloudflare.

This "special URL" stuff sounds like preview URLs, as seen for example with Netlify, right? On the surface, yes, but don't be mistaken: this is fundamentally different. The code that runs when you hit this preview URL is the same on _all_ environments.

They are not so much preview URLs than just addresses to a specific version of a bundle, running anywhere. It shortens the workflow of pushing, building, testing, deploying and releasing by a big factor!

You may not be convinced by this advantage. After all, if you have one testing environment and the bundle builds in less than 3 minutes, what's the need? Well, you need to try it to be convinced. Shortening the feedback loop is so important.

Still, you are more likely to see the benefits when you start scaling. At Spendesk, you have ten test environments, and the bundle builds in more than eleven minutes. Yes, eleven. With Linc, we shave off _at least_ 20 minutes waiting for the CI for each feature. It's huge.

That's all fine and dandy, but what does it actually means for Cloudflare? My opinion is that it ties in to the recently announced Cloudflare Pages.
At that time, I expressed my disappointment that it basically just copied @vercel and @Netlify. I might be wrong.

Cloudflare needs to distinguish itself from the current players, which have a gigantic head start. In typical Cloudflare fashion, that would probably means innovating by simplifying.

We have seen it with Cloudflare Workers already. They took an existing product category (FaaS on the edge, exemplified by AWS Lambda@Edge) and made it much simpler and much better.

First, at the runtime level. No node.js, no containers. Just raw v8 isolates with a minimal API. Building small functions is much simpler (not necessarily easier though), and the functions themselves run much faster. It's the only FaaS on the market with 0ms cold start!

Second, at the API level. Instead of having the option define 4 hooks like AWS Lambda@Edge does, Cloudflare Workers leverages the existing Service Worker API. It is so much simpler.

So, Cloudflare took an existing product category and, in it, produced something with totally unique properties by leveraging the power of simplification. Those unique properties naturally emerged from a product whose abstractions were much more suited to the problem being solved.

More recently, Cloudflare announced Durable Objects. Again, innovation through simplification. The typical way of managing a geo-replicated write model is by provisioning datastores in different regions and synchronise them at the application layer.

The genius of Cloudflare is realising that all this work could be removed by providing just the right primitive: an object, running on a single process, close to the user. That's it. You can't make it simpler. And in doing so this birthed a totally unique product.

Coming back to Cloudflare Pages: this product breaks the pattern a bit. It looked to me like a market grab. With Workers and Workers Sites, a business has all it needs to build any web product, but one thing: a workflow.

The workflow is basically what sold Vercel, Netlify and AWS Amplify: hook your GitHub repo and we will do the rest. Without such an easy process (and the tools that come with it) it's hard to convince a customer to pick the Workers platform.

Cloudflare Pages is an answer to this; but, not a category-breaking product. It also doesn't completely fit the overall vision of Cloudflare Workers as the backbone of edge computing. That's where Linc comes in.

Linc has already realised that vision. With FAB, they found the proper abstraction: the frontend bundle. That whole bunch of code and assets, served by the Cloudflare Workers platform.

I am eager to see how Linc can bring this to Cloudflare Pages. This will make this new JAMStack provider not only unique, but also much simpler.

I hope you enjoyed the long thread. I am gonna write another one later on all the feature of Linc I wish would be brought to Cloudflare and how. Stay tuned!