Данный FAQ был специально создан для телеграм сообщества https://t.me/WebAssembly_ru.
Он базируется на статье от Andre Weissflog, но так же содержит множество моих дополнений и мыслей, которые могут быть уже не слишком актуальны на момент прочтения. Прошу это учитывать.
https://github.com/myshov/codemodes-tycoon - codemodes из презентации
https://github.com/facebook/jscodeshift - jscodeshift
https://github.com/benjamn/ast-types/blob/master/def - определения AST-узлов
https://www.toptal.com/javascript/write-code-to-rewrite-your-code - статья с хорошими примерами
https://astexplorer.net - инспектор ast
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)
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.
#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
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
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
See https://github.com/romainl/vim-qlist for an up-to-date version.