ESLint use it! To start using it on large codebases, add all files to .eslintignore and then tackle files one by one. This cuts down on the number of collisions with other PRs. Look for additional plugins, like the React ESLint plugin, and you can create your own
OSS your code early. Don’t wait until “it’s good enough for others”, because then you’ve waited too long. OSS is about collaboration and improvement, not promotion of already-finished code.
Start with libraries and frameworks as you rapidly develop/evolve/explore a project. But as it matures, try to build time in for refactoring to reduce/remove those pieces. You don’t need them permanently. The best code is the code that’s exactly what’s needed, no more, no less.
Favor laziness since laziness can lead to better performance & extendability
Try to compose single expressions which data flows through and, if you struggle, don’t “cheat”, but rather look for stream method alternatives - they are there. It will simplify the whole codebase.
Normalization helps composability. I tend to wrap all my utilities in the same type of stream so that my application code works like legos. Wrapping is a pain, but those utilities tend not to change so it’s a one time thing.
When you arrive at an n-way stop at the same time as one or more vehicles, who should go first? Take your right hand, and point it to the right of you. If you’re pointing at nobody, it’s your turn to go!
Make sure you use waitUntil() for any async operations outside of respondWith(). Many examples will try to do things like cache resources after resolving the respondWith() promise without calling waitUntil(). The browser can kill the worker before these async operations complete. You may not see this in development, though, because the browser sometimes keeps the worker alive with devtools open.
If you do 'network first' routes in the service worker, fallback set a timeout to wait for the response and if it fails respond with cached or fallback content. This keeps the app responsive when the device is "online" but no data is going anywhere this stops infinite loading spinners when connected to captive portals, or have low phone signal. I do 2-5s timeout usually.
Sometimes it's just easier to disable registering SW in development. Just helps when you're trying to build/fix other parts of the site.
It's very important to test your update process when deploying new versions of apps with SW. It's possible to “brick” a web app since if you successfully register a SW, then push an update that has a JS error that prevents your SW registration code from running. Pushing a new version won't fix it because it won't register the new SW and keeps serving the broken code from the previous SW.
It's early to say this, but I think GraphQL will eventually replace REST as dominant http API approach for applications.
When you are struggling on a problem, take two steps back and ask “What am I trying to accomplish. Is this the best avenue for the results.”
Read the source code!!! Source code is the one true documentation. If you are ever curious about how something works, or what additional features there are, pop in the source code and start reading. Webpack’s source code has lots of hidden and cool features.
When you dive into new realms of programming, be it web-audio, functional programming, or whatever it is you're after, don't be afraid to dive in and iterate. Start with simple micro-projects and keep growing a notch every time. I find it hard to really get into new technology without getting my hands dirty from the start. Practice is essential.