Bret Little blittle

## headless-theme-redirect.liquid
{% comment %}

  UPDATE: Now you can use this theme to more easily manage your redirects:
  https://github.com/benjaminsehl/shopify-headless-theme

{% endcomment %}

{% assign new_website = 'https://headless-website.com/' %}
<!doctype html>
<html>

## statechange-proposal.md

      
              1 file
            
          
              0 forks
            
          
              1 comment
            
          
              1 star
            
          
                frehner
                / statechange-proposal.md
            
            
              Last active
              May 15, 2020 19:30
            
              
                This is a work-in-progress proposal
              
          
    Proposal

Add an event called statechange that will fire on any change to the history stack, whether that be through the browser's back button, or window.history.pushState or other methods.
This proposed event would be similar to popstate, except that it would fire on all route changes regardless of the source, much like hashchange fires on all hash changes regardless of the source.
Current Problems

hashchange events allowed javascript router libraries (e.g. React Router, vue-router) to easily respond to any routing event when the application is using hash routing.

  
## WhyReact.md

      
              1 file
            
          
              14 forks
            
          
              26 comments
            
          
              263 stars
            
          
                sebmarkbage
                / WhyReact.md
            
            
              Created
              September 4, 2019 20:33
            
              
                Why is React doing this?
              
          
    I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

  
## shakespeare.json
[
"Shall I compare thee to a summer's day?\nThou art more lovely and more temperate:\nRough winds do shake the darling buds of May,\nAnd summer's lease hath all too short a date",
"To be, or not to be: that is the question",
"Neither a borrower nor a lender be; For loan oft loses both itself and friend, and borrowing dulls the edge of husbandry",
"This above all: to thine own self be true",
"Though this be madness, yet there is method in 't.",
"That it should come to this!",
"There is nothing either good or bad, but thinking makes it so",
"What a piece of work is man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world, the paragon of animals! ",
"The lady doth protest too much, methinks",

## prepack-gentle-intro-1.md

      
              1 file
            
          
              26 forks
            
          
              14 comments
            
          
              637 stars
            
          
                gaearon
                / prepack-gentle-intro-1.md
            
            
              Last active
              May 3, 2024 12:56
            
              
                A Gentle Introduction to Prepack, Part 1
              
          
Note:
When this guide is more complete, the plan is to move it into Prepack documentation.

For now I put it out as a gist to gather initial feedback.

A Gentle Introduction to Prepack (Part 1)

If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:

Babel lets you use newer JavaScript language features, and outputs equivalent code that targets older JavaScript engines.


## prepack-svelte.md

      
              1 file
            
          
              3 forks
            
          
              7 comments
            
          
              44 stars
            
          
                Rich-Harris
                / prepack-svelte.md
            
            
              Last active
              May 19, 2022 11:02
            
              
                Is Prepack like Svelte?
              
          
    Note: I'm not involved in Prepack in any way — please correct me if I say anything incorrect below!
A few people have asked me if Prepack and Svelte are similar projects with similar goals. The answer is 'no, they're not', but let's take a moment to explore why.
What is Prepack?

Prepack describes itself as a 'partial evaluator for JavaScript'. What that means is that it will run your code in a specialised interpreter that, rather than having some effect on the world (like printing a message to the console), will track the effects that would have happened and express them more directly.
So for example if you give it this code...

  
## imperative-v-declarative-imports.md

      
              1 file
            
          
              1 fork
            
          
              15 comments
            
          
              32 stars
            
          
                Rich-Harris
                / imperative-v-declarative-imports.md
            
            
              Last active
              May 6, 2024 10:23
            
              
                Why imperative imports are slower than declarative imports
              
          
    Why imperative imports are slower than declarative imports

A lot of people misunderstood Top-level await is a footgun, including me. I thought the primary danger was that people would be able to put things like AJAX requests in their top-level await expressions, and that this was terrible because await strongly encourages sequential operations even though a lot of the asynchronous activity we're talking about should actually happen concurrently.
But that's not the worst of it. Imperative module loading is intrinsically bad for app startup performance, in ways that are quite subtle.
Consider an app like this:
// main.js

  
## firstJank.js
if (window.requestAnimationFrame) {
  function checkForJank () { // eslint-disable-line no-inner-delcarations
    const frameStart = Date.now()
    window.requestAnimationFrame(() => {
      const frameDuration = Date.now() - frameStart
      if (frameDuration > 17) {
        Perf.log(FirstJank)
      } else {
        checkForJank()
      }

## classy-jquery.js
/**
classy jQuery - an alternate reality where jQuery really sucked and never took off
OR
Why nobody would have liked jQuery if it had exported a class instead of a factory.
**/

// This just looks stupid. Are we creating a new DOM element
// with id="foo"? Nope. We're selecting an existing DOM element
// with id="foo", and wrapping it in a jQuery object instance.
var $foo = new $('#foo');

## reflux.js
var EventEmitter = require('events').EventEmitter,
    _ = require('lodash');

/**
 * Creates an action functor object
 */
exports.createAction = function() {

    var action = new EventEmitter(),
        eventLabel = "action",
	{% comment %}

	UPDATE: Now you can use this theme to more easily manage your redirects:
	https://github.com/benjaminsehl/shopify-headless-theme

	{% endcomment %}

	{% assign new_website = 'https://headless-website.com/' %}
	<!doctype html>
	<html>
	[
	"Shall I compare thee to a summer's day?\nThou art more lovely and more temperate:\nRough winds do shake the darling buds of May,\nAnd summer's lease hath all too short a date",
	"To be, or not to be: that is the question",
	"Neither a borrower nor a lender be; For loan oft loses both itself and friend, and borrowing dulls the edge of husbandry",
	"This above all: to thine own self be true",
	"Though this be madness, yet there is method in 't.",
	"That it should come to this!",
	"There is nothing either good or bad, but thinking makes it so",
	"What a piece of work is man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world, the paragon of animals! ",
	"The lady doth protest too much, methinks",
	if (window.requestAnimationFrame) {
	function checkForJank () { // eslint-disable-line no-inner-delcarations
	const frameStart = Date.now()
	window.requestAnimationFrame(() => {
	const frameDuration = Date.now() - frameStart
	if (frameDuration > 17) {
	Perf.log(FirstJank)
	} else {
	checkForJank()
	}
	/**
	classy jQuery - an alternate reality where jQuery really sucked and never took off
	OR
	Why nobody would have liked jQuery if it had exported a class instead of a factory.
	**/

	// This just looks stupid. Are we creating a new DOM element
	// with id="foo"? Nope. We're selecting an existing DOM element
	// with id="foo", and wrapping it in a jQuery object instance.
	var $foo = new $('#foo');
	var EventEmitter = require('events').EventEmitter,
	_ = require('lodash');

	/**
	* Creates an action functor object
	*/
	exports.createAction = function() {

	var action = new EventEmitter(),
	eventLabel = "action",