Skip to content

Instantly share code, notes, and snippets.

@paulhhowells
paulhhowells / memory leaks .js
Last active May 25, 2022 08:33
avoid memory leaks with closures. google javascript style guide.
// from google javascript style guide:
// One thing to keep in mind, however, is that a closure keeps a pointer to its enclosing scope. As a
// result, attaching a closure to a DOM element can create a circular reference and thus, a memory leak.
// For example, in the following code:
// Leaky example
function foo (element, a, b) {
element.onclick = function() {
// uses a and b
// this func keeps a pointer to foo, its enclosing scope
@sindresorhus
sindresorhus / writing-eslint-rule.md
Last active February 26, 2023 03:01
Gettings started writing a ESLint rule

Gettings started writing a ESLint rule

First, take a look at the ESLint rule documentation. Just skim it for now. It's very long and boring. You can come back to it later.

ESLint rules works on the AST (Abstract Syntax Tree) representation of the code. In short, this is a tree structure that describes the code in a very verbose form. ESLint walks this tree and rules can subscribe to be notified when it hits a specific node type, like a Literal type, which could be the "hello" part of const welcome = "hello";.

Go ahead and play around with some code in AST Explorer (Make sure the parser is espree). It's a great tool!

Here are some good articles on the subject (ignore the scaffolding parts):

@ryanoglesby08
ryanoglesby08 / server.js
Last active June 21, 2024 14:11
A node.js SPA server that serves static files and an index.html file for all other routes.
/*
Incredibly simple Node.js and Express application server for serving static assets.
DON'T USE THIS IN PRODUCTION!
It is meant for learning purposes only. This server is not optimized for performance,
and is missing key features such as error pages, compression, and caching.
For production, I recommend using an application framework that supports server-side rendering,
such as Next.js. https://nextjs.org

Bypassing a Browser Game's Client-Side Security

Not long ago, I used to play a real-time multiplayer browser game called TagPro. The architecture is fairly standard for real-time multiplayer games. The browser opens a websocket connection to a server and user input is sent over the open connection. The server runs all the game logic and sends the game state to each browser several times a second.

Client-Side Security

There are two separate versions of the JavaScript bundle that powers the TagPro client: a competitive version with client-side security and a casual version without. A toggle in private games enables the competitive version. The JavaScript for TagPro's competitive scene has a few security measures in place to prevent third-party script execution. The first security measure is not exposing the game object globally by wrapping the game.js bundle in a self-executing function:

(function init() {
  // game.js
  var tagpro = {
 ...