The old viastudio.com website launched nearly a decade ago atop of Wordpress - our go-to custom website development platform. 

But much has changed in those ten years in web development - and the goals we had for the

We wanted something that would create a unique, elegant, interesting user experience, delivered "scary fast"  - that was also easy to develop and maintain.

We love Wordpress - it has been and remains our go-to for custom website development. In order to achieve our user experience and development goals for the 

, we found that they aligned closely to the offerings of the JAMstack: static markup, delivered fast and enhanced with Javascript. This is commonly known as a "headless" content management system (CMS).

There are many JAMstack CMS options- including using Wordpress in a "headless" mode. But would that fit our needs?

Read How We Customized the Sanity CMS

The biggest challenge was moving our data from WordPress to Sanity, mainly our blog posts going back years. Fortunately, we were able to write a tool using PHP and Node to convert all of our WordPress data into a format that we could import into Sanity.

Read About Our How We Migrated Our Content

For a framework, we had two main options: Gatsby and Next. For me, the choice was easy. While Gatsby offers a theme and plugin ecosystem that resembles Wordpress’s in some ways, Next’s ability to dynamically work as a static site generator or a server side rendering framework on a page-by-page basis is a huge win. We had recently tested it out on our 

 and were immediately impressed. In the time since that project, Next has rolled out features like the incremental static regeneration which means that we can generate our featured case studies at build time, generate additional case studies at runtime when they are requested and also create server-rendered landing pages that can take advantage of A/B testing, cookies, etc.

Next also introduced API routes, which means instead of relying on a full custom server for things like form handling, we can just create a file at “api/form,” and Next will generate an API endpoint for us where we can run server-side code while doing everything else on the client.

Using a React framework also enabled us to take advantage of libraries like Framer Motion, which provides physics-based animations that give layout changes a more natural, playful feeling than duration-based CSS animations.

Vercel was our first choice for hosting because it supports Next out of the box as it is built by the same team. But more than that, they provide a great development experience. We have our project set up as a monorepo, for which Vercel recently rolled out support, which means our CMS and frontend are two separate packages that we host in one repository, and they each have their own project in Vercel with continuous integration through Github. Any time we open a PR for one of the projects, Vercel creates a preview deployment where we can view all the changes just how they will appear in production, and when we merge it into our “main” branch, a new production deployment is created. And if anything goes wrong, we can easily roll back to a previous deployment.

While we always work closely with the design team throughout the development process on a project, we often don’t get involved until fairly late in the design process. For this project, the goal was for design and development to collaborate on the design system and build it from the ground up, with an emphasis on componentization, since we knew we would be building the site with React.

Before design even got started, we got to work on the foundation of the design system. Inspired by the layout primitives in Andy Bell and Heydon Pickering’s Every Layout, we created React components for basic layouts that can be truly modular and intrinsically responsive, so we could use them all throughout the site. My favorite is The Switcher, which switches directly from a row to column layout with no breakpoint and no awkward in-between wrapping states with orphaned items.

To help with testing these primitives and collaborating with design, we built our components in 

, which enabled us to isolate components, visualize variants, and test responsiveness and accessibility. With this workflow we could develop layout primitives individually and share them with design; then design could construct layouts with these primitives in mind and hand back components, we could build those in Storybook and have them reviewed and incorporated into full page layouts, which we could then build in our Next.js app. This workflow brought design and development much more in sync and enabled a more efficient back-and-forth compared to a more standard hand-off where development begins after design has already completed the full page layouts.

The most exciting thing about our new site is what’s yet to come. Moving to a modern stack has opened the doors to all kinds of new ideas and experimentation. We’re only restricted by our imaginations.

We are extremely proud of what we were able to build and are excited to continue work on improving the site for our employees, clients and friends over the coming years.

PHP, Javascript & React

Frontend Development

Custom Dev

Developing the New via.studio

As a front-end developer in 2020, it is time that I fulfill the FEDeral mandate that I publish words regarding the JAMStack. If you follow too many developers on Twitter, it’s likely you’ve heard about the Next Big Thing in web development, but I’d like to put this trend (fad? movement?) into context to better understand what’s truly new about this approach and whether it’s worth using.

What even is a stack? You may have heard the term “full-stack developer” and know it refers to someone who does both frontend and backend work, but what is the actual stack? A stack — in the web development world — describes the combination of tools being used to host, serve and render a web project. Traditionally it has four components: an operating system, a server, a database and a programming or scripting language.

Let’s look at a couple notable stacks in recent history.

The LAMP Stack comprises Linux, Apache, MySQL and PHP. This is 

 stack of the early 2000s, and due to its ubiquity it will be around for many years to come. Notable LAMP sites — include Facebook (which has since migrated away), Wikipedia (technically using MariaDB rather than MysQL, for the record) and Yahoo (remember Yahoo?). Most importantly, though, is Wordpress, which powers something like thirty percent of the web and is almost certainly the biggest reason for the average person to build a LAMP stack site in 2020. Because of its history and popularity, though, there is a huge community of developers with LAMP knowledge, and it’s very easy to find affordable hosting from almost any provider.

As you may have noticed from the lack of an acronym, this is not a stack per se, but it is a highly opinionated web framework that became a popular alternative to the LAMP stack architecture in the mid-to-late 2000s. It is database agnostic, so you could still use a MySQL server, but Rails itself generates models, controllers, tests, database migrations, etc. and famously enforces the Rails method of application building. Github is a notable example of a Rails site. To this day, if a company is building a monolithic server-based website, it will likely choose either Rails or a framework it’s inspired, like Laravel for PHP.

Arguably the JAMstack of 2014, the MEAN Stack comprises MongoDB, Express.js, AngularJS, and Node.js. As is apparent from all those suffixes, this stack is JavaScript all the way down. The advent of Node.js, a Javascript environment that allows the language to be used anywhere, not just the browser, opened the door for a new era of web development where the full stack could be written in one language. Innovations were being made on the backend with NoSQL databases like Mongo, and the Javascript framework wars were beginning with Google’s Angular and Facebook’s React. (At the time, Angular had the edge. Since then, the frontend community has largely unified around React as the framework of choice, which contributed to the decline in popularity of the MEAN Stack.)

This is very much not a stack but feels worth mentioning as it’s a trend that feels transitional between the MEAN Stack and the JAMstack. With the popularity of React and its tool Create React App, as well as libraries like React Router, a client-side routing tool, many developers began creating sites that were completely client-side: a single index.html with a React application container that simulates a multi-page application without any server-calls or page changes. But while this is useful for interactive web applications like drawing tools, for more traditional websites it meant abandoning server benefits like SEO and resulted in extremely large Javascript bundle sizes.

From a stack perspective, the OS has been replaced by a CDN, the web server has been replaced by serverless functions, the database is optional, and JavaScript is the only required language. Like Ruby on Rails, this approach relies one one tool: the static site generator.

A static site generator is a tool that pre-renders web pages from a combination of markup and Javascript and will usually also perform code-splitting and other optimizations on the codebase. By pre-rendering the pages, the files can be served statically from CDNs rather than having to be rendered at runtime by a web server.

There are many tools available, depending on your language of choice. For true versatility, use something like 

 to take any type of markup — Markdown, Liquid, plain old HTML — and generate static pages without the need for a Javascript framework. Similar tools are 

For those who have a Javascript framework of choice, each big framework has its own choices for SSGs. For React, Gatsby is a popular choice for generating static pages from a React application and has an ecosystem of themes and plugins to choose from. NextJS can do the same but is notably more than just an SSG. On a page-by-page basis, it can either generate a static page or server-render it, providing extra options for those who want the speed and simplicity of static pages without sacrificing the benefits of server-rendering for pages that need it.

The core concept behind JAMstack is that almost any functionality you would need from a server has an API available already. Need CRUD for your MySQL database? Use 

 to generate a GraphQL endpoint for it. Authentication? Use 

. CMS? Well, that’s a whole other blog post, but 

. These are usually referred to as "headless" services, as they have been decoupled from the front-end.

For anything else, use Netlify’s serverless functions or NextJS’s API routes to spin up a little endpoint that handles what you need on the fly.

So should you start building all your sites with the JAMstack? As always, It Depends. Let’s take a look at some of the key decision points.

Static sites are extremely fast. Pages. Unfortunately, they can be very slow to build. If a site has thousands of pages, an SSG generally has to generate every single one of those pages every time the site is built. This can take a long time and severely hold up deployments. Fortunately, features like NextJS’s incremental static page regeneration allows for a hybrid approach where some pages can be generated at build time and the rest aren’t generated until they’re requested.

Some may also argue that static page speeds can be replicated by simply putting Cloudflare’s CDN in front of a Wordpress site, for example, but it’s nice that the speed is there out of the box rather than requiring the setup of a CDN or caching solution on top of the site build.

A common complaint about Wordpress is that they are vulnerable to hacking attempts. This is not so much a problem with Wordpress itself as it is with the fact so many websites are built with it. But the reality is that because JAMstack sites don’t have a server, there isn’t really anything to hack into. And because data fetching can be done in serverless functions, you can also avoid exposing API tokens like you might in a fully client-side site.

On the other hand, you have to put a lot of trust in the services you’re relying on, especially for e-commerce, so it’s important to vet all of your APIs and not rely on the lack of a server for solving all of your security problems.

This is arguably one of the largest benefits of the JAMstack. Static site generators generally have great build tools that enable features like fast refresh, code splitting and ready-made development environments. There is generally very little setup required to get a project started, and libraries, APIs and build tools can be added as needed, if needed. Frameworks like NextJS will handle things like Webpack and Babel configurations, routing, and enforcing best practices for front-end development, freeing up developers to Just Write Code. The only risk here is getting greedy and simply writing too much of it! It’s tempting to use every library out there and end up serving way too much Javascript. But when used responsibly, you can painlessly create great front-end experiences.

Monolithic approaches like Wordpress, Ruby on Rails or Laravel are still extremely useful for developers or teams with a need for fully custom backends or simply want to use a tried-and-true approach with endless resources and hosting options. For developers who want to quickly spin up fully custom marketing sites, ecommerce shops and blogs to deliver rich frontend experiences without needing to build custom servers, the JAMstack is an exciting new methodology that provides great experiences for both developers and users.

Websites

What's the JAMstack?

Web Design

Illustration

UX / UI

Celestial Bodies of the Past Present & Future

Branding

Non-profit Marketing

Graphic Design

Art Direction

Louisville Institute

While we have wide and varied development expertise and experience the core of our development skill is with PHP, Javascript, Vue and React, allowing us to maintain and develop new features for 80% of all websites on the Internet. That said, we regularly explore new and useful platforms to stay ahead of the ever-changing development curve.

PHP, Javascript & React

PHP, Javascript & React: Case Studies

01

Celestial Bodies of the Past Present & Future

02

Louisville Institute

PHP, Javascript & React: Blog Posts

Developing the New via.studio

What's the JAMstack?