branneman

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

jevakallio

TL;DR: If you want to see me perform a spoken word poem about JavaScript in front of 1000 people (and on video), please ⭐ star this gist. If you're on mobile, you'll need to request desktop site.

JavaScript Slam Poetry

kitten

With styled-components into the future

Preprocessing is dead, long live preprocessing!

This is a CFP for ReactiveConf 2017's open call for Lightning talks. If you'd like to see this talk become a reality, please ⭐ star this gist. #ReactiveConf

halfzebra

This gist is a proposal for lightning talk at Reactive Conf 2017

Like the idea? Give me a 🌟 and see you in Bratislava!

How Create React App changed the way I work

Hello, my name is Eduard!

I'm the maintainer of Create Elm App and contributor to Create React App and Webpack

pesterhazy

This gist lists challenges you run into when building offline-first applications based on IndexedDB, including open-source libraries like Firebase, pouchdb and AWS amplify (more).

Note that some of the following issues affect only Safari. Out of the major browsers, Chrome's IndexedDB implementation is the best.

Backing file on disk (WAL file) keeps growing (Safari)

When this bug occurs, every time you use the indexeddb, the WAL file grows. Garbage collection doesn't seem to be working, so after a while, you end up with gigabytes of data.

Random exceptions when working with a large number of indexeddb databases (Safari)