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
(by @andrestaltz)
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.
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)
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
The spec has moved to a repo: https://github.com/defunctzombie/package-browser-field-spec to facilitate collaboration.
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.
NOTE: This guide has moved to https://github.com/bpierre/switch-to-vim-for-good
This guide is coming from an email I used to send to newcomers to Vim. It is not intended to be a complete guide, it is about how I switched myself.
My decision to switch to Vim has been made a long time ago. Coming from TextMate 1, I wanted to learn an editor that is Open Source (so I don’t lose my time learning a tool that can be killed), cross platform (so I can use it everywhere), and powerful enough (so I won’t regret TextMate). For these reasons, Vim has always been the editor I wanted to learn, but it took me several years before I did it in a way that works for me. I tried to switch progressively, using the Janus Vim distribution for a few months, then got back to using TextMate 2 for a time, waiting for the next attempt… here is what finally worked for me.
Original gist with comments: https://gist.github.com/bpierre/0a0025d348b6001394e0
#Angular Sandbox Escapes Cheatsheet
Source: XSS without HTML: Client-Side Template Injection with AngularJS
1.0.1 - 1.1.5 Mario Heiderich (Cure53)
{{constructor.constructor('alert(1)')()}}
1.2.0 - 1.2.1