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

ryanflorence

import React from "react";
import { Link } from "react-router-dom";

export function createResource(getPromise) {
  let cache = {};
  let inflight = {};
  let errors = {};

  function load(key) {
    inflight[key] = getPromise(key)

bvaughn

This API was removed in React 17

---

Interaction tracing with React

React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".

With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.

rviscomi

# https://discuss.httparchive.org/t/how-many-text-files-are-not-served-with-gzip/1092
#
# https://bigquery.cloud.google.com/table/httparchive:runs.2017_10_15_requests
#
# Browse encoding and MIME type for 10 random requests.

#standardSQL
SELECT
  resp_content_encoding,
  mimeType,

jezhumble

Stevey's Google Platforms Rant

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real

CMCDragonkai

HTTP Streaming (or Chunked vs Store & Forward)

The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.

However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on

fakedarren

I feel the need to have a little rant about MooTools and ES7 and the whole 'Array.contains' hoo-hah.

When MooTools came out in 2006, the most popular framework was Prototype. As the name suggests, it extended prototypes, as did MooTools. People still referred to making websites with JavaScript as 'DHTML', there was no trim method on strings, there wasn't even a forEach method on arrays. JavaScript was a crippled language. IE6 ruled the waves.

MooTools, Prototype, Dojo, Base2 - they made the language usable, even fun, to work with. By using an incredible feature of JavaScript, prototypical inheritance, we were able to add features to the language that made it palatable.

Be it simple methods like number.toInt, string.trim, array.forEach, or familiar programming constructs such as Class, MooTools and its ilk took JavaScript from something impossible to work with to something that you could properly use to build awesome sites, and even apps - Microsoft, IE and desktop ruled everything, and the concept of a 'we

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

jboner

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD