How It Works

Philosophy

At its heart, Greenwood is all about web standards. With the browser becoming such a powerful tool, especially with the advent of ECMAScript Modules (ESM) now having ubiquitious support in modern browsers, an entirely new workflow paradigm has emerged in which the browser can do more of the heavy lifting in our web dev workflows. In this way, less tooling and depedencies are needed to achieve excellent local development workflows as well as needing less overhead to maintain that stack.

Greenwood wants to take advantage of this oppourtunity to join in with other projects that are re-evaluating the landscape and thinking of a more unbundled world. One with less reliance on across the board bundling and transpilation, and one that just transforms on the fly only when needed. This paradigm lends itself really well to speedy local development workflows as well as benefiting end users who can be shipped more modern code. And for developers, now the code you write might actually look familiar while debugging in your browser!

CLI

To actually use Greenwood, everyone is required to install the CLI. The CLI is what powers all the workflows available by Greenwood and builds your project for local development and production builds. It is plugin based so that it can be extended by users to support additional workflows not intended to be maintained in core.

During development the CLI will:

• Instantaneously start a local web server with live reload.
• Process requests on the fly only for the content or code you need for a given page.
• Supports loading dependencies from node_modules using an importMap to avoid bundling.
• While Greenwood is ESM first, we have a plugin to tranform CommonJS into ESM (🤞)

For production builds:

• Combine all your code and dependencies into efficient modern bundles including minifying your JavaScript and CSS.
• Optimizes loading of JavaScript and CSS assets using web hints like preload and prefetch.
• All JavaScript (Web Components) are pre-rendered to static HTML (using puppeteer) for web standards templating with no runtime cost.
• Can output a standard static site (SSG), a multi-page application (MPA), or single-page application (SPA).
• Supports further optimization for additional hints like inlining or only statically pre-rendering JavaScript.

Lastly, Greenwood aims to be a low point of friction as part of a standard development workflow. In this way, there will be a balance between what tools and dependencies are considered core to Greenwood. We aim to avoid the common "meta" framework paradigm and instead want to hone in on a lean and efficient core with good extension points for longer term maintainability and technical design.

Plugins

The Greenwood CLI will aim to support development for all modern web standards and file types out of the box, in addition to markdown. Otherwise, additional languages and tools can be added to extend the core development experience using Greenwood's plugin system. In fact, Greenwood even maintains a few of its own to help you get started! In this way the Greenwood team aims to keep a strong focus on a core experience that everyone will benefit from no matter what their building, while allowing a DIY / BYOP (bring your own plugin) workflow that anyone can use.

Browser Support

For when transpilation is desired (Babel, PostCSS), Greenwood recommends using an "evergreen build" approach that ensures that the code delivered to users is as modern as modern as possible, with the least amount of processing and tranformations applied. Greenwood has two plugins that already support taking advantage of the two amazing tools that makes this all possible; Browserslist and caniuse.com.

• Babel is a compiler for JavaScript that transforms modern JavaScript down to a specific "target" of JavaScript. For example, source code can be written using 2018+ syntax, but transformed such that browsers that don't support that syntax can still run that JavaScript.
• PostCSS, much like Babel is a compiler, but for CSS! Just as with Babel, we can use modern CSS features without a transpilation process from a higher level version of CSS (LESS, SASS). CSS has finally arrived in modern web applications! ✨

Using the above tools and leveraging their respective env presets available, essentially, Browserlist will query CanIUse data to determine, based on the browser query provided, what features are / aren't needed for transpilation. This in turn allows Babel and PostCSS to intelligenty transpile only what's needed for the features that are missing from the browser you are targatting, thus ensuring an "evergreen" experience for users and developers. Nice. 😎

So for example, a .browserslistrc that looks like this:

> 1%
not op_mini all
not ie 11

When run against the browserslist, will in turn not transpile any modern code that all these browser support.

$ npx browserslist
and_chr 67
and_uc 11.8
chrome 67
edge 17
firefox 61
ios_saf 11.3-11.4
ios_saf 11.0-11.2
safari 11.1