Improving DX with Web Apps and Google Apps Script | Part 1

Introduction

There have never been more options when choosing your web application stack than there are today. One technology that often gets overlooked is Google Apps Script (GAS); I find an overwhelming majority of fellow developers have never heard of it. I’ve spent years working and playing with GAS, and while it isn’t suited for building all types of applications, internal enterprise apps for Google Workspace organizations is a great use case. Apps Script has built-in libraries for each of Workspace’s “primitives” like Google Sheets, Drive, Calendar, etc., providing you the easiest way to build applications and automations that integrate with these services.

While there are a few different categories of applications that can be built on this platform, I’d like to focus primarily on web apps. This is an area that leaves much to be desired and will have you wondering “Why did I ever choose to deploy my application to Google Apps Script.” Today, we’ll take a moment to give an overview of the developer challenges we face when building web apps with GAS, and define a vision for overcoming these obstacles.

Why Apps Script? Why Not?

Google itself refers to Apps Script as…

[!quote] ”…a rapid application development platform that makes it fast and easy to create business applications that integrate with Google Workspace.”

A different definition might point out that it is a serverless Javascript runtime powered by the V8 engine.

As a junior developer Apps Script made my heart flutter. It was a game-changer for me — it’s free, it abstracts away infrastructure, and handles basic authentication, all of which were areas I was quite unfamiliar with as a newbie. But because I worked at Google Workspace supported organizations, I now had the power to make basic yet impactful software quickly.

As I became a more senior developer, I started solving more complex issues than just automating spreadsheets with Apps Script. But as I tried to push the boundaries of what Google Apps Script could do, I started to see its shortcomings, especially when it came to web app development:

• How can I collaborate with others on a project efficiently?
• Can I develop locally?
• Can I manage my versions with Git?
• How do I test my code?
• What about third-party libraries and packages, can I install those?
• Will my application scale?

GAS tries to answer some of these questions, and disregards others completely. Often the answers it does have are also its intricacies and don’t represent the “typical way” or “best practice.” For example, Apps Script does have version control, but it ain’t Git. It does have support for libraries, but it ain’t NPM.

Having now developed full-stack web applications with Node, its clear that GAS falls short in providing the type of developer experience we are used to as a community. But this is why we are here today, to change this notion.

The Task at Hand

With a full glass of optimism I say in challenge lies opportunity. How can we make developing web applications for Google Apps Script feel akin to developing for NextJS? Our task then:

[!tip] Solve as many Google Apps Script environment challenges as possible, providing a framework for a drastically improved developer experience

Thanks for reading, and stay tuned for Part Two!