const pApply = (fn, ...cache) => (...args) => {
const all = cache.concat(args);
return all.length >= fn.length ? fn(...all) : pApply(fn, ...all);
};
// This sample is a Work in Progress for JSI , and specific functions may change. | |
#pragma once | |
#include <string> | |
#include <unordered_map> | |
#include <jsi/jsi.h> | |
// This SameplJSIObject needs to inheric from HostObject, and this is the object that will be exposed to JS. |
// Based on a discussion with Michael Haufe: | |
// https://groups.google.com/group/jsmentors/browse_thread/thread/d028fb0041f93a27 | |
// Not really recommended for anything but the fun of knowing it can be done! | |
var omega = function() { | |
var queue = []; | |
var valueOf = Function.prototype.valueOf; | |
Function.prototype.valueOf = function() { | |
queue.push(this); | |
return 1; // not needed now, but could be used later to distinguish operators. |
Eric Bidelman has documented some of the common workflows possible with headless Chrome over in https://developers.google.com/web/updates/2017/04/headless-chrome.
If you're looking at this in 2016 and beyond, I strongly recommend investigating real headless Chrome: https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md
Windows and Mac users might find using Justin Ribeiro's Docker setup useful here while full support for these platforms is being worked out.
var detectBackOrForward = function(onBack, onForward) { | |
hashHistory = [window.location.hash]; | |
historyLength = window.history.length; | |
return function() { | |
var hash = window.location.hash, length = window.history.length; | |
if (hashHistory.length && historyLength == length) { | |
if (hashHistory[hashHistory.length - 2] == hash) { | |
hashHistory = hashHistory.slice(0, -1); | |
onBack(); |
#!/bin/bash | |
LOADING=false | |
DEBUG=/dev/null | |
usage() | |
{ | |
cat << EOF | |
usage: $0 [options] <DBNAME> |
LOADING=false | |
usage() | |
{ | |
cat << EOF | |
usage: $0 [options] dbname | |
OPTIONS: | |
-h Show this help. | |
-l Load instead of export |
The Critical Rendering Path is the sequence of steps the browser goes through to convert the HTML, CSS and JavaScript into actual pixels on the screen. If we can optimize the critical rendering path, we can make our pages faster.
When you type an URL and hit enter, the browser sends a request to the server. The server returns a response with the HTML to the browser, which somehow needs to convert the markup into something that we can see on the screen.
The browser follows a well defined set of steps and it all starts with processing the HTML and building the DOM.