Hey all, I have some exciting news. Nearly three months ago we announced we were working on something new. Today, we're breaking our silence and announcing a complete overhaul and re-launch of the Standard Library platform. This re-launch will be rolled out incrementally, beginning with our developer tools. However, over the next few weeks our announcements will touch everybody from backend API developers to spreadsheet pros, serverless pundits, code newbies, even "low-code" fanatics.

After speaking with thousands of folks ranging from students at hackathons to existing users and customers, IT professionals, Slack application builders and more, we identified a pretty significant opportunity to create a large amount of value for developers: specifically newbies. The heart of the problem we identified is that API development is largely inaccessible to a huge swath of professionals who could and should be able to make use of them on a daily basis. The modern API development stack is extremely intimidating — you don't just need to understand how to code, you need to understand frameworks, HTTP requests, hosting a server, and more.

We started out as a "serverless" company, but we believe "serverless" is but a small sliver of the overall opportunity ahead of us in this industry. If we can provide the right tools to new and emerging developers, we can change how people think about building software altogether. With this in mind, we have been busy rethinking Standard Library from the ground up. We will be presenting the changes to our platform and updates incrementally, starting with developers and moving up the stack as we go.

We're thrilled to kick off our series of announcements by introducing the world to FunctionScript, a language and specification for turning JavaScript functions into typed HTTP APIs. Some of what's included in this announcement can also be read directly on the FunctionScript GitHub repository.

FunctionScript Overview


FunctionScript is the primary specification underpinning our API development and integration platform. It allows JavaScript (Node.js) functions to be seamlessly exported as HTTP APIs by defining what the HTTP interface will look like and how it behaves - including type-safety mechanisms.

FunctionScript arose out of a need to introduce developers with little programming experience, but familiarity with JavaScript, to full-stack API development and best practices around defining and connecting HTTP application interfaces. For this reason, the goals of the language are significantly different than TypeScript. FunctionScript is intended to provide an easy introduction to API development for those of any skill level, while maintaining professional power and flexibility.

You can start building with FunctionScript immediately using Code on Standard Library, right in your web browser.

Quick Example of a FunctionScript API

The following is a real-world excerpt of an API that can be used to query a Spreadsheet like a Database. The underlying implementation has been hidden, but the parameters for the API can be seen.

* Select Rows from a Spreadsheet by querying it like a Database
* @param {string} spreadsheetId The id of the Spreadsheet.
* @param {string} range The A1 notation of the values to use as a table.
* @param {enum} bounds Specify the ending bounds of the table.
* @param {object} where A list of column values to filter by.
* @param {object} limit A limit representing the number of results to return
* @ {number} offset The offset of records to begin at
* @ {number} count The number of records to return, 0 will return all
* @returns {object} selectQueryResult
* @ {string} spreadsheetId
* @ {string} range
* @ {array} rows An array of objects corresponding to row values
module.exports = async (
  spreadsheetId = null,
  bounds = 'FIRST_EMPTY_ROW',
  where = {},
  limit = {offset: 0, count: 0},
) => {

  /* implementation-specific JavaScript */

  return {/* some data */};


It generates an API which accepts (and type checks against, following schemas):

  • spreadsheetId A string
  • range A string
  • bounds An enum, can be either "FIRST_EMPTY_ROW" or "FULL_RANGE"
  • where An object
  • limit An object that must contain:
    • limit.offset, a number
    • limit.count, a number

It will return an object:

  • selectQueryResult
    • selectQueryResult.spreadsheetId must be a string
    • selectQueryResult.range must be a string
    • selectQueryResult.rows must be an array

Why FunctionScript?

You can break down the reason for the development of FunctionScript into a few key points:

  • Modern developers and people being introduced to software development for the first time are often trying to build web-native scripts. It is exceedingly difficult to go from "zero to API" in less than a few hours, writing code is just the first step of many. We'd like it to be the first and only step.

  • No true standards around APIs have ever been built or enforced in a rigorous manner across the industry. Primarily, opinions around SOAP, REST and GraphQL requests have been built into frameworks and tools instead of a language specification, which has artificially inflated the cognitive overhead required to ship functional web-based software.

  • Companies like Stripe and Twilio which have built and enforced their own API development paradigms internally have unlocked massive developer audiences in short timeframes, indicating the power of treating web APIs as a first-class citizen of development.

  • Serverless computing, specifically the Function-as-a-Service model of web-based computation, has made API development significantly more accessible but has not brought us over the "last-mile" hump.

  • JavaScript, specifically Node.js, is an ideal target for API development standardization due to its accessibility (front-end and back-end), growth trajectory, and flexibility. Most new developers are introduced to JavaScript out of necessity.

  • As opposed to something like TypeScript, FunctionScript helps newer entrants to software development by extending JavaScript with very little overhead. It adds types around only the HTTP interface, leaving the majority of the language footprint untouched but strengthening the "weakest" and least predictable link in the development chain: user input.

With FunctionScript, it's our goal to develop a language specification for building APIs that automatically provides a number of necessary features without additional tooling:

  • Standardized API Calling Conventions (HTTP)
  • Type-Safety Mechanisms at the HTTP -> Code Interface
  • Automatically Generated API Documentation

FunctionScript: Roadmap

In the coming months we'll be doubling down on our investments in FunctionScript as the basis for the Standard Library Platform. You can expect to see:

  • A deeper integration to treat stdlib.com as the Standard Library for FunctionScript ("APIs"), available via the lib package on NPM
  • A growing, open-source, globally accessible Type System that will allow contributors to define their own custom types
  • Better, more sophisticated tooling for both newbies and professionals
  • An increased commitment to the development community

Much, Much More Coming

FunctionScript is just the first step in a complete overhaul of Standard Library's available tooling and the ecosystem we've been hard at work creating. Stay tuned for a heck of a lot more. It looks to be an exciting summer.

If you're as excited as we are, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library