Netlify, GitHub Pages & GitLab Pages

GitHub/GitLab pages are among the most widespread publishing tools among developers. They are free, have no frills, and they’re easy to use but - let’s face it - they are quite basic. Sometimes too basic.

Sure, they may be fine for your cool personal landing page, but sometimes developers simply need more flexibility and capabilities to host slightly more complex demos of their products, for example.

GitLab Pages has a few advantages over its GitHub doppelgänger, indeed:

• You can self-host your own GitLab instance and as such actually own your data.
• Project pages are available - you can set up pages for a group’s namespace.
• Pages can be integrated in the CI configuration to embed, for example, a build’s artifacts.

But then Netlify came into play with advanced features such as globally distributed CDNs, atomic deploys with one-click rollbacks, and on-demand instant cache invalidation (less than 1s!).

GH/GL Pages is a simple solution but has significant soft limitations in place in terms of disk space, bandwith and builds-per-hour; GL Pages does not impose you such limits, but has a significant caveat for HTTPS on subdomains. Netlify is instead your go-to & fully-fledged solutions for web applications that scale, still maintaining that simplicity that GH/GL Pages got developers accustomed to:

• Optimized CDNs can handle traffic spikes without blinking.
• Internationalization is handled even before the client reaches your domain, as he or she is redirected at DNS and CDN level.
• SSL certificates can be rotated without complex practices.
• Are you ready for HTTP2? Because Netlify is.
• Integrated DDoS protection, no more bouncing via CloudFlare’s certificates.
• Custom domains (you could as well use differnet subdomains in place of separate project/group pages).
• Deploys can be automated via webhooks, choose your CI/CD tool of choice and stop worrying.

As a developer, one of the most important questions about this kind of publishing tools should be:

How do I deploy my content? I’ve already spent hours creating it, I don’t want to spend as much time deploying it.

The process for GH/GL Pages is quite easy:

• Create a repository named USERNAME.{github|gitlab}.io in your account
• Clone it locally
• Commit & push your static content (must be the in the final assets form)
• Have fun

While this is surely simple enough, it has some practical limitations, and the project page for my Dumpster project (here the blog post about it) it the living example: POST requests are not supported.

This, along with many other caveats, is one of the itches that you won’t find in Netlify’s deployment process:

• Create your repository on either GitHub, GitLab, BitBucket
• Clone it locally
• Commit & push content (can be raw unprocessed content, as Netlify will run Grunt, Gulp or Broccoli tasks for you on deploy)
• Have fun

The two processes may look the same, but there are a few benefits in the latter:

• You can use unprocessed assets: if you use a task runner to package them up, Netlify supports it.
• Thanks to their CLI tool, you are not tied to one of the publicly available Git hosters: you may as well have an in-house repository that gets manually pushed.
• Netlify supports generic webhooks for deploying your website - do you use an obscure custom-made CI/testing tool for your content? No problem, just make it call an URL with some simple metadata to trigger a deploy.

Lately Netlify has introduced a new cool thing as well: the Deploy to Netlify button.

If you have a template that you want to reuse, just link one of these useful buttons to its repository to be ready to launch a customized instance in no time, whenever you’ll need it. Definitely useful for one-off project demos that have short lives.

The JAMstack philosophy

JavaScript, API & Markup

Netlify is founded on the JAMstack principles:

• Decouple Building and Hosting
• Decouple Front-end and Back-end
• APIs rather than databases
• Pre-baked Markup, enhanced with JS

This makes this stack the perfect place to try out serverless frameworks: with most of your architectural complexities abstracted out via CDNs and APIs, you are free from managing any kind of database - if you want to make it so. The same goes for heavy frameworks addons or other >32KB file that your page would usually pull from its server just to extract some small informations. Let it run somewhere else, instead of consuming a client’s resources!

The best part of this kind of architecture is the small footprint that its development environment has on your machine: just get ahold of some common utilities (many of them will even come pre-installed on most OSs!), and you are ready to go. No huge and clumsy IDEs, no custom configurations scattered all over your system, no need for a dedicated virtual environment! Just fire up your favorite text editor & browser combo, and develop away.

If you feel that GitHub/GitLab Pages is getting tight on you, or if you just want to experiment with what the future has to offer, simply spin up a free tier account on Netlify and migrate your Git* Pages content in no time, thanks to this 5-step migration guide.