I'm incredibly excited to announce an app I've been working on for a while, Roughpad: a productivity tool for quick and easy notes.

Roughpad is great for jotting down small and unstructured bits of information. So far users have been using Roughpad for meeting notes, code snippets, todo lists, journaling, twitter thread drafts, jotting down phone numbers, and more.

Tools like Notion, Quip, and Google Docs encourage structure with folders, document titles, and document formatting options. While structure is great for larger documents, it is often overkill for rough notes or jotting things down. Roughpad doesn't force you to figure out what folder you should put a note into, nor does it encourage titling or formatting. Just create a new tab and start typing.

Features

Global Shortcut

Roughpad adds a global shortcut which allows you to press Command + Shift + D to focus Roughpad.

Tabs and Shortcuts

Markdown

Roughpad supports markdown, which makes code snippets, lists, checkboxes, and other tasks easy.

Command Palette and Search

To make Roughpad even faster to use,  it features a command palette for quick searches across all your notes. Open and close the command palette with Command + P.

Local First

Roughpad's notes are local first, meaning they're stored on your computer. This makes Roughpad incredibly fast and secure.

Try it out!

What is Alfred? TL;DR

Alfred is toolchain for JavaScript that aims to:

• Provide tools that work out of the box
• Simplify the process of using JavaScript tooling
• Make JavaScript tooling more reliable
• Serve as an alternative for boilerplates/"starter kits"

Here's an example of how Alfred is be used:

# Create a new Alfred project
alfred new my-react-app --project app.browser
cd my-react-app

# Add react support to your project
alfred learn @alfred/skill-react

# Run commands
alfred run start
alfred run build
alfred run lint

# Deploying to Github Pages
alfred learn @alfred/skill-github-pages
alfred run deploy

To get a better understand what Alfred is trying solve, its improtant to understand the current state of JavaScript tooling.

The State of Tooling

Maintaining over 200 open source JavaScript projects for the last 6 years has exposed me to the best and worst parts of JavaScript infrastructure. JavaScript infrastructure shines when it comes to flexibility. They make few assumptions about the user of the tools, but they don't assume you'll be using other tools. Making no assumptions is nice because it allows users to use whatever tools they want. Infrastructure usually doesn't come with integration for other tools out of the box support so integration is usually added by 3rd party plugins. This model for infrastructure is convenient because it allows developers to write plugins which extend the functionality of the tools they use, therefore allowing the tools to be used in a much wider range of scenarios than anticipated by maintainers. The downside of this customizability is that the tools usually don’t work out of the box. This comes at a huge cost to the user experience of beginners who have never used that tool before.

The JS ecosystem responds to this complexity by creating ‘boilerplates’, or ‘starter kits’, which are essentially template projects that have their infrastructure preconfigured for the tools the template project supports. For example, electron-react-boilerplate is a boilerplate that configures electron, react, eslint, webpack, and jest. Boilerplates solve the out-of-the-box problem but they sacrifice extensibility because they don’t expect users to change the tools they come with or even change the configurations of those tools.

Alfred proposes a new solution that allows each tool to configure itself with respect to other tools. To better understand Alfred’s solution, it is important to dive deeper into the current drawbacks of JS infrastructure.

Tooling Drawbacks

JS Tooling is Brittle

When trying new tools, newcomers often spend a significant amount of time configuring tools. The difficulty of configuring a tool or library can discourage the user from using the it alltogether. Even users of widely adopted libraries and tools tend to experience issues related to configuration. The tweet below describes the situation well:

"Looking at the issues on storybooks/storybook:

• 2,479 total issues
• 732 mention "webpack" (30%)
• 428 mention "babel" (17%)

That's crazy! Other keywords that come up that often would be treated as requiring architectural change, but those are just for configuration."

It's a little mind-boggling how many issues are purely for dealing with Babel or Webpack configuration. And those are by far some of the most frustrating issues to debug when you do run into them. So much time wasted. Makes you really understand the "zero config" movement.

Incorrect, Suboptimal Infrastructure

One of the great strengths of JS tooling is its customizability. This customizability allows JS tools to be used in a wide different use cases. But leaving the configuration of tools up to users allows for the possibility of misconfiguring tools, which often results in tools that are used sub-optimally or even incorrectly. For example, it is common for libraries to ship with polyfills or compiled code. This is considered an anti pattern because this makes it harder for applications to optimize apps which use the libraries (tree shaking) and it increases the bundle sizes of apps that use the libraries.

The Solution

Alfred aims to solve these problems by enabling tools to configure themselves out of the box. Each tool should know how to configure itself so that it can be compatible with other tools the user is using. Alfred achieves this 'out of the box' solution by generating minimal configurations for the user's tools. Advanced users can override or extend generated configurations. Alfred tests each combination of tools before publishing new versions.

Skills

A skill is an abstraction over a tool that allows it to configure itself with respect to other tools. For example, a babel ‘skill’ which wants to add react support would add the babel-preset-react preset to its config if the user is using the react skill.

Here is an example of a skill:

export default {
  name: "eslint",
  devDependencies: {
    "eslint-config-airbnb": "18.0.0"
  },
  configs: [
    {
      // Config's filename
      filename: ".eslintrc.js",
      // The base eslint config
      config: {
        plugins: ["eslint-plugin-prettier"]
      }
    }
  ],
  transforms: {
    // Make eslint config compatible with react
    react(eslintSkill) {
      return eslintSkill
        .extendConfig("eslint", {
          plugins: ["eslint-plugin-react"]
        })
        .addDevDeps({
          "eslint-plugin-react": "7.18.0"
        });
    }
  }
};

For more on skills, see the skills section of the docs.

Alfred comes with skills out of the box but it also allows users to use 3rd party skills as well. Users can customize configs through Alfred's configs:

Here is an example of what an Alfred config looks like:

// package.json
{
  // ...
  "alfred": {
    "skills": [
      [
        "@alfred/skill-eslint",
		// A which extends the generated config
        {
          "extends": ["eslint-config-airbnb"],
          "rules": {
            "no-console": "off"
		  }
        }
      ]
    ]
  }
}

Entrypoints

Alfred formalizes the concept of entrypoints, which are files that determine the project type and platform a project will run on. For example, the entrypoint src/app.browser.js will be built as a browser app, app being the project type and 'browser' being the platform. Entrypoints determine which skills should be used to act on the entrypoint for a specific subcommand. Running the build subcommand on a project that has a ./src/lib.browser.js entrypoint should build the entrypoint with rollup, a bundler that is optimal for libraries.

Skills can declare which project types, platforms, and environments they support. Here's how the parcel skill defines which environments, platforms, and projects it supports:

const supports = {
  envs: ["production", "development", "test"],
  platforms: ["browser", "node"],
  projects: ["lib"]
};

export default {
  name: "rollup",
  tasks: [
    ["@alfred/task-build", { supports }],
    ["@alfred/task-start", { supports }]
  ],
  // ...
};

Tasks

Tasks determine which skill should be used when a certain subcommand is called. For example, when alfred run build is called, either the parcel, webpack, or rollup skill could be used. They also specify how skills are called and provide information about the task. Below is an example of a task:

// @alfred/task-build
export default {
  subcommand: "build",
  description: "Build, optimize, and bundle assets in your app",
  runForEachTarget: true,
  resolveSkill(skills, target) {
    // return whichever skill you want to resolve...
  }
};

Skills can then implement certain tasks:

export default {
  name: "parcel",
  tasks: ["@alfred/task-build", "@alfred/task-start"],
  // ...
};

Tasks allow for skills to be interchanged while maintaining a consistent developer workflow. For example, all skills that lint a user’s project will use the @alfred/task-lint task so all of these skills are invoked through the lint subcommand that the task registers.

Alfred comes with the following tasks built-in: build, start, lint, format, and test.

Files and Directories

Sometimes, adding or changing configuration may not be enough to add support for a certain tool or library. Redux, for example, requires configureStore.js, root.js, and other files. To allow skills to fully add out of the box support for tools they wrap, Alfred allows them to define files and directories which are added to the user's project. Similar to configs, files can also be modified by skill transforms. Below is an example of how the redux skill transforms the configureStore.prod.js file to be compatible with typescript:

export default {
  name: "redux",
  files: [
    {
      alias: "configureStore.prod",
      src: path.join(__dirname, "../boilerplate/store/configureStore.prod.js"),
      dest: "src/store/configureStore.prod.js"
    }
    // ...
  ],
  transforms: {
    typescript(skill) {
      skill.files
        .get("configureStore.prod")
        .rename("configureStore.prod.ts")
        .applyDiff(
`@@ -12 +12 @@
-function configureStore(initialState) {
-  return createStore(rootReducer, initialState, enhancer);
+function configureStore(initialState?: State): Store {
+  return createStore(rootReducer, initialState, enhancer);`
        );
      return skill;
    }
  }
};

Files can be transformed by either applying diffs to files or by replacing strings that match a regular expression.

Getting Started with Alfred

To get started with alfred,

# Create a new project
npx alfred new my-project
cd my-project

# Build your project
npx alfred run build

Here is an example of what an Alfred config looks like:

// package.json
{
  // ...
  "alfred": {
    // Extend a shared Alfred config
    "extends": "alfred-config-web-app",
    // 3rd party skills the project uses
    "skills": ["@alfred/skill-react"],
    // The package manager to be used
    "npmClient": "yarn"
  }
}

For more details on how to use Alfred, see the docs.

Directory Structure

The following is an example of the directory structure of an Alfred browser app project:

my-project/
├── .gitignore
├── README.md
├── src/
│   └── app.browser.js
├── targets/
│   └── app.browser.dev/
│        └── index.js
│   └── app.browser.prod/
│        └── index.js
└── package.json

Exciting Opportunities

Alfred creates some exciting new oppertunities for workflows and tooling integration. Expect to see the oppertunities below in future releases!

Entrypoint specific commands

Sometimes, it is useful to run subcommands for a specific entrypoint. Alfred will allow user's to do so through the CLI:

# Building a specific entrypoint
alfred entrypoint lib.browser run build

# Building all app entrypoints
alfred entrypoint app.* run build

This will make maintaining apps with multiple entrypoints much easier.

Publishing/Deploying with Alfred

Alfred integration with publishing and deploying can significantly simplify the deployment process for many web developers. Ideally, developers can deploy to their platform of choice just by learning a skill:

# Publishing a specific entrypoint
# By default, libs and node apps are published to npm registry
alfred entrypoint lib.browser run publish

# Publish all entrypoints
alfred run publish

# Publishing all app entrypoints
alfred entrypoint app.* run publish

# Publish app to GitHub Pages
alfred learn @alfred/skill-github-pages
alfred entrypoint app.browser run publish

# Publish app to Now
alfred learn @alfred/skill-now
alfred entrypoints app.browser app.node run publish

Documentation Tooling

It can be said that one of the most undervalued pieces of JS tooling is its documentation tooling. There is much to be learned from the success of docs.rs, the standard for documentation generation for Rust. A JS equivalent of docs.rs might be of much use to the JS ecosystem.

Plugins for Alfred

It is very common for JS tools to allow plugins to add extra functionality to tools. Take, for example, a simple rollup plugin that prints the sizes of chunks after bundling:

A useful plugin indeed! But if we want to use this plugin across all our bundlers of all our entrypoints (parcel or webpack if you have an app entrypoint) we would need to create a new plugin for both webpack and parcel.

Alfred can reduce the duplication of plugins with skills and tasks. Skills can return metadata from the tools they wrap. Tasks can provide an interface which skills should conform their metadata responses to.

Here is an example of what a task may look like:

// @alfred/task-build
export default {
  subcommand: "build",
  description: "Build, optimize, and bundle assets in your app",
  runForEachTarget: true,
  resolveSkill(skills, target) {
    // return whichever skill you want to resolve...
  },
  metadataInterface: {
    ast: type.object,
    output: type.array.of(type.string)
  }
};

Below is an example of a skill that takes rollup's AST and return an object that conforms to the interface defined by the task.

// @alfred/skill-rollup
export default {
  name: "rollup",
  tasks: ["@alfred/task-build"],
  // ...
  metadata(rollupAst) {
    // ...
    return {
      ast: {...},
      outputs: [...]
    };
  }
};

A plugin can now receive this metadata from any skill that uses the build task:

// @alfred/plugin-size
export default {
  name: "size",
  hooks: {
    afterBuild({ metadata }) {
      const outputSizes =
        metadata.outputs.map(output =>
          `${output.name} size: ${output.size}`
        );
      console.log(outputSizes);
    }
  }
}

Shared ASTs

Sharing AST's between tools is an interesting area for investigation that can provide significantly improve the quality of JS tooling. This can improve the performance and developer experience of all JS tooling. Rome is already doing this!

Acknowledgements

Prior Art

• Cargo
• NPM, Yarn
• Yeoman
• Rome
• create-react-app
• react-boilerplate, electron-react-boilerplate, and many many other boilerplates

Inspiration

• parcel
• docker
• elm
• Cargo
• Yarn
• webpack-merge

Ensuring browser compatibility of apps is an ongoing concern among browser developers. It is common for web apps to be required to run on multiple browsers.

Understanding the Problem

It is very common for businesses to require that their app works on certain browsers. Facebook, for example, requires that a version of their web app should still work on Internet Explorer, a browser known for its gaping holes in browser API support. Enforcing this requirement is met by testing the app on different browsers but doing so usually introduces development overhead because it requires tests to be written and time for the tests to be run.

In place of tests, it is common for developers to reference compatibility tables, which are tables which list all the browsers a given API is supported in. However many of these tables are either incomplete or non-existent for certain APIs because they are manually filled in by developers, which is not easy. There are roughly 10K APIs and 131 variants of browsers, which amounts to 1,310,000 API compatibility entries that must be filled in. Compatibility records are maintained by two projects: Mozilla Developer Network (MDN) and caniuse.

MDN

Examples of unknown API records:

caniuse

caniuse is the most complete collection of these API compatibility records. But this solution is difficult to scale. With a limited amount of developers with limited time and resources, it is difficult to maintain a table with thousands of records.

As you can see, caniuse has over 1K issues and only one active maintainer to address them.

Furthermore, developers manually checking a compatibility table isn't a scalable solution for handling browser compatibility inconsistencies. caniuse provides no scalable solution for integrating with existing static analysis (i.e. code analysis) tools.

proposed solution: compat-db

compat-db is a project that automates the generation of compatibility records of APIs. It takes APIs as input and return compatibility records as output. To generate all the browser compatibility records, it is given all the standard browser APIs as input and it returns all the corresponding compatibility records.

Input: WebIDL

APIs are defined with a special language called WebIDL. API authors write the specification for APIs in the form of WebIDL, a language which specifies the interface of the API. Here's an example of WebIDL corresponding to the TextEncoder.encodeInto API:

dictionary TextEncoderEncodeIntoResult {
  unsigned long long read;
  unsigned long long written;
};

[Constructor]
interface TextEncoder {
  TextEncoderEncodeIntoResult encodeInto(USVString source, Uint8Array destination);
};

JavaScript tests are generated from the WebIDL.

Here is a simplified version of the corresponding compatibility tests that are generated from the TextEncoder.encodeInto API WebIDL example above:

if (typeof TextEncoder === 'undefined') {
  return false;
}

if (typeof TextEncoder.encodeInto === 'undefined') {
  return false;
}

if (typeof TextEncoder.encodeInto === 'function') {
  return false;
}

return true;

Determining Compatibility: Browser VMs

The next step is to run these generated compatibility tests in each browser. This is done by dispatching the tests to run in remote browsers where it is then evaluated. These browsers are hosted by a number of services, including browserstack and saucelabs. The results of the evaluated tests are then returned as responses to compat-db.

Performance Considerations

Naive implementation

The naive implementation would need to run tests for every version of every browser for every API in order to build a complete compatibility table.

for (const API of APIs) {
  for (const browser of browsers) {
    for (const version of browser.versions) {
      dispatchCompatTest(API, version);
    }
  }
}

This algorithm is an O(m * n) algorithm, where m is the number of APIs that are tested and n is the total number of browser versions that are tested.

There are 10K API's, and 131 versions of all the browsers:

Summing the total number of browser versions, we get 131 total versions.

The naive method would require $$10,000*131=1,310,000$$ tests 😱.

Optimizations

We can observe some certain browser heuristics to reduce the number of tests required to build a complete compatibility table. Once a browser implements an API, it cannot be taken out. This is a general principle web browsers follow because they can't "break the web". If a browser yanks a previously supported API then it will break pages that depended on that API existing in that browser. APIs are deprecated but never removed (only in some extremely rare scenarios i.e. SharedArrayBuffer).

Using this heuristic, we run a modification that finds the first version of a browser that supports a given API. The algorithm almost identical to binary search: look at the sorted versions of any given browser.

Consider the example sorted versions of a browser:

[12, 14, 16, 18, 22]

If we execute compatibility tests against the "middle" version (16 in this example) of the browser and they return false then we know all the previous versions of that browser must not have had that API implemented before. So we look at the versions "right" of the "middle" version: [18, 22] and then recursively perform the previous operation.

This can be done in O(m * log n) time for one browser where n is the number of versions of a browser and m is the number of APIs that need to be tested.

When determining the runtime for all the browers we need to make some changes. First we'll create a list of all the browser versions and then sum over it:

$$ \sum_{i=0}^{|x|} m * log x_i = m * \sum_{i=0}^{|x|} log x_i = 64,393$$

This brings down our initial number of tests from 1,310,000 to 64,393, a 95% drop in the number of tests needed to determine the browser compatibility of all APIs.

Use cases for compat-db

The future of compat-db includes integration with static analysis tools, like the following projects.

Static Analysis

eslint-plugin-compat, an ESLint plugin which lints the compatibility of JavaScript code. Here's an example of it in use:

compat-db will serve as the source which contains the compatibility records which eslint-plugin-compat refers to for API compatibility lookups.

Automatically Including Polyfills and Shims

Polyfills and shims are pieces of code which implement an API if it is not supported by the runtime. For example, if chrome does not support the fetch API then a polyfill for it would implement that function using native JavaScript.

At the time of writing, there is no way of automatically including the necessary polyfills or shims for a codebase given a list of target browsers. Library authors include polyfills for their libraries with the intention of simplifying the process of using libraries. This way, library consumers do not have to worry about including polyfills themselves. However, this comes at the cost of bloating sizes of apps and libraries which consume these libraries.

An ideal solution, now made possible with compat-db, is iterating through every API used, check compat-db to see if it is supported by the browsers the user is targeting, and then append the polyfills to the user's build. This solution, which should be used only in the context of apps as opposed to libraries, ensures that only the necessary polyfills and shims are included in the compiled output of apps.

The Project

compat-db is hosted on GitHub. I'm actively looking for contributors so let me know if you're interested in contributing! There's some work that needs to be done to make compat-db production ready.

An ongoing list of my heroes (in no order)

I believe everyone has something to teach me. This is a list of people who have made the most significant influence on me.

• Martin Luther King
• Richard Feynmann
• Carl Sagan
• My brother
• Henry David Thoreau
• Yan Zhang (One of my discrete math teachers)
• Jean-Paul Sartre
• Steve Jobs
• Christy Hallford (my English teacher)
• Naval Ravikant
• Paul Graham

I have recently open sourced Falcon.

What is Falcon?

Falcon is a modern, cross-platform SQLite database client. It is in a very experimental stages at the moment.

Why another database client?

1. A lot of databases feel dated since they don't support modern features
2. Bad performance, use legacy java cross-platform gui's
3. Platform dependent. The best clients are only for macOS
4. Most clients are not extensible/pluggable
5. Most clients are specific to a certain database
6. Current clients only show data. They don't help explain what it means

Future

1. Add support for other database clients
   Adding support for MSSQL, MYSQL, PostgreSQL, Mongo, and other clients will be a high priority after pushing an initial stable version of the client.

2. Add plugin support
   Editors such as VSCode, Atom, and Hyper have seen huge successes because they allow developers to install plugins which can be written in Node. This allows users more fine grained control over their own experience and ability.

This is an ongoing blog post that lists project ideas I am thinking of working on. If you are interested on working on any one of these ideas with me, feel free to reach out to me!

Legend

• ☕️: Small/Easy Project
• ☕️☕️☕️: Large/Difficult Project
• ✅: MVP Shipped
• 🔨: In Progress
• ❌: Not Yet Started

🔨 ☕️☕️☕️ any-cast

• Cast audio or video to any device with one API

🔨 ☕️☕️☕️ compat-db

• An automated browser compatibility database
• Runs type checks on browser's to determine if API's are defined
• Another way is by running w3c tests on each browser and checking if they pass.
• Use the Microsoft API Catalog for API's to be type-checked
• Determine if an API can be polyfilled which API's can be polyfilled
  • This can be done by adding a property of polyfillable: bool to each spec record

VR Perspective Seat Experiment ❌ ☕️☕️☕️☕️

• What
  • Take Codrops' Perspective Seat Preview and create a VR experience out of it
  • Possible integrate this experience into popcorn time desktop
• How:
  • Experiment with WebVR to seem if a WebVR implementation is possible

Pagerank ❌ ☕️☕️☕️☕️

Graph Drawer ❌ ☕️☕️

• What:
  • A general purpose API that can draw graphs. This is intended to be used by falcon
  • Allow drawing graphs like those in game engines
  • 
  • 
  • 

Study Rooms ❌ ☕️☕️☕️☕️☕️☕️

• What:
  • Mimic great study environments
  • Play sounds that match that environment
  • The app is meant to be played on a screen (laptop or monitor) while they study
    • This is similar to a lot of asmr (asmr rooms and others)
  • Sounds
    • Merging sounds together like Noizio
    • Example Sounds
      • Chatter sounds
      • Rain
      • Thunder
      • Space
      • Cabin forest
      • Cabin snow
      • Etc...
  • Environments
    • Will be from many different places, some fictional and some real
    • Will have people moving around in them.
    • The music and sounds of the environments should match real life
      • Example: A coffee shop would have jazz playing in the backround
    • The goal is to be as realistic as possible with the environments
    • The time of day in real life should match the time in the environment
    • Examples of environments
      • Stormy cathedral
      • Coffee shops
      • Lord of the rings bar
      • Libraries
      • Small cabin
      • Writer's Refuge
• How:
  • Models
    • Take models from sketchfab
    • Also generate own models
  • Sound
    • Go to similar places in real life and record those environments
    • Sounds can be taken from soundcloud or youtube (using their api's)
  • Graphics Performance
    • This will be difficult on low end laptops
    • We can detect if a laptop is
    • For low end
  • Infra:
    • App will be served over github pages
    • Will use https
    • Will use service worker to cache textures

❌ ☕️☕️☕️☕️☕️☕️ Extensible JS Type Checker

Inspired by:

• https://cstheory.stackexchange.com/questions/22117/language-with-extensible-type-system
• Create a type system for JS and allow plugins to extend it

❌ warn-non-ui-critical

• iOS and Android native platforms, for example, restrict (by default) the usage of any APIs not critical to UI manipulation on the main thread. (from tasklet)
• Make a static analyzer that can warn when using APIs not critical for UI

❌ ☕️☕️ pretty-print-errors

• Should have browser console fallback
• Source map support
• Automatic script blackboxing
• Path Error.prototype.toString
• Use project root as root of errors: Error in 'project-root/foo/bar.js'
• Lower opacity of code that does not error
• Show line numbers
• Highlight rows with errors
• Use like babel-polyfill, babel-node -r pretty-print-errors some.js

Inspired by:

• eslint-formatter-pretty
• Laravel 'Woops' Errors demo
• pretty-error
• better-exceptions
• clarify

@emberjs I'm loving the new error messages in Ember 2.15! pic.twitter.com/TYrtPLlOKc

— Jordan Vincent (@jordan_vinc) September 23, 2017

Making my stack traces a little more readable with a quick regex and some CSS line height pic.twitter.com/AvivrDHIAt

— Wes Bos (@wesbos) February 15, 2017

Stacktrace Parsing Library

• https://github.com/felixge/node-stack-trace
• https://github.com/stacktracejs/stacktrace.js
• https://www.npmjs.com/package/error-stack-parser

Some terminal highlighting libraries

• https://medium.com/@gauntface/pretty-printing-d80639fb8881
• https://github.com/chalk/chalk
• https://github.com/thlorenz/cardinal
• https://github.com/mikaelbr/marked-terminal
• https://github.com/dtao/console-highlight
• https://github.com/felixfbecker/cli-highlight
• https://github.com/eush77/v8-print-code-highlighter (not maintained)

const config = {
  blackbox: bool = true,
  root: string = __dirname,
  lineNumbers: bool = true,
  previousLinesCount: number = 5
}

Research

• Elm stack trace errors

❌ ☕️☕️ stylelint-plugin-compat

• Lint css style compatibility by using caniuse db
• Check if using autoprefixer. If not, warn if missing prefix

❌ ☕️☕️☕️ compat-webpack-plugin

• Automatically polyfill browser API's (ex. fetch()) by using browserlist or babel-env-preset config
• Use polyfills from inexorabletash/polyfill
• Base off zloirock/core-js
• Automatically include polyfills based on browserslist targets. Find necessary polyfills from eslint-plugin-compat
• Allow for dynamically requiring polyfills to reduce build size. (ex. if 90% of target browsers support feature, force network request instead of polyfill)
• Borrow from https://github.com/Financial-Times/polyfill-service

❌ ☕️☕️☕️ eslint-plugin-dom

• Lint dom API performance, warn of sync layout calc, error on forced reflow
• Paul Irish as an eslint rule?

❌ ☕️☕️ eslint-plugin-deps

• Warn on installation/usage of unstable dependency. Determine dependency quality
• Use npm-check to determine is depinstalled
• Use the new "npm audit"

❌ ☕️ compat-check

cli tool used to analyze the build to see if any deprecated or unsupported API's are being used

❌ ☕️☕️ webpack-strip-polyfills

Detect all the supported browsers and remove all the polyfills which are included but will never be used by the targets

❌ ☕️☕️☕️ Alfred Runtime

• A linter that can collect runtime errors
• Examples: why-did-you-update: Instead of logging warnings to the console, what if errors could be sent to a server which collects runtime errors and displays them in an interface for the user to see?

❌ ☕️☕️☕️ Alfred Runner

• Given a list of routes, automate a nightmare/selenium instance to traverse the routes, simulate action, and detect performance weak points/fps drops/memory leaks
• Interaction to Simulate
  • Clicks
  • Route navigation

❌ ☕️☕️☕️☕️☕️☕️ Alfred Linter

• An alternative to ESLint that suggests solutions to errors
• Similar to Cargo

- a minifier that does constant folding and inlining
- a compiler transforms that don't rely on order
- a compiler that uses an immutable AST to perform transforms, with accurate scope tracking
- a linter that gives me suggestions on how to fix my code
- ...

— Sebastian McKenzie (@sebmck) November 16, 2018

✅ ☕️☕️ eslint-plugin-compat

• Allow css-in-js to be linted for CSS compat
• Integration with aphrodite, styled-components, react-style, radium, JSS, others
• Each will likely need its own parser. Should be able to detect which css-in-js framework is being used
• Integration with CSS preprocessors (ex. autoprefixer)
• Determine if an API can be polyfilled which API's can be polyfilled
  • This can be done by adding a property of polyfillable: bool to each spec record
• If compat-webpack-plugin detected, fail on only non-polyfillable API's
• Why CSS in JS

Now, this is a configuration that makes sense to me. Specify browsers once, let Babel and Autoprefixer do the work. https://t.co/KgOtIyw0wH pic.twitter.com/vVPeECXGY3

— Dan Abramov (@dan_abramov) December 12, 2016

A big advantage of CSS in JS(X): One language (JS), not three (JS, HTML, CSS).
One linter. One code style. One type system. One test system.

— Guillermo Rauch (@rauchg) November 26, 2016

✅ ☕️ FreeSound Node Client Library

• https://freesound.org/docs/api/
• Current one is utter trash
• Maybe if time permits, we can redo the web interface for https://freesound.org because it's open source

✅ ☕️☕️ babel-plugin-fail-explicit

Force javascript to be stricter in development environment

Coercion and silent failure are dead. Long live usable JavaScript

• Fail on Coercion
• Fail on array out of bounds access
• Fail on non-existent property access

Get the values of functions:

• https://github.com/power-assert-js/power-assert

Inspiration

• wat js talk

webgl-specs ✅ ☕️☕️

• What:
  • Detect the specs of a graphics card using web apis
• How:
  • Extract source from webglreport and create an API from it

Modeling Growth of Projects ✅ ☕️☕️

• Consider using SIR Model
• Variables
  • Initial stars (because we can't get view metrics, assume star count prop. to view count)
  • code quality
  • tags
  • language
    • size of language ecosystem

✅ ☕️ ast-metadata-inferer

• Generate a large collection of the ast node types of different API's

🔨 ☕️☕️☕️ compat-test-runner

• Given compat-db records, return if each record is supported in a specific browser
• Run tests in every browser
  • How: use testcafe and download binaries for each browser

xwing ✅ ☕️☕️

• What:
  • Emulate the trench run scene from star wars. The game involves avoiding obstacles in the trench and avoiding fire from tie fighters
• How:
  • Take models from sketchfab
  • Use three.js to build a small game
  • Should have sound affects
  • Adapt game textures to device. Use lower quality resources for low powered devices (laptops)
• Resources:
  • https://sketchfab.com/models/94b745226cc64333becfdad566dbdce3
  • https://sketchfab.com/amilajack/likes

The web environment has seen many advancements within the last few years. We've seen advancements in rendering (react), significant improvements in serving assets quickly (service worker), and near native performance (WebAssembly). The web has seen improvements at such a rapid pace and Electron is what is brining these improvements to cross-platform desktop apps. It was only two years ago that electron had really started catching on. Electron is a derivative of the chromium project that embeds the node.js runtime.

Bare-bones Electron

Out of the box, Electron doesn't do much other than provide the API's. And because Electron is solely a library, does not have the responsibility of setting up infrastructure around electron apps. Infrastructure decisions are let to the developer. But it is rarely the case that new developers to electron know the ins and outs of Electron specific infrastructure.

Enter electron-react-boilerplate

Enter electron-react-boilerplate (ERB). ERB provides solutions for the following infrastructure around Electron apps:

• Auto Updates: Allowing developers to publish updates to their apps
• Asset Optimization: Optimizing JS, CSS, images, and other assets
• DevTools Integration: Support for React, Redux, and Devtron DevTools
• Packaging: Out of the box support for packaging apps to Windows, Mac, and Linux
• Compilation: Out of the box support for Babel and Webpack
• Code Analysis: ESLint and Flow integration out of the box (TypeScript support planned)
• Hot Module Replacement: Saved changes to app are reflected instantaneously without refreshing the app
• State Management and Routing:  Comes with Redux and react-router support out of the box

Target Audience

There is a balancing act when it comes to creating a boilerplate: adding too many features and configurations would intimidate newcomers and too little would not fulfill the demands of more mature developers with requirements.

NewComers

We think ERB will add value to developers who are new to the Electron ecosystem and are trying to quickly scaffold Electron apps without worrying about the infrastructure. The base of the app is kept simple in order to ease the entry of newcomers.

Mature Electron Devs

While the base is kept simple, we also wanted to make sure that it could be extended as well. For example, all of our WebPack configs are exposed to the user of the boilerplate and therefore can be easily extended. If mature devs want a slight permutation of the infrastructure, we offer examples of configuring ERB for the configuration they want. For example, if a user preferred TypeScript over Flow, they can refer to examples of ERB that are configured with TypeScript instead of the default, which is Flow.

Future of electron-react-boilerplate

Since the creation of ERB, a number of new projects in the JS and Electron ecosystems have emerged and influenced the direction of ERB.

TypeScript

Flow was the initial choice for ERB a couple of years ago. Much has changed since then: TypeScript has thrived in the ecosystem and has proven itself to be a significant competitor to Flow. It previously presented compatibility issues with our with our existing infrastructure. Babel, ESLint, and React integration with TypeScript presented a number of issues and Flow could be implemented with much less friction to existing JS infrastructure. But with TypeScript embracing compatibility with  existing JS infra, we are considering migrating to TypeScript from.

create-react-app

The explosion of new React apps created with create-react-app (CRA) was hard for anyone in the JS ecosystem to ignore. CRA was a breakthrough in infrastructure because it removed the tight coupling between infrastructure of React apps and the source code of the apps themselves. The infrastructure of CRA apps are encapsulated in a single package: react-scripts. I believe ERB should go down this direction as well and embrace the separation from infrastructure and apps. Here's what I imagine creating apps with ERB will look like in the future:

# With npm
$ npx create-erb-app my-app
# With yarn
$ yarn create erb-app my-app
cd my-app

# Some examples of commands that can be run
yarn start
yarn package
yarn build
yarn publish
yarn lint

All the infrastructure would be configured with a few simple scripts which would be our equivalent of react-scripts

WebAssembly

Many electron apps rely on native dependencies, which are dependencies which interoperate with C and C++ code. These modules interoperate with C and C++ for performance increases and for simply having a way to bind to those languages. But native compilation requires recompiling those modules on a machine each time they are installed. More complications are introduced when the user does not have the dependencies to build these modules installed on their machine. These issues can be solved by compiling native modules to WebAssembly. Library authors can compile the C/C++ on their machines and distribute the compiled WebAssembly. Adding WebAssembly support to ERB can dramatically simplify the process of using native dependencies with Electron.

Every year I have a personal goal of learning something new each summer to make sure I don't stagnate as a programmer. This summer, my focus is to learn about the graphics stack of the web platform--namely, WebGL. After learning the basics of WebGL, shaders, and ThreeJS, I thought I'd start a project that incorporates all these technologies. That project is xwing, a game which recreates the trench run scene from Star Wars. If you've every seen Star Wars, you're probably familiar with the trench run scene. If not, here's a short clip showing what that is:

Inspiration

This game was heavily inspired by Star War Squadron Rogue Leader:

Goals

The goal of this project is to design a gameplay experience that is similar to Star War Squadron Rogue Leader. Here are the following goals that are unique to xwing:

• Published to the web
• Optimize game for slower internet connections
• Run on multiple devices with different levels of graphics performance
• Leverage high resolution assets and textures for the game
• Leverage modern web graphics technologies (WebGL 2, OffscreenCanvas)

Current State

The current state of xwing is a very experimental work in progress. The source code is available here. Feel free to contribute if you're interested! Subscribe for follow up blog posts tracking my progress on xwing and other projects.

Prior Art

• DroneWorld

TL;DR:

The tale of Brendan Eich's notorious 10 days of writing what he was told would be Java's "sidekick" language in the browser, "JavaScript", has taken off like no one would have ever expected. But Brendan could only do so much in those 10 days and one of the things he didn't have time to do was add exceptions and error handling to the language.

JS was designed so that it would "fail silently". These issues still persist in the language.

Here's some examples of JS silent failure semantics:

const foo = []
foo[1000]      // No exception thrown
foo.bar        // No exception thrown

[] + []        // No exception thrown
{} + []        // No exception thrown
// etc..

Fixing JavaScript

Why can't you just fix the problems in JavaScript?

TC39, the committee that decides the language specification for JS, follows a "Don't break the web" philosophy. All changes to the language must be semantically backwards compatible with all previous versions of the language.

There are also a number of attempts to fix the silent failure semantics of JS. Some time ago, Google proposed a "Strong Mode" for JS, which would eliminate all silent failure semantics from JS in a backwards compatible way. Unfortunately, the proposal did not pass and we're still left with the same broken semantics.

A New Hope: Transpilers

A couple years go by and writing vanilla JS has become a dreaded pastime. Transpilers, namely Babel, have taken the JS community by storm. Transpilers allow transformation of JS source code to compiled JS source code. What if we could write unsafe JS code and transform it to a stricter subset?

That's exactly what I've been experimenting with for a few weeks and the results have been quite promising:

What it does

Here's a simple example that shows failure of binary operators (-, +, *, etc) with unexpected types:

Here's a more real world example that shows:

• Failure on access of non-existent property
• Index out of bounds errors

Here's an informal spec of what the plugin (each will throw a TypeError on failure):

• Prevents out of bound array access
• Prevents access of non-existent property
• Allows usage of + (and other forms: +=, etc) only between strings and numbers. Other binary operators will fail on operation that contains at least one expression that is not a number
• Only comparisons between strings and numbers is
  allowed. Comparisons are only allowed between the same type. ex: '12' > 12 throws while 12 > 12 does not

How it works

The transformations that are applied are pretty simple: all binary expressions are wrapped in a function that checks the types of each expression and throws when the types are invalid. Here's an example of the comparison transformation:

{} + []

// transforms to:

safeComparison({}, "+", [])

Other transformations are similar. Here's the property access transformation:

const some = {}
some.foo.bar.baz

// transforms to:

safePropertyAccess(some, ['foo', 'bar', 'baz'])

Trying it out

Using the demo

git clone https://github.com/amilajack/babel-plugin-fail-explicit-demo.git
cd babel-plugin-fail-explicit-demo
npm i -g babel-cli
babel-node index.js

Manual install:

npm i babel-plugin-fail-explicit
npm i transform-es2015-modules-commonjs
npm i -g babel-cli

Create a .babelrc file:

{
  "plugins": [
    "fail-explicit",
    "transform-es2015-modules-commonjs"
  ]
}

Write some JS:

// index.js
const some = []
some += 12

Run babel-node index.js ? ? ?

Challenges

Transforming code and wrapping expressions in functions comes at the cost of debugging the code. The stacktraces of the transformed code is far more convoluted when compared to those of source code. Here's what the stack trace of the transformed code looks like for the following source:

const foo = []
foo[1111]

/safe-access-check/lib/index.js
          throw new TypeError(`"${separators.join('')}" is out of bounds`);
          ^

TypeError: "Array[1111]" is out of bounds
    at protoChain.forEach.each
    at Array.forEach (native)
    at safePropertyAccess
    at Object.<anonymous>
    at Module._compile
    at loader
    at Object.require.extensions.(anonymous function)
    at Module.load
    at tryModuleLoad
    at Function.Module._load

Ideally, safePropertyAccess() and other added checks could be removed from the stack trace, giving the impression that the checks were made natively by the language. I have noticed that flow-runtime somehow does this. The way it manipulates the stack trace is definitely worth investigating.

What's Next

I'm currently looking for feedback from users and language designers. I'd really appreciate test case contributions or bug reports.

This article provides a short background of WebAssembly and provides a tutorial to get you started.

Background

“Write once, work everywhere” is the beauty of the web. This cannot be said for the many native platforms, including iOS, OSX, Android, Windows, Gnome, and other. Just remember the last time you tried compiling or installing something and it would just work! Nothing beats npm i && npm start ? .

But the high-level environment that the browser offers comes at the cost of performance. “Write once, work everywhere” also means that the web can't be broken. Providing a high-level also means that developers are stuck with the API's that the browser has. Want truly multithreaded apps? Too bad. You're stuck with WebWorkers and will have to wait until the Web API's or ES6 standards change. Want to build a graphics intensive app

Or at least this was the case.

WebAssembly is what changes all of that.

What is WebAssembly?

In short, Webassembly (wasm) is a binary format for the web that aims to match native performance, extend the JavaScript language (kernel semantics). For a more in-dept explanation, refer to the sources at the end of this article. Check out an Angry Bots and compare the differences between asm.js and wasm performance.

Possibilities

Some practical use cases of wasm include migrating the bottlenecked parts of a JavaScript application to wasm and importing them as scripts (very similar to node c++ bindings):

// vDOM reconciliation in react
import diff from 'wasm-diff'

// Check if react update the DOM
function reconcileDOM(vDOM, html) {
    diff(vDOM, html)
}

wasm can also be used as a compile target for games, video editing, and other native applications.

At the moment, this is pretty difficult. I've been messing around with wasm but haven't found any tutorials to help me out so I thought I would shed some light on how to get started.

Mad Science

First, let's try to compile a native application so that we have something to compare wasm to. We will be using, openFrameworks a mature graphics library that supports compilation to wasm through emscripten, build tool which compiles C/C++ to wasm. I should note that this tutorial assumes that you are running on macOS. If you are using another platform, please reference the docs.

First, we'll need to go to openframeworks and download the version for osx. Preferably, you should move this to your projects directory. (Note: Avoid cloning from the github repo)

Then we need to generate the files needed to run the openFrameworks examples, located in of v0.9.x_osx_release/examples. To do this, open projectGenerator.app inside of projectGenerator-osx. If you don't prefer manually entering the path to the download, click on the search icon and open the openFrameworks folder.

The result should resemble this:

Cool! Now click generate. This should notify you to open xCode. When it opens, click on the 'scheme' at the top right and select the library icon:

Perfect! Now, cd to the examples/3d/3DPrimitivesExample directory inside of v0.9.x_osx_release, open 3DPrimitivesExample.xcodeproj, and click xCode's 'play' button.

You should see something similar to this:

Impressive! Now let's see how well wasm performs.

==Requirements: cmake, git, node ==

To get started, we'll need to download the emscripten sdk and 'Portable Emscripten SDK for Linux and OS X'. After unzipping the folder:

# Move it to your mode directory.
mv emsdk_portable ~/

# cd into it.
cd ~/emsdk_portable

# Fetch the latest registry of available tools.
./emsdk update

# Download and install the latest SDK tools.
./emsdk install latest

# Make the "latest" SDK "active"
./emsdk activate latest

# Set the env variables for the current session
source ./emsdk_env.sh

Requirement: Your default browser should support WebGL

Now that we have emsdk, let's use it to compile an openFrameworks project. Inside the same terminal window, cd back to the examples/3d/3DPrimitivesExample directory inside of v0.9.x_osx_release and run:

# This will take a while. Come back after a cup of coffee
emmake make

# Run the demo in your default browser
emrun bin/3DPrimitivesExample.html

"...wth... HOW?" Alon Zakai (creator of emscripten) explains this well:

This blog post is a work in progress. I am in the process of asking Alon Zakai about how to migrate asm.js code to wasm and will update this blog post when I get the answer

I do not have a comments system at the time of writing this so feel free to email me if you have any questions (amilajack@gmail.com).

Sources/Recommended Reading:

• Official WebAssembly page
• WebAssembly Design
• What is WebAssembly? The dawn of a new era
• Why we need WebAssembly an interview with Brendan Eich
• From asm.js to WebAssembly
• Things you should know about webassembly