How Git has Shaped the Web and Jamstack

If we look at the history of Git, we can see the enormous effect it has had on everything that makes the modern web a better place for developers and companies alike. It might not seem entirely obvious that a version control system for text files has anything specific to do with the modern web. It might be easy to think that these two were different worlds—that web apps evolved completely differently from how we actually manage the source behind those web apps. However, the closer we look, the more we will see Git’s influence on how the web is still being built today. 

Early Version Control Patterns

Before Git, there were other early-stage, decentralized source control systems, but far more popular were centralized source control management systems, like Apache’s Subversion (SVN). SVN, which still exists, was a very common source control system in the early days of the web. The SVN model relies on running a central source control server.

With SVN, every repository has to be set up as its own server that each individual developer connects to, making a local working copy on their own machine, with the server always being the single source of truth. This central server model requires a systems operator to run SVN on a machine somewhere. This operational overhead makes it difficult to use SVN for hobby projects or smaller projects.

Wow, Git is Like Magic

It might seem mundane today, but when Git first premiered, the idea that you could initiate a new instance of a version control system by simply typing `git init` in any folder was magical.  You had a full version control system on your local laptop without the need to set up a central server and maintain it. 

Suddenly, if you made changes to any file in your project folder, you had access to a full Git status and Git history, letting you see how your code was modified. The simple and fast commands allowed you to add files to a repository and make Git commits without any server setup, without any provisioning, or without managing any other servers. It was simply groundbreaking.

It’s easy to forget, but before Git, doing things like checkout, branching, and immediately seeing diffs, even between branches, was revolutionary. 

This completely changed how folders and files worked on a local machine. Git meant you could have a README file, type a command to Git checkout another branch, and suddenly have a completely different README on your screen. This magic meant every folder on a laptop had a whole new potential, and what used to be a really cumbersome, big operation like merging different branches in a Subversion server became as easy as typing `git merge`.

Working Locally to Collaborating Online

When GitHub emerged, it allowed developers to create new repositories online and instantly sync their local, decentralized folders. It’s pretty magical to think that you, the developer, require almost no setup to make this happen; no server provisioning or anything of the sort. Everything went from a local experience to an online experience thanks to GitHub. You were suddenly able to share any repository with everyone in the world! Everyone that checked it out locally from GitHub would have all of that magic and a full copy of your project they would be able to work with. 

A lot of the work that used to be really tough, like managing different environments and merging between them, became simple. Every change made could have its own branch and you could share those branches online.

Interestingly enough, the decentralized characteristics of Git were actually what made it really easy to start adopting centralized platforms like GitHub, GitLab, or Bitbucket. Developers could start building conventions together around URLs and workflows. GitHub really introduced the possibility of defining Git as a cloud workflow tool. 

Enabling Worldwide Git Workflows 

Git quickly went from “just” a source code versioning tool to a central component for how we work together as developers to build and publish. Immediately after GitHub came into existence, developers started having this idea of instant repositories, where every hobby project or any bit of code could instantly become a Git repository, shared with the world to collaborate on. 

When GitHub, and then later GitLab and Bitbucket, introduced the concept of a “pull request” or “merge request,” it really set the world of online project collaboration in motion. The idea that every changeset can have its own URL that you can visit for code reviews meant the whole planet could collaborate together in an asynchronous manner.

This foundational change in collaboration also unleashed a lot of the patterns we’re seeing today around working together remotely and how we build distributed cultures. All of this would not have happened without these small pieces of magic that turned every folder into a repository where every changeset could be compared and pulled and pushed and synced globally.

How The Web Has Changed

You still might be thinking, “what does all this have to do with the web? How does Git actually map onto the web?”

If you think back to what the web looked like when SVN was popular, there was typically a server running Apache, maybe some PHP or Ruby on Rails, and maybe a DB. You could pull down the code locally, but the centralized server would always be sort of the single source of truth. Early web browsers acted more of a document viewer, requesting a copy of the full web document from the server. 

As a developer in the world of SVN, you would typically operate with very long-lived branches that are almost like their own repositories, one for each server. There is a production branch, a staging branch, and sometimes, a development branch. Development branches aren’t super common in SVN because handling merges and keeping different branches in sync is often really hard. 

It felt like you needed a server for each environment, even if it was running in the same SVN server. The web really mirrored that type of server setup. You would have your production environment, your staging environment, and sometimes our development environment, but it’s really hard to keep all those environments up to date and in sync.  Between all the system operations, SVN requires that language versions and libraries are all synced correctly and that the data is represented in each environment.

The Origins of Jamstack and Netlify

When Netlify first started out, it was really because Matt Biilmann and his team saw that GitHub and Git created this new world where you could collaborate in a different way. A world where the modern browser really started allowing you to treat the web as more of a self-standing application that you could push to end-users to run in their browsers.

Instead of having a big, monolithic application where the web UI, the database, and the application layer were all tied together, you could start thinking in terms of decoupling the web UI from the backend and business logic. You could start seeing the backend split into all these different APIs and services. While you could build some of these on your own, a lot of them are other people’s services. Some great examples include Twilio, Stripe, Contentful, Sanity.io, and Algolia. There are many more emerging services in the webspace, and these types of services are what get us to the term Jamstack.

The Jamstack and Static Sites

In modern web development, the whole stack has moved up a level, where you push the UI straight to the browser and then talk to all these different APIs and services, either as build-time or runtime systems. Some of the really early pioneers in this space were Jekyll and Ember, who helped pave the way for the rise of Jamstack. 

Jekyll is a static site generator, created by the founder of GitHub, Tom Preston-Werner, that shifted developers to the idea of moving away from long-running servers with a database and all the complexities of maintaining that setup. It moved developers towards the idea that each website could just be a Git repository with a build step. That build step would know how to take all the different source files in GitHub and output a ready-to-go website that runs statically and is eventually pushed to a CDN. You get amazing performance benefits and security characteristics with very little overhead.  

Ember was one of the pioneering single-page application frameworks. It looked at the browser as more of an operating system than a document viewer. The earliest versions of Ember used a Rails application, and Ember injected itself into the view layer and everything was still coupled together. Later versions of the Ember CLI really pioneered the idea of a completely decoupled web UI layer, separate from this back-end. This decoupling meant that making use of APIs was just an implementation detail and no longer an architecture-level decision. 

With today’s Jamstack approach, decoupled architectures leveraging APIs have really become the standard way to think about the web. Developers are no longer thinking about sites and apps as living inside templates in some monolithic application. Developers are now thinking about sites as code that can live in their own Git repository, following their own set of workflows and Git branching strategies. 

Being able to work locally is so important for Jamstack. The security of being able to work fully locally and then push the code up to a remote is really what inspired Netlify. Just clone a Git repository and you suddenly have a full local environment where you can work exactly with the same characteristics as your production website. You are decoupled from running servers and operating databases and so on. You can simply push your local work up and let Netlify worry about the building, publishing, and operation of modern websites and web applications.

Netlify started seeing collaboration workflows emerge that moved away from long-living production, staging, and dev environments and more towards pull requests and short-lived feature branches for each bug fix or each launch update. This drove Netlify to introduce the concept of ‘deploy previews’ back in 2016, with the thought that if you have a production site with a main URL, why not give every pull request its own deploy preview each with a unique URL that you can share and collaborate against?  

Watch this video clip to see Netlify CEO, Matt Biilmann give a full demonstration of the principles of local development and preview environments using Astro, a framework for building static websites. 

Next Generation of Jamstack Tools

Astro is a framework that Matt and his team at Netlify are really excited about. It allows you to do a lot of really smart things with modern component libraries at build time, defining precisely what you want to be JavaScript and dynamic, and only having those parts generate JavaScript at runtime. As a developer, you can freely pick which component libraries and which underlying UI framework you want to lean on.

You can quickly spin up a local development environment that completely mimics what you will later push to the cloud. Once it looks right and behaves as expected locally, you can push the code to your Git repo and create a pull request to fire off the needed build and deploy processes. 

Every single deployment has a unique identifier that will always stick around. When you publish a new version of your main site, you can see what’s in production, but you can also see the earlier versions of the main site. You can also see a content chart that identifies these specific versions, something that will always be available. These are always instantly accessible, with no sort of reloading needed, enabling the ability to roll code back or forward with no interruptions.

Git Built the Decentralized Web

Git is inherently decentralized. This conceptually allows you to work locally and instantly sync to a remote repository. It was the power of that decentralization that really allowed platforms like GitHub, GitLab, and Bitbucket to do so much more for collaborative workflows for developers than any of the earlier source control platforms. Instead of maintaining always-running Subversion servers, developers could jump straight to collaboration around their source code, building workflows together.

Netlify has applied all of those learnings from Git and the web to allow developers to rapidly build stateless, decoupled applications on a cloud platform. One that is not just a place for hosting your website, but one that’s really a workflow engine for your whole team to collaborate together faster, building better results for the web in a shorter time. That’s what makes the team at Netlify really excited. As the Jamstack evolves, everyone will be looking to Git and the patterns that emerge there to give us all clues of what comes next!