All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
With the addition of ES modules, there's now no fewer than 24 ways to load your JS code: (inline|not inline) x (defer|no defer) x (async|no async) x (type=text/javascript | type=module | nomodule) -- and each of them is subtly different.
This document is a comparison of various ways the <script> tags in HTML are processed depending on the attributes set.
If you ever wondered when to use inline <script async type="module"> and when <script nomodule defer src="...">, you're in the good place!
Note that this article is about <script>s inserted in the HTML; the behavior of <script>s inserted at runtime is slightly different - see Deep dive into the murky waters of script loading by Jake Archibald (2013)
HTTP Archive (powered by HAR files): www.httparchive.org
HAR Viewer: http://code.google.com/p/harviewer/
| import { test, expect } from "@playwright/test"; | |
| import type * as webVitals from 'web-vitals'; | |
| import path from 'path'; | |
| import fs from 'fs'; | |
| declare global { | |
| interface Window { | |
| webVitals: typeof webVitals; | |
| validateMetric: (name: string, good: boolean) => void; | |
| } |
| " ============================================================================= | |
| " Miller Medeiros .vimrc file | |
| " ----------------------------------------------------------------------------- | |
| " heavily inspired by: @factorylabs, @scrooloose, @nvie, @gf3, @bit-theory, ... | |
| " ============================================================================= | |
| " ----------------------------------------------------------------------------- | |
| " BEHAVIOR |
| # ----------------------------------------------------------------- | |
| # .gitignore for WordPress @salcode | |
| # ver 20180808 | |
| # | |
| # From the root of your project run | |
| # curl -O https://gist.githubusercontent.com/salcode/b515f520d3f8207ecd04/raw/.gitignore | |
| # to download this file | |
| # | |
| # By default all files are ignored. You'll need to whitelist | |
| # any mu-plugins, plugins, or themes you want to include in the repo. |
As William Durand was recently explaining in his SOS, he "didn't see any other interesting blog post about REST with Symfony recently unfortunately". After spending some long hours to implement an API strongly secured with oAuth, I thought it was time for me to purpose my simple explanation of how to do it.
You might have already seen some good explanation of how to easily create a REST API with Symfony2. There are famous really good bundles a.k.a. :
| /* Using a JavaScript proxy for a super low code REST client */ | |
| // via https://dev.to/dipsaus9/javascript-lets-create-aproxy-19hg | |
| // also see https://towardsdatascience.com/why-to-use-javascript-proxy-5cdc69d943e3 | |
| // also see https://github.com/fastify/manifetch | |
| // also see https://github.com/flash-oss/allserver | |
| // and https://gist.github.com/v1vendi/75d5e5dad7a2d1ef3fcb48234e4528cb | |
| const createApi = (url) => { | |
| return new Proxy({}, { | |
| get(target, key) { |
