evantahler

#! /usr/bin/env node
// I am ./bin/buildSitemap.js

const path = require('path')
const glob = require('glob')
const fs = require('fs')

const SITE_ROOT = process.env.SITE_ROOT || 'https://www.actionherojs.com'
const SOURCE = process.env.SOURCE || path.join(__dirname, '..', 'pages', '/**/*.js')
const DESTINATION = process.env.DESTINATION || path.join(__dirname, '..', 'static', 'sitemap.xml')

VictorTaelin

async/await is just the do-notation of the Promise monad

CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.

In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.

First, let's illustrate the 3 styles by implementing

seanjensengrey

# source:http://reocities.com/SiliconValley/heights/7052/opcode.txt
From: mark@omnifest.uwm.edu (Mark Hopkins)
Newsgroups: alt.lang.asm
Subject: A Summary of the 80486 Opcodes and Instructions

(1) The 80x86 is an Octal Machine
   This is a follow-up and revision of an article posted in alt.lang.asm on
7-5-92 concerning the 80x86 instruction encoding.
 
   The only proper way to understand 80x86 coding is to realize that ALL 80x86

developit

🐻 valoo

just the bare necessities of state management.

Usage

Hotlink it from https://unpkg.com/valoo.

See Interactive Codepen Demo.

DavidKuennen

(function (context, trackingId, options) {
    const history = context.history;
    const doc = document;
    const nav = navigator || {};
    const storage = localStorage;
    const encode = encodeURIComponent;
    const pushState = history.pushState;
    const typeException = 'exception';
    const generateId = () => Math.random().toString(36);
    const getId = () => {

donaldpipowitch

Install @codemod/cli globally:

$ npm install -g @codemod/cli
# or
$ yarn global add @codemod/cli

This package works out of the box with most code bases, because it comes bundled with @babel/preset-env and @babel/preset-typescript. If you need other presets or plugins for parsing your source code you can use a custom Babel config as well. Note that the codemod will not apply the transformations from these presets and plugins - they are only used for parsing. Therefor you keep your TypeScript types in your source code for example. Formatting will be kept the same as much as possible.

ld100

Migrating from Ubuntu on WSL to ArchLinux on WSL2

Obsolete notice

This document was created back in 2020 and might not be actual nowadays. It is not supported anymore, so use thise information at your own risk.

Upgrading to WSL 2

• Download WSL2 Kernel
• run wsl --set-default-version 2 in windows command line, so that all future WSL machine will use WSL2.

tannerlinsley

Replacing Create React App with the Next.js CLI

How dare you make a jab at Create React App!?

Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.

Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.

So why

rikschennink

export default (element: HTMLElement, options: any = {}) => {
    // if added as action on non focusable element you should add tabindex=0 attribute

    const {
        direction = undefined,
        shiftMultiplier = 10,
        bubbles = false,
        stopKeydownPropagation = true,
    } = options;

yyx990803

// example vite.config.js
import { cdn } from './vite-plugin-cdn'

export default {
  plugins: [
    // also supported: esm.run, jspm
    // loads the dep over the CDN during dev
    // auto downloads and includes into the bundle during build
    cdn('skypack', {
      vue: '^3.0.5'