Upgrade to Pro — share decks privately, control downloads, hide ads and more …

🇪🇸 React Alicante 2026 (Workshop)

🇪🇸 React Alicante 2026 (Workshop)

Avatar for Matheus Albuquerque

Matheus Albuquerque PRO

September 24, 2026

More Decks by Matheus Albuquerque

Other Decks in Programming

Transcript

  1. 𝕏 Matheus Albuquerque ↝ 👨💻 STAFF SWE @ MEDALLIA ↝

    ⚛ CHAIR @ REACT SUMMIT NYC ↝ ⚡ GOOGLE DEVELOPER EXPERT ↝ YTHECOMBINATOR
  2. COMPILERS &… ME: JAVASCRIPT YOUR MACRO YOUR CODE unless (user.isLoggedIn)

    { macro unless { rule { ($condition) { $body } } } if (!$condition) { $body } } > = . . . . . } . showLogin(); {
  3. COMPILERS &… ME: JAVASCRIPT YOUR MACRO YOUR CODE unless (user.isLoggedIn)

    { macro unless { showLogin(); rule { ($condition) { $body } if (!$condition) { $body } } > . }
  4. COMPILERS &… ME: JAVASCRIPT YOUR CODE unless (user.isLoggedIn) { showLogin();

    } YOUR RESULT if (!user.isLoggedIn) { showLogin(); }
  5. COMPILERS &… ME: JAVASCRIPT ↝ LANGUAGE EXPERIMENTS COULD HAPPEN THROUGH

    COMPOSABLE USER-LAND SYNTAX EXTENSIONS. ↝ INDEPENDENTLY AUTHORED SYNTAX TRANSFORMATIONS COULD PARTICIPATE IN THE SAME COMPILATION PIPELINE, GIVING US A PLAYGROUND WHERE SYNTAX IDEAS COULD EXIST AS LIBRARIES BEFORE/WITHOUT BECOMING PART OF ECMASCRIPT.
  6. COMPILERS &… ME: JAVASCRIPT ↝ IN RETROSPECT, NOT EVERY JAVASCRIPT

    FEATURE BECAME A MACRO… OUR ECOSYSTEM LARGELY MOVED TOWARD PARSERS, BABEL PLUGINS, TRANSFORMS, CODEMODS, AND SPECIALIZED COMPILERS. ↝ BUT THE UNDERLYING IDEA SURVIVED: COMPILE-TIME EXTENSIBILITY BECAME REGULAR JAVASCRIPT ENGINEERING.
  7. COMPILERS &… ME: JAVASCRIPT ↝ CAN I EXTEND JAVASCRIPT ITSELF?

    ↝ CAN I ANALYZE AND TRANSFORM JAVASCRIPT? ↝ CAN STATIC ANALYSIS CHANGE FRAMEWORK EXECUTION? ↝ WHAT IF THE LANGUAGE ITSELF IS DESIGNED TO EXPOSE MORE INFORMATION TO THE COMPILER?
  8. #reflection 🤔 Looking back, this was probably my earliest exposure

    to an idea that'll keep resurfacing throughout this workshop…
  9. #protip 📝 JavaScript source doesn't have to be the program

    that executes. It can be input to another program that understands and rewrites it.
  10. “So here’s my advice for anyone who wants to make

    a dent in the future of web development: time to learn how compilers work.” Compilers are the New Frameworks • Tom Dale, 2017
  11. “Reactive systems have existed even in this space for years.

    In fact, reactivity was seen as a bad thing for a while with the rise of the popularity of React. The thing that has made reactive programming interesting again are compilers.” Marko: Compiling Fine-Grained Reactivity • Ryan Carniato, 2022
  12. “Static analysis and compilation let us take what we know

    of your code's structure and optimize the creation paths as we already know what you are trying to create.” Marko: Compiling Fine-Grained Reactivity • Ryan Carniato, 2022
  13. COMPILERS & STATIC ANALYSIS… ↝ LINTERS: ESLint (2013), TSLint (2015),

    Biome (2023), Oxlint (2023)… ↝ FORMATTERS: Prettier (2017), dprint (2020), Biome (2023)… ↝ BUNDLERS: Webpack (2012), Rollup (2015), Vite (2020), esbuild (2020), Rspack (2022), Rolldown (2023)…
  14. COMPILERS & STATIC ANALYSIS… ↝ TRANSPILERS: Babel (2014), SWC (2020)…

    ↝ TYPE CHECKERS: TypeScript (2012), Flow (2014)… ↝ MINIFIERS: UglifyJS (2010), Terser (2018)… ↝ CSS PROCESSING: PostCSS (2013), CSSO (2015), cssnano (2015), LightningCSS (2022)…
  15. METHODOLOGY: OVERVIEW ↝ REVISITING COMPUTER SCIENCE CONCEPTS. ↝ UNDERSTANDING HOW

    TOOLS WORK UNDER THE HOOD AND THE RATIONALES BEHIND THEM BY CHECKING THEIR SOURCE CODE. ↝ LEVERAGING REAL-WORLD CASE STUDIES FROM SMALL, MEDIUM, AND ENTERPRISE-SCALE COMPANIES. ↝ MICRO EXPERIMENTS AND THEIR RESULTS.
  16. METHODOLOGY: GOALS Open your mind to—or even Bridge the gap

    between empower you with—tools to foundational CS concepts tackle a variety of complex and practical front-end challenges. development.
  17. METHODOLOGY: STEPS ↝ CLONING THE REPO NOW. ↝ GETTING THE

    SLIDES LATER. ↝ QUESTIONS AT THE END OF EACH SECTION. ↝ CONFERENCE BREAKS.
  18. OVERVIEW ↝ A COMPILER TRANSLATES BETWEEN LANGUAGES OR REPRESENTATIONS UNDER

    A CONTRACT. ↝ CORRECTNESS IS RELATIVE TO THAT CONTRACT: TYPES, SOURCE LOCATIONS, PERFORMANCE CONSTRAINTS, API COMPATIBILITY, ETC. ↝ AN OPTIMIZATION MAY RADICALLY CHANGE IMPLEMENTATION WHILE “PROMISING” THE SAME RELEVANT BEHAVIOR.
  19. OVERVIEW ↝ SOURCE ⇢ REPRESENTATION ⇢ FACTS ⇢ TRANSFORMATION ⇢

    TARGET. ↝ THE SOURCE DEFINES THE SYNTAX AND SEMANTICS ACCEPTED AS INPUT. ↝ THE TARGET DEFINES THE FORM PRODUCED AS OUTPUT. ↝ THE COMPILER CONTRACT STATES WHICH PROPERTIES OF THE SOURCE PROGRAM THE TRANSLATION PRESERVES.
  20. OVERVIEW: SOURCE TO DESTINATION SOURCE DESTINATION “PROMISE” TYPESCRIPT JAVASCRIPT ERASE

    TYPES + PRESERVE RUNTIME JSX JAVASCRIPT PRESERVE COMPONENT/RENDERING OLD API NEW API SATISFY A DOCUMENTED MIGRATION
  21. OVERVIEW: SOURCE TO DESTINATION ↝ BABEL: MODERN JAVASCRIPT + TYPESCRIPT

    SYNTAX ⇢ JAVASCRIPT ACCEPTED BY A SELECTED RUNTIME ENVIRONMENT. ↝ SVELTE: A .SVELTE COMPONENT ⇢ JAVASCRIPT + CSS MODULES.
  22. COMPILATION PHASES ↝ EACH PHASE CONSUMES ONE PROGRAM REPRESENTATION AND

    PRODUCES ANOTHER ONE (OR A SET OF FACTS). ↝ LEXICAL ANALYSIS PRODUCES TOKENS. ↝ PARSING PRODUCES A SYNTAX TREE. ↝ SEMANTIC ANALYSIS PRODUCES FACTS ABOUT DECLARATIONS, REFERENCES, TYPES, AND PROGRAM BEHAVIOR.
  23. COMPILATION PHASES ↝ LOWERING PRODUCES A MORE REGULAR INTERMEDIATE REPRESENTATION.

    ↝ CODE GENERATION PRODUCES THE TARGET PROGRAM. ↝ A REAL-WORLD COMPILER MAY COMBINE PHASES, REPEAT PHASES, AND USE SEVERAL INTERMEDIATE REPRESENTATIONS.
  24. COMPILATION PHASES: TYPESCRIPT ↝ SCANNER FOR LEXICAL ANALYSIS. ↝ PARSER

    FOR SYNTAX ANALYSIS. ↝ BINDER FOR SYMBOL CREATION AND SCOPE MANAGEMENT. ↝ TYPE CHECKER FOR SEMANTIC ANALYSIS. ↝ EMITTER FOR CODE GENERATION. ↝ TRANSFORMATION PIPELINE FOR AST TRANSFORMATIONS.
  25. COMPILERS: FRONT-END ↝ IT'S THE PART THAT READS THE SOURCE

    LANGUAGE AND PRODUCES A CHECKED, COMPILER-ORIENTED, REPRESENTATION. ↝ IT USUALLY CONTAINS LEXICAL ANALYSIS, PARSING, NAME RESOLUTION, AND SEMANTIC CHECKS. ↝ IT REPORTS SOURCE-LANGUAGE ERRORS WITH SOURCE LOCATIONS AND SUPPLIES THE REPRESENTATION CONSUMED BY LATER PHASES.
  26. COMPILERS: MIDDLE-END ↝ IT'S THE PART THAT ANALYZES AND TRANSFORMS

    INTERMEDIATE REPRESENTATIONS. ↝ ITS ANALYSES COMPUTE FACTS SUCH AS REACHABILITY, CONSTANTS, ALIASES, AND EFFECTS. ↝ ITS TRANSFORMATIONS SIMPLIFY, NORMALIZE, AND/OR OPTIMIZE THE PROGRAM.
  27. COMPILERS: BACK-END ↝ CONVERTS AN INTERMEDIATE REPRESENTATION INTO A TARGET-LANGUAGE

    REPRESENTATION. ↝ A NATIVE-CODE BACK-END SELECTS INSTRUCTIONS, ASSIGNS REGISTERS, AND EMITS MACHINE CODE. ↝ A SOURCE-TO-SOURCE BACK-END GENERATES SOURCE CODE IN ANOTHER LANGUAGE OR LANGUAGE VERSION.
  28. COMPILERS: LEXICAL ANALYSIS ↝ THE PROCESS OF RECOGNIZING TOKENS IN

    A SEQUENCE OF SOURCE CHARACTERS. ↝ A LEXER READS CHARACTERS AND EMITS TOKENS. ↝ A TOKEN RECORDS A TOKEN CATEGORY AND MAY CARRY A LEXEME, DECODED VALUE, SOURCE RANGE, AND MORE. ↝ LEXERS RECOGNIZE IDENTIFIERS, KEYWORDS, LITERALS, OPERATORS, AND PUNCTUATION.
  29. LEXEME ↝ THE EXACT SUBSTRING OF SOURCE TEXT RECOGNIZED AS

    ONE TOKEN. ↝ A LEXER CAN STORE BOTH THE ORIGINAL LEXEME "1E3" AND THE DECODED NUMERIC VALUE "1000". ↝ SOURCE-PRESERVING TOOLS USE LEXEMES AND SOURCE RANGES TO RETAIN THE AUTHOR’S SPELLING.
  30. TOKEN ↝ A TOKEN IS A CLASSIFIED UNIT PRODUCED BY

    LEXICAL ANALYSIS AND CONSUMED BY PARSING. ↝ A TOKEN HAS A CATEGORY (E.G. Identifier). ↝ A TOKEN CAN INCLUDE THE CORRESPONDING LEXEME AND SOURCE POSITION. ↝ A TOKEN STREAM GIVES THE PARSER A SEQUENCE OF CLASSIFIED SOURCE UNITS.
  31. COMPILERS: LEXICAL ANALYSIS LEXEME TOKEN CATEGORY CONST KEYWORD TOTAL IDENTIFIER

    = PUNCTUATOR/OPERATOR PRICE IDENTIFIER * PUNCTUATOR/OPERATOR 1.2 NUMERIC LITERAL ; PUNCTUATOR/OPERATOR
  32. GRAMMAR ↝ A FORMAL SET OF RULES THAT DESCRIBES THE

    VALID SYNTACTIC STRUCTURES OF A LANGUAGE. ↝ TERMINAL SYMBOLS = TOKENS ACCEPTED. ↝ NONTERMINAL SYMBOLS = LANGUAGE CONSTRUCTS SUCH AS EXPRESSIONS, STATEMENTS, AND DECLARATIONS. ↝ PRECEDENCE AND ASSOCIATIVITY RULES DETERMINE THE GROUPING OF OPERATORS.
  33. PARSER ↝ RECOGNIZES GRAMMATICAL STRUCTURE IN A TOKEN OR CHARACTER

    SEQUENCE. ↝ APPLIES THE LANGUAGE GRAMMAR TO DETERMINE HOW THE INPUT IS GROUPED. ↝ PRODUCES A CONCRETE SYNTAX TREE, ABSTRACT SYNTAX TREE, OR ANOTHER SYNTAX REPRESENTATION. ↝ RECORDS SYNTAX ERRORS.
  34. PARSER ↝ PROVES A GRAMMATICAL STRUCTURE BY USING A GRAMMAR

    AND PRECEDENCE AND ASSOCIATIVITY RULES. ↝ IT DOESN'T NORMALLY ANSWER… ↝ WHETHER A EXISTS ↝ WHAT B REFERS TO ↝ WHETHER MULTIPLYING B AND C IS TYPE-SAFE
  35. ABSTRACT SYNTAX TREE ↝ A TREE-SHAPED INTERMEDIATE REPRESENTATION OF THE

    LANGUAGE CONSTRUCTS IN A PROGRAM. ↝ EACH AST NODE REPRESENTS A CONSTRUCT SUCH AS A DECLARATION, STATEMENT, EXPRESSION, ETC. ↝ AST NODES COMMONLY STORE SOURCE RANGES, COMMENTS, AND PARSER-SPECIFIC METADATA NEEDED BY TOOLING. 🚨
  36. NODE KINDS ↝ THE CATEGORY ASSIGNED TO AN AST OR

    CST NODE BY THE TREE SCHEMA. ↝ DETERMINES WHICH FIELDS AND CHILD RELATIONSHIPS ARE VALID FOR THE NODE. ↝ A STATIC TYPE DESCRIBES THE VALUES AN EXPRESSION MAY PRODUCE OR ACCEPT. 🚨
  37. NODE KINDS ↝ Identifier (E.G. useState • props • Button)

    ↝ CallExpression • NewExpression ↝ JSXElement • JsxOpeningElement (E.G. <Button />) ↝ FunctionDeclaration • ArrowFunctionExpression ↝ ImportDeclaration • ExportNamedDeclaration ↝ ConditionalExpression • IfStatement 🚨
  38. SEMANTIC ANALYSIS ↝ THE PROCESS OF COMPUTING AND CHECKING PROGRAM

    PROPERTIES THAT DEPEND ON LANGUAGE MEANING. ↝ NAME RESOLUTION CONNECTS IDENTIFIER REFERENCES TO DECLARATIONS. ↝ MODULE RESOLUTION CONNECTS IMPORT SPECIFIERS TO SOURCE FILES AND DECLARATIONS. ↝ TYPE CHECKING VERIFIES OPERATIONS.
  39. SYMBOL ↝ A COMPILER DATA STRUCTURE THAT REPRESENTS A DECLARED

    PROGRAM ENTITY. ↝ IT CAN REPRESENT A VARIABLE, FUNCTION, CLASS, PROPERTY, MODULE, TYPE, OR NAMESPACE. ↝ IT LINKS DECLARATIONS AND REFERENCES THAT BELONG TO THE SAME ENTITY.
  40. TYPE CHECKER ↝ A SEMANTIC-ANALYSIS COMPONENT THAT ASSIGNS TYPES TO

    EXPRESSIONS AND VERIFIES TYPE RULES. ↝ IT READS AST NODES, SYMBOLS, DECLARATIONS, AND CONTROL-FLOW FACTS. ↝ A TYPE DESCRIBES AN APPROXIMATION OF THE VALUES AND OPERATIONS ASSOCIATED WITH A PROGRAM ENTITY.
  41. TYPE CHECKER ↝ TYPE INFERENCE COMPUTES TYPES FROM DECLARATIONS, EXPRESSIONS,

    AND CONTEXTUAL CONSTRAINTS. ↝ TYPE ERRORS REPORT OPERATIONS THAT VIOLATE THE TYPE SYSTEM.
  42. INTERMEDIATE REPRESENTATION ↝ A COMPILER-ORIENTED REPRESENTATION USED BETWEEN SOURCE PARSING

    AND FINAL TARGET EMISSION. ↝ DEFINES A VOCABULARY OF OPERATIONS AND A SET OF STRUCTURAL INVARIANTS. ↝ A COMPILER CAN USE SEVERAL IRs, WITH EACH REPRESENTATION SERVING DIFFERENT ANALYSES AND TRANSFORMATIONS.
  43. INTERMEDIATE REPRESENTATION ↝ A HIGH-LEVEL IR PRESERVES SOURCE-LANGUAGE OR DOMAIN

    CONCEPTS. ↝ A LOW-LEVEL IR MAKES CONTROL FLOW, DATA MOVEMENT, AND EXECUTION OPERATIONS EXPLICIT. ↝ LOWERING IS A TRANSFORMATION FROM A HIGHER-LEVEL REPRESENTATION TO A LOWER-LEVEL ONE, WITH MORE EXPLICIT OPERATIONS AND FEWER LANGUAGE CONSTRUCTS.
  44. TRAVERSAL ↝ THE PROCESS OF VISITING NODES OR BLOCKS IN

    A REPRESENTATION ACCORDING TO AN ORDER. ↝ A GRAPH TRAVERSAL USES A VISITED SET TO HANDLE JOINS AND CYCLES. ↝ TRAVERSAL ORDER DETERMINES WHEN PARENT, CHILD, PREDECESSOR, AND SUCCESSOR INFORMATION IS AVAILABLE. 🚨
  45. VISITOR ↝ SELECTS BEHAVIOR ACCORDING TO THE KIND OF NODE

    BEING VISITED. ↝ A VISITOR METHOD RECEIVES A NODE OR PATH AND THE STATE ASSOCIATED WITH THE CURRENT PASS. ↝ ENTER AND EXIT CALLBACKS RUN BEFORE AND AFTER VISITING CHILD NODES. 🚨
  46. CONTROL-FLOW GRAPH ↝ A DIRECTED GRAPH THAT REPRESENTS POSSIBLE TRANSFERS

    OF EXECUTION WITHIN A PROGRAM. ↝ CFG NODES REPRESENT BASIC BLOCKS OR INDIVIDUAL OPERATIONS. CFG EDGES REPRESENT POSSIBLE NEXT EXECUTION STEPS. ↝ CONTROL-FLOW ANALYSES USE THE CFG TO REASON ABOUT REACHABILITY, LIVENESS, DEFINITE ASSIGNMENT, AND AVAILABLE EXPRESSIONS.
  47. REACHABILITY ANALYSIS ↝ COMPUTES WHICH NODES IN A GRAPH CAN

    BE REACHED FROM A SELECTED SET OF ROOTS. ↝ THE ROOTS DEFINE THE STARTING NODES OF THE ANALYSIS. THE GRAPH EDGES DEFINE PERMITTED TRANSITIONS. ↝ CFG REACHABILITY IDENTIFIES EXECUTABLE BLOCKS. MODULE-GRAPH REACHABILITY IDENTIFIES MODULES AND EXPORTS REACHABLE FROM APPLICATION ENTRY POINTS.
  48. SOURCE MAP ↝ A MAPPING FROM LOCATIONS IN GENERATED CODE

    TO LOCATIONS IN ORIGINAL SOURCE FILES. ↝ DEBUGGERS USE SOURCE MAPS TO DISPLAY ORIGINAL SOURCE LOCATIONS WHILE EXECUTING GENERATED CODE. ↝ ERROR-REPORTING TOOLS USE SOURCE MAPS TO ATTRIBUTE GENERATED-CODE FAILURES TO AUTHORWRITTEN SOURCE. 🚨
  49. CODEMOD ↝ A PROGRAM THAT APPLIES A SOURCE-TO-SOURCE TRANSFORMATION ACROSS

    A COLLECTION OF FILES. ↝ IT SELECTS SOURCE LOCATIONS, CHECKS TRANSFORMATION PRECONDITIONS, CREATES EDITS, AND WRITES UPDATED SOURCE. ↝ COMMONLY USED TO MIGRATE APIS, RENAME DECLARATIONS, UPDATE IMPORTS, AND REPLACE DEPRECATED PATTERNS. 🚨
  50. #definition 🧐 jscodeshift is a tool that runs a transformation

    script fi over one or more JavaScript or TypeScript les.
  51. JSCODESHIFT: HELLO WORLD export default function transformer(file: FileInfo, api: API)

    { const j api.jscodeshift; const root j(file.source); const variableDeclarators root.findVariableDeclarators('foo'); variableDeclarators.renameTo('bar'); return root.toSource(); = = = }
  52. JSCODESHIFT: HELLO WORLD export default function transformer(file: FileInfo, api: API)

    { const j api.jscodeshift; const root j(file.source); const variableDeclarators root.findVariableDeclarators('foo'); variableDeclarators.renameTo('bar'); return root.toSource(); = = = }
  53. JSCODESHIFT: HELLO WORLD export default function transformer(file: FileInfo, api: API)

    { const j api.jscodeshift; const root j(file.source); const variableDeclarators root.findVariableDeclarators('foo'); variableDeclarators.renameTo('bar'); return root.toSource(); = = = }
  54. STATIC ANALYSIS ENABLED… GRADUAL ROLLOUT OF TWO ENTIRELY DIFFERENT, FEATURE

    -FLAG-PROTECTED, BUILDS OF THE SAME CODEBASE, WITH: ↝ DIFFERENT VERSIONS OF DEV DEPENDENCIES. ↝ DIFFERENT VERSIONS OF APP DEPENDENCIES. ↝ DIFFERENT STRATEGIES FOR BUNDLING AND SERVING.
  55. HYRUM'S LAW & ME — BASICS OF THE G2 +

    MEDALLIA INTEGRATION • G2 DOCUMENTATION
  56. CASE STUDY: FINDING PATTERNS const selector 'span.validation'; $(selector).each((_, element) const

    $element { $(element); if ($element.text().trim() === 'Required') { console.log('Pattern found: Required field'); } > = = = });
  57. CASE STUDY: FINDING PATTERNS const selector 'span.validation'; $(selector).each((_, element) const

    $element { $(element); if ($element.text().trim() === 'Required') { console.log('Pattern found: Required field'); } > = = = });
  58. STATIC ANALYSIS ENABLED… ↝ METRICS AROUND USER-GENERATED CONTENT BASED ON

    PLUGIN COMPOSITION. ↝ ACTUAL DATA IS THE SINGLE SOURCE OF TRUTH AND CONSISTENCY IS GUARANTEED ACROSS ALL API ENDPOINTS AND THE REACT APP. ↝ RAPID ITERATION WITH INSTANT TYPED APIS AND ENHANCED DX WHEN IMPLEMENTING NEW METRICS.
  59. TS-MORPH: HELLO WORLD BEFORE interface Welcome { } AFTER interface

    ApiResponse { the_user_data?: UserData; userData?: UserData; "api-version"?: string; apiVersion?: string; isActive?: boolean; isActive?: boolean; user_preferences?: any; userPreferences?: UserPreferences; }
  60. TS-MORPH: HELLO WORLD sourceFile.getInterfaces().forEach(iface { Convert snake_case to camelCase const

    newName toCamelCase(iface.getName()); iface.rename(newName); Transform properties iface.getProperties().forEach(prop const propName { prop.getName(); if (propName.includes('_') const camelName propName.includes('-')) { toCamelCase(propName.replace(/["-]/g, '_')); prop.rename(camelName); } Replace 'any' types with proper interfaces if (prop.getTypeNode()?.getText() === 'any') { prop.setType('UserPreferences'); } }); > = > = | | = = = / / / / / / });
  61. TS-MORPH: HELLO WORLD sourceFile.getInterfaces().forEach(iface { Convert snake_case to camelCase const

    newName toCamelCase(iface.getName()); iface.rename(newName); Transform properties iface.getProperties().forEach(prop const propName { prop.getName(); if (propName.includes('_') const camelName propName.includes('-')) { toCamelCase(propName.replace(/["-]/g, '_')); prop.rename(camelName); } Replace 'any' types with proper interfaces > = > = | | = = prop.setType('UserPreferences'); = / / / / / / if (prop.getTypeNode()?.getText() === 'any') {
  62. BREAKING CHANGES DETECTION ↝ THE RENDERED DOM (TAGS, CLASSES, ID,

    ETC.) IS A CUSTOMER CONTRACT. THEY WRITE CSS/JS AGAINST IT. ↝ WE NEED TO CATCH WHEN A PR CHANGES IT WITHOUT A HAND-MAINTAINED SELECTOR LIST. ↝ FOR THAT, WE CAN PARSE EVERY COMPONENT'S TSX/JSX AND WALK THE TREE TO EXTRACT A STRUCTURAL DOM CONTRACT: TAGS, RESOLVED CLASS TOKENS, ID/NAME…
  63. TYPESAFE DOM LOCATOR DSL ↝ QUALITY ASSURANCE TEAMS NEED STABLE

    SELECTORS TO AUTOMATE AGAINST, BUT HAND-WRITTEN LOCATORS IN TEST CODE OFTEN DRIFT FROM THE ACTUAL DOM. ↝ TO IMPROVE THIS, WE CAN SCAN THE ACTUAL SOURCE OF TRUTH (E.G. JSX + SCSS) AND GENERATE A LOCATOR DSL QE CONSUMES.
  64. TSRX: CONTEXT ↝ IN JSX, MANY UI INTENTIONS ARE ENCODED

    AS ARBITRARY JAVASCRIPT PATTERNS THAT COMPILERS HAVE TO GUESS FROM USAGE. ↝ E.G. items.map(…): A COMPILER ONLY SEES A METHOD CALL ON AN OBJECT. MAP COULD BE ARRAY MAPPING, SOME CUSTOM API BEHAVIOR, OR SOMETHING ELSE WITH SIDE EFFECTS.
  65. TSRX: OVERVIEW ↝ EXTENDS ACORN + TYPESCRIPT/JSX PARSING WITH ITS

    OWN NODES SUCH AS JSXIfExpression, JSXForExpression, JSXCodeBlock, JSXStyleElement, ETC. ↝ PERFORMS SEPARATE SEMANTIC ANALYSIS AND TRANSFORMATION PHASES.
  66. TSRX: OVERVIEW GENERIC JS AST CallExpression TEMPLATE-AWARE AST JSXForExpression callee:

    MemberExpression(items, map) source: items args: [ArrowFunctionExpression] binding: item key: item.id body: JSXElement(li)
  67. TSRX: STATEMENT CONTAINERS export function Profile({ user }: Props) @{

    const displayName const initials user.name.trim(); getInitials(displayName); <section> <Avatar initials={initials} /> <h2>{displayName}</h2> </section> = = }
  68. TSRX: STATEMENT CONTAINERS export function Profile({ user }: Props) @{

    const displayName const initials user.name.trim(); getInitials(displayName); <section> <Avatar initials={initials} /> <h2>{displayName}</h2> </section> = = }
  69. TSRX: CONTROL FLOW @if (user) { <Profile user={user} /> }

    @else { <LoginPrompt /> } @switch (status) { @case ("loading") { <Spinner /> } @case ("error") { <ErrorMessage /> } @default { <Content /> } }
  70. TSRX: CONTROL FLOW @if (user) { <Profile user={user} /> }

    @else { <LoginPrompt /> } @switch (status) { @case ("loading") { <Spinner /> } @case ("error") { <ErrorMessage /> } @default { <Content /> } }
  71. RADIUS TRACKER: OVERVIEW ↝ A STATIC ANALYSIS TOOL THAT TRACKS

    EVERY CONSUMPTION POINT OF REACT COMPONENTS ACROSS MULTIPLE CODEBASES WITHIN AN ORGANIZATION. ↝ IT GENERATES BOTTOM-UP ADOPTION REPORTS BY IDENTIFYING HOW COMPONENTS FROM SPECIFIC DESIGN SYSTEMS ARE USED, ALIASED, OR BYPASSED. ↝ IT ANSWERS TECHNICAL/BUSINESS QUESTIONS ON DESIGN SYSTEM HEALTH AND MIGRATION PROGRESS.
  72. RADIUS TRACKER: ARCHITECTURE ↝ IT USES TS-MORPH TO NAVIGATE THE

    TYPESCRIPT/ JAVASCRIPT AST, ALLOWING IT TO FOLLOW COMPONENTS ACROSS IMPORTS, EXPORTS, AND COMPLEX CODE PATTERNS (E.G. HOCS OR DESTRUCTURING). ↝ ITS ENGINE RUNS IN A MULTI-STAGE PIPELINE, ENDING WITH THE GENERATION OF A UsageStat ARRAY THAT DESCRIBES HOW DESIGN SYSTEM COMPONENTS ARE CONSUMED WITHIN A PROJECT.
  73. RADIUS TRACKER: IMPORTS/EXPORTS IMPORT TYPE SYNTAX EXAMPLE CODE ENTITY ESM

    DEFAULT import Button from "./Button" ESMImportDefault ESM NAMED import { Button } from "./UI" ESMImportNamed ESM NAMESPACE import * as UI from "./UI" ESMImportNamespace ESM EQUALS import val = require("mod") ESMImportEquals DYNAMIC await import("./Mod") ESMImportDynamic COMMONJS const Mod = require("./Mod") CJSImport
  74. RADIUS TRACKER: HOMEBREW DETECTION ↝ THIS PROCESS IDENTIFIES COMPONENTS CREATED

    IN THE CODEBASE THAT DO NOT ORIGINATE FROM A TRACKED DESIGN SYSTEM. IT CAN DISTINGUISH BETWEEN DESIGN SYSTEM USAGE AND CUSTOM/LEGACY IMPLEMENTATIONS. ↝ IT USES AST TRAVERSAL AND HEURISTICS TO IDENTIFY COMPONENT DECLARATIONS THAT DIRECTLY REFERENCE PRIMITIVE DOM ELEMENTS OR CSS-IN-JS FACTORIES.
  75. RADIUS TRACKER: HOMEBREW DETECTION CODE SNIPPET const MyComp = ()

    <div /> const Box = styled.div const Wrapper = () <OtherDSComp /> > = > = function util() { return 1 + 1 } DETECTED? REASON YES BUILT-IN LOWERCASE JSX YES STYLED-COMPONENTS (FACTORY) NO NO PRIMITIVE DOM ELEMENTS USED NO NOT A COMPONENT (NO JSX)
  76. ASTRO: OVERVIEW ↝ BY DEFAULT, SHIPS ZERO JAVASCRIPT. ↝ EVERY

    ISLAND IS LOADED IN PARALLEL. ↝ MULTI-FRAMEWORK: BUILD ISLANDS WITH REACT, PREACT, SVELTE, VUE, AND OTHERS. ↝ YOU CAN SPECIFY THE LOADING STRATEGY FOR EACH ISLAND INDIVIDUALLY.
  77. import MyReactComponent from ' . . - - - <MyReactComponent

    /> - - - ASTRO: ISLANDS /components/MyReactComponent.jsx';
  78. import MyReactComponent from ' /components/MyReactComponent.jsx'; <MyComponent client:load /> <MyComponent client:idle

    /> <MyComponent client:visible /> <MyComponent client:m edia={string} /> . . - - - <MyComponent client:only={string} /> - - - ASTRO: ISLANDS
  79. import MyReactComponent from ' /components/MyReactComponent.jsx'; <MyComponent client:m edia="(max-width: 20em)" />

    <MyComponent client:idle={{timeout: 200}} /> . . - - - <MyComponent client:visible={{rootMargin: "200px"}} /> - - - ASTRO: ISLANDS
  80. import MyReactComponent from ' /components/MyReactComponent.jsx'; <MyComponent client:m edia="(max-width: 20em)" />

    <MyComponent client:idle={{timeout: 200}} /> . . - - - <MyComponent client:visible={{rootMargin: "200px"}} /> - - - ASTRO: ISLANDS
  81. import MyReactComponent from ' /components/MyReactComponent.jsx'; <MyComponent client:m edia="(max-width: 20em)" />

    <MyComponent client:idle={{timeout: 200}} /> . . - - - <MyComponent client:visible={{rootMargin: "200px"}} /> - - - ASTRO: ISLANDS
  82. ASTRO: COMPILER RESPONSIBILITIES ↝ CSS SCOPING: APPLIES STRATEGIES TO ENSURE

    COMPONENT STYLES ARE ISOLATED. ↝ SCRIPT EXTRACTION: IDENTIFIES <script> TAGS THAT SHOULD BE HOISTED OR PROCESSED AS MODULES. ↝ HYDRATION DIRECTIVES: PROCESSES client:* DIRECTIVES TO IDENTIFY COMPONENTS THAT REQUIRE CLIENT-SIDE HYDRATION.
  83. ASTRO: COMPILER ⨯ HYDRATION THE COMPILER RECORDS: ↝ HYDRATED COMPONENTS:

    COMPONENTS WITH DIRECTIVES LIKE client:load. ↝ CLIENT-ONLY COMPONENTS: COMPONENTS WITH THE client:only DIRECTIVE. ↝ HYDRATION DIRECTIVES: RECORD OF ALL DIRECTIVES USED IN THE FILE.
  84. MITOSIS: INTERMEDIATE REPRESENTATION ↝ COMPONENT METADATA (name, imports, exports) ↝

    STATE MANAGEMENT (useState, useStore) ↝ LIFECYCLE HOOKS (onInit, onMount, etc.) ↝ CONTEXT (useContext) ↝ REFS (useRef) ↝ JSX TREE STRUCTURE (MitosisNode)
  85. MITOSIS: INTERMEDIATE REPRESENTATION FRAMEWORK STATE OPTIONS STYLING OPTIONS REACT useState

    • mobx • valtio • etc. STYLE TAG • emotion • styled-components • etc. VUE COMPOSITION API • OPTIONS API STYLE TAG • CSS MODULES ANGULAR SIGNALS API • CLASSIC API STYLE TAG • CSS MODULES QWIK useStore STYLE TAG • file splitting SOLID createSignal STYLE TAG • SOLID-STYLED-COMPONENTS SVELTE REACTIVE STATEMENTS STYLE TAG
  86. MITOSIS: TWO TOOLCHAINS ↝ @babel/core + @babel/traverse: SYNTAX-LEVEL AST MANIPULATION

    ⇢ “WHAT SHAPE IS THIS CODE?”. ↝ ts-morph: SEMANTIC ANALYSIS ⇢ “WHAT DOES THIS CODE MEAN/RESOLVE TO?”. ↝ BOTH ARE STATIC (NO CODE EXECUTION), BUT AT DIFFERENT LEVELS OF ABSTRACTION.
  87. MITOSIS: OVERVIEW ↝ DECOUPLING PARSING FROM GENERATION VIA A STATIC

    IR IS THE ENTIRE REASON MITOSIS CAN SUPPORT 20+ FRAMEWORKS FROM ONE SOURCE. ↝ STATIC ANALYSIS IS WHAT LETS THE IR CARRY SEMANTIC HINTS (E.G. REACTIVITY) THAT PURELYSYNTACTIC PARSING CAN'T CAPTURE.
  88. REACT DOCTOR: OVERVIEW ↝ A DIAGNOSTIC TOOL THAT ANALYZES REACT

    CODEBASES FOR SECURITY, PERFORMANCE, AND CORRECTNESS. ↝ IT SUPPORTS BOTH MANUAL USE BY DEVELOPERS AND AUTOMATED CONSUMPTION BY AI CODING AGENTS. ↝ @react-doctor/core DOES THE HEAVY LIFTING AND ORCHESTRATES THE ANALYSIS PIPELINE. IT LEVERAGES oxlint-plugin-react-doctor FOR HIGH-PERFORMANCE LINTING AND deslop-js FOR DEAD-CODE ANALYSIS.
  89. AST-GREP AGENT SKILLS: OVERVIEW ↝ A CLAUDE CODE PLUGIN DESIGNED

    TO EMPOWER AGENTS WITH STRUCTURAL CODE SEARCH CAPABILITIES. ↝ THE SKILL CONVERTS REQUESTS SUCH AS “FIND ASYNC FUNCTIONS THAT CALL THIS API WITHOUT ERROR HANDLING” INTO EXPLICIT STRUCTURAL CONDITIONS. ↝ IT EVALUATES THOSE CONDITIONS AGAINST TREESITTER SYNTAX NODES, MAKING MATCHES INDEPENDENT OF FORMATTING, INDENTATION, AND COMMENTS.
  90. AST-GREP AGENT SKILLS: OVERVIEW ↝ QUERIES CAN DESCRIBE A TARGET

    NODE TOGETHER WITH ITS DESCENDANTS, ANCESTORS, AND NEIGHBORING NODES. ↝ THE RESULT IS A REPEATABLE QUERY YOU CAN INSPECT, TEST, SAVE AS YAML, AND RUN ACROSS YOUR REPO.
  91. AST-GREP AGENT SKILLS: SEARCHING #2 rule: all: - kind: function_declaration

    - pattern: async function $$$($_) { $$$ } - not: has: kind: try_statement stopBy: end
  92. AST-GREP AGENT SKILLS: SEARCHING FEATURE TEXT SEARCH (GREP) STRUCTURAL SEARCH

    (AST-GREP) MATCHING UNIT LINES/STRINGS AST NODES AWARENESS LITERAL CHARACTERS SYNTAX, SCOPE, AND GRAMMAR FORMATTING SENSITIVE TO SPACES/NEWLINES AGNOSTIC TO FORMATTING COMPLEXITY LIMITED TO REGEX RELATIONAL & COMPOSITE LOGIC
  93. AST-GREP MCP SERVER: OVERVIEW ↝ THE CLIENT SENDS TYPED PARAMETERS

    CONTAINING CODE, PATTERNS, YAML RULES, LANGUAGE INFORMATION, AND OUTPUT CONTROLS. ↝ THE SERVER TRANSLATES EACH REQUEST INTO AST-GREP COMMAND-LINE ARGUMENTS AND EXECUTES AST-GREP AS A SUBPROCESS. ↝ THE SERVER ALSO INTERPRETS THE PROCESS OUTPUT AND RETURNS AN AGENT-ORIENTED RESULT.
  94. AST-GREP MCP SERVER: OVERVIEW TOOL PURPOSE PRIMARY USE CASE DUMP_SYNTAX_TREE

    VISUALIZE AST STRUCTURE DEBUGGING RULES AND UNDERSTANDING SYNTAX TEST_MATCH_CODE_RULE VALIDATE YAML RULES TESTING RULES BEFORE DEPLOYMENT FIND_CODE SIMPLE PATTERN SEARCH FINDING SINGLE AST NODE PATTERNS FIND_CODE_BY_RULE COMPLEX YAML RULE SEARCH ADVANCED RELATIONAL SEARCHES
  95. AST-GREP MCP SERVER: OVERVIEW ↝ STRUCTURAL SEARCH: FIND PROGRAMMING CONSTRUCTS

    (FUNCTIONS, CLASSES) REGARDLESS OF FORMATTING. ↝ ITERATIVE RULE DEVELOPMENT: AI CAN TEST RULES WITH test_match_code_rule() BEFORE APPLYING TO THE FULL CODEBASE. ↝ PATTERN DISCOVERY: AI CAN USE dump_syntax_tree() TO UNDERSTAND AST STRUCTURE BEFORE WRITING SEARCH PATTERNS.
  96. MILLION LINT: COMPILER function App({ start }) { const [count,

    setCount] useEffect(() useState(start); { console.log("double: ", count * 2); }, [count]); return <Button onClick={() setCount(count + 1)}>{count}</Button>; } > = = > = — MILLION LINT IS IN PUBLIC BETA • 2024
  97. MILLION LINT: COMPILER function App({ start }) { Million.capture({ start

    }); const [count, setCount] Million.capture(useState)(start); useEffect( () { console.log("double: ", count * 2); }, Million.capture([count]), ); return Million.capture( <Button onClick={() setCount(count + 1)}>{count}</Button>, ); } = > = > = — MILLION LINT IS IN PUBLIC BETA • 2024
  98. MILLION LINT: COMPILER [ 'src/App.jsx': { components: { [ App:

    { renders: [{ count: 7, time: 0.1 }, ], { kind: 'state', instances: 3, count: 7, count: 70, time: 0.1, time: 1, changes: [{ prev: 0, next: 8 }, location: [13, 0, 23, 1], ], } } ]; } } ]; . . . . . . — MILLION LINT IS IN PUBLIC BETA • 2024
  99. RIPPLE TS: OVERVIEW ↝ A UI FRAMEWORK THAT COMBINES FINE-GRAINED

    REACTIVITY WITH A MULTI-PHASE COMPILER TO DELIVER HIGH-PERFORMANCE WEB APPLICATIONS. ↝ ITS ARCHITECTURE HAS THREE PARTS: THE COMPILER + THE RUNTIME (CLIENT-SIDE REACTIVITY AND SSR) + DEVELOPER TOOLS. ↝ THE COMPILER TRANSFORMS .tsrx FILES INTO OPTIMIZED JS THAT CALLS RUNTIME APIS.
  100. RIPPLE TS: OVERVIEW ↝ THE COMPILER + STATIC ANALYSIS CAN

    IDENTIFY THE SHAPE OF THE REACTIVE PROGRAM AND PLACE UPDATE SITES. ↝ THE RUNTIME TRACKS ACTUAL DEPENDENCIES AND SCHEDULES UPDATES.
  101. RIPPLE TS: REACTIVITY MODEL ↝ RIPPLE USES FINE-GRAINED REACTIVITY WITHOUT

    VIRTUAL DOM. IT RELIES ON A GLOBAL CLOCK AND DEPENDENCY TRACKING TO UPDATE ONLY WHAT CHANGED. ↝ WHEN A Tracked VALUE IS UPDATED VIA A SETTER, IT MARKS THE ASSOCIATED Block HIERARCHY AS DIRTY. ↝ THE SCHEDULER FLUSHES THESE UPDATES, TRIGGERING SPECIFIC DOM UPDATE PRIMITIVES (LIKE set_text OR set_attribute) ONLY FOR THE AFFECTED NODES.
  102. RIPPLE TS: REACTIVITY MODEL let &[count, countRef] count; count track(0);

    read from tracked state 10; write into tracked state = / / / / / / explicit reactive identity when needed / countRef; / read-modify-write = count++;
  103. RIPPLE TS: COMPILER RESPONSIBILITIES ↝ PARSING: HANDLES THE COMPONENT KEYWORD,

    REACTIVE PREFIXES, AND TRACKED COLLECTION LITERALS. ↝ ANALYSIS: BUILDS SCOPE CHAINS, RESOLVES BINDING OBJECTS, AND VALIDATES RULES. ↝ TRANSFORMATION: TEMPLATES ARE TRANSFORMED INTO OPTIMIZED DOM INSTRUCTIONS. IN SERVER, IT PUSHES STATIC STRINGS AND DYNAMIC EXPRESSIONS INTO THE SSR OUTPUT BUFFER.
  104. MILLION.JS: OVERVIEW ↝ TWO KEY COMPONENTS: THE VIRTUAL DOM RUNTIME

    AND THE OPTIMIZING COMPILER. ↝ VIRTUAL DOM RUNTIME: UPDATES THE UI, SIMILAR TO EXISTING VIRTUAL DOM LIBRARIES. ↝ OPTIMIZING COMPILER: ANALYZES JAVASCRIPT AND COMPUTES UNNECESSARY WORK DURING COMPILE TIME TO REDUCE LOAD TIME AND SPEED UP RENDERING.
  105. MILLION.JS: HYPERSCRIPT ↝ THE COMPILER OUTPUTS HYPERSCRIPT, A LOW-LEVEL REPRESENTATION

    OF FUNCTION CALLS THAT CONSTRUCT A VIRTUAL NODE TREE AT RUNTIME. ↝ HYPERSCRIPT SERVES AS AN IDEAL INTERMEDIATE FORMAT DUE TO ITS SIMPLICITY.
  106. MILLION.JS: VIRTUAL NODE FLATTENING ↝ THE COMPILER EMPLOYS AN APPROACH

    THAT TRANSFORMS HYPERSCRIPT FUNCTION CALLS INTO A FLATTENED STRUCTURE. ↝ THIS OPTIMIZATION REDUCES THE MEMORY ALLOCATION REQUIRED DURING RUNTIME BY ELIMINATING FUNCTION CALL NESTING.
  107. MILLION.JS: VIRTUAL NODE FLATTENING ↝ ADDITIONALLY, COMPILER FLAGS ARE ASSIGNED

    TO THE FLATTENED NODES, ENABLING FINE-GRAINED CONTROL OVER RUNTIME COMPUTATIONS. ↝ THIS IS SIMILAR TO THE OPTIMIZATIONS IMPLEMENTED IN INFERNO, TARGETING REDUCED COMPUTATIONAL OVERHEAD DURING RENDERING.
  108. MILLION.JS: VIRTUAL NODE FLATTENING { tag: 'div', h('div', null, 'Hello

    World'); children: ['Hello World'], flag: Flags.ONLY_TEXT_CHILDREN }
  109. MILLION.JS: VIRTUAL NODE FLATTENING { tag: 'div', h('div', null, 'Hello

    World'); children: ['Hello World'], flag: Flags.ONLY_TEXT_CHILDREN }
  110. MILLION.JS: STATIC TREE HOISTING ↝ TO MINIMIZE UNNECESSARY RUNTIME MEMORY

    ALLOCATION, IT EXTRACTS HYPERSCRIPT STRUCTURES THAT ARE INDEPENDENT OF STATE CHANGES AND RELOCATES THEM TO THE GLOBAL JAVASCRIPT SCOPE. ↝ BY SEPARATING STATIC ELEMENTS FROM DYNAMIC ONES, THIS OPTIMIZATION ENSURES THAT NON-DYNAMIC CONTENT IS PRECOMPUTED AND REUSED EFFICIENTLY, REDUCING THE LOAD ON RUNTIME OPERATIONS.
  111. REACT COMPILER: OVERVIEW ↝ IMPROVE THE RENDERING PERFORMANCE BY AUTOMATICALLY

    GENERATING THE EQUIVALENT OF useMemo, useCallback, AND memo CALLS. ↝ MINIMIZE THE COST OF RE-RENDERING WHILE RETAINING REACT’S PROGRAMMING MODEL. ↝ AUTOMATIC OPTIMIZATION COMPILER.
  112. ALIAS ANALYSIS: OVERVIEW ↝ IT'S A CLASS OF TECHNIQUES THAT

    ATTEMPT TO DETERMINE IF VARIABLES REFER TO THE SAME UNDERLYING DATA. ↝ IT HELPS COMPILERS GENERATE EFFICIENT AND OPTIMIZED CODE.
  113. ALIAS ANALYSIS: OVERVIEW function example(arr) { arr[0] 10; const value

    = arr[0]; return value; = } DOES VALUE ALWAYS EQUAL 10?
  114. ALIAS ANALYSIS: EX. #1 function Component({ a, b }) {

    function Component({ a, b }) { const x = []; x.push(a); return <Foo x={x} />; } } > — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  115. ALIAS ANALYSIS: EX. #1 function Component({ a, b }) {

    const x = useMemo(() function Component({ a, b }) { { const x = []; x.push(a); return x; }, [a]); } return <Foo x={x} />; } > = — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  116. ALIAS ANALYSIS: EX. #1 function Component({ a, b }) {

    function Component({ a, b }) { ✅ } } > — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  117. ALIAS ANALYSIS: EX. #2 function Component({ a, b }) {

    function Component({ a, b }) { const x = []; x.push(a); const y = x; y.push(b); return <Foo x={x} />; } } > > — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  118. ALIAS ANALYSIS: EX. #2 function Component({ a, b }) {

    function Component({ a, b }) { const x = useMemo(() { const x = []; x.push(a); return x; }, [a]); const y = useMemo(() { const y = x; y.push(b); return y; }, [x, b]); return <Foo x={x} />; } } > > = = — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  119. ALIAS ANALYSIS: EX. #2 function Component({ a, b }) {

    function Component({ a, b }) { const x = []; x.push(a); ❌ const y = x; y.push(b); return <Foo x={x} />; } } > > — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  120. ALIAS ANALYSIS: EX. #2 function Component({ a, b }) {

    function Component({ a, b }) { const x = useMemo(() { const x = []; x.push(a); const y = x; y.push(b); return y; }, [a, b]); return <Foo x={x} />; } } > = — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  121. ALIAS ANALYSIS: EX. #2 function Component({ a, b }) {

    function Component({ a, b }) { const x = useMemo(() => { const x = []; x.push(a); const y = x; y.push(b); return y; ✅ }, [a, b]); return <Foo x={x} />; } } — ALIAS ANALYSIS IN THE REACT COMPILER • SATHYA GUNASEKARAN, 2024
  122. SSA FORM: OVERVIEW ↝ A TECHNIQUE WHERE EVERY VARIABLE HAS

    A SINGLE DEFINITION. MAINTAINING USE-DEFINED CHAINS IS EASIER, SINCE FOR EVERY USE, YOU HAVE TO KEEP TRACK OF ONLY ONE DEFINITION. ↝ THE SIMPLIFIED STRUCTURE ENABLES MORE POWERFUL AND EFFICIENT OPTIMIZATION TECHNIQUES.
  123. SSA FORM: OVERVIEW BEFORE AFTER x = y - z

    x = y - z s = x + s s2 = x + s x = s + p x2 = s2 + p s = z * q s3 = z * q s = x * s s4 = x2 * s3
  124. SSA FORM: OVERVIEW BEFORE AFTER x = y - z

    x = y - z s = x + s s2 = x + s x = s + p x2 = s2 + p s = z * q s3 = z * q s = x * s s4 = x2 * s3
  125. SSA FORM: REACT function Component(props) { const $ = useMemoCache(2);

    const { colors } = props; let t0; if ($[0] function Component({ colors }) { colors) { t0 = { colors }; let styles = { colors }; $[0] = colors; return <Item styles={styles} />; $[1] = t0; } } else { t0 = $[1]; } const styles = t0; return <Item styles={styles} />; } = = ! — COMPILER THEORY AND REACTIVITY • SATHYA GUNASEKARAN, 2024
  126. GOTCHAS #1: BROKEN RULES OF REACT const Component useEffect(() ({currentValue,

    onValueChange}) { onValueChange(currentValue) }, currentValue); > = > = = }; {
  127. GOTCHAS #1: BROKEN RULES OF REACT export default function usePrevious<T>(state:

    T): T | undefined { const ref useRef<T>(); useEffect(() ref.current { state; }); return ref.current; = > = = }
  128. GOTCHAS #2: INTERPOLATIONS ↝ TAILWIND DOESN'T PARSE OR EXECUTE ANY

    OF THE CODE. IT USES REGULAR EXPRESSIONS TO EXTRACT EVERY STRING THAT COULD POSSIBLY BE A CLASS NAME. ↝ IT WILL ONLY FIND CLASSES THAT EXIST AS COMPLETE UNBROKEN STRINGS. ↝ YOU CAN'T CONSTRUCT CLASS NAMES DYNAMICALLY.
  129. PREPACK: OVERVIEW ↝ A PARTIAL EVALUATOR THAT RUNS CODE AOT

    AND GENERATES CODE THAT CAPTURES THE RESULT OF COMPUTATIONS THAT CAN BE PERFORMED IN ADVANCE. ↝ IT TRANSFORMS JAVASCRIPT CODE THROUGH ABSTRACT INTERPRETATION, CONCRETE EVALUATION, AND SERIALIZATION TO PRODUCE OPTIMIZED OUTPUT. ↝ META BUILT IT TO IMPROVE JAVASCRIPT PERFORMANCE FOR WEB APPLICATIONS.
  130. INFERNO.JS: OVERVIEW ↝ THE COMPILER CREATES MONOMORPHIC createVNode CALLS, INSTEAD

    OF createElement CALLS; OPTIMIZING THE RUNTIME PERFORMANCE OF THE APPLICATION. ↝ SPECIAL JSX FLAGS CAN BE USED DURING COMPILE TIME TO OPTIMIZE RUNTIME PERFORMANCE AT THE APPLICATION LEVEL.
  131. INFERNO.JS: CHILD FLAGS function StaticComponent(props) { return <div>Hello world!<div> }

    function StaticComponent(props) { return <div>{data}<div> } function StaticComponent(props) { return <div $HasNonKeyedChildren>{unknown}<div> }
  132. INFERNO.JS: CHILD FLAGS function StaticComponent(props) { return <div>Hello world!<div> }

    function StaticComponent(props) { return <div>{data}<div> } function StaticComponent(props) { return <div $HasNonKeyedChildren>{unknown}<div> }
  133. INFERNO.JS: CHILD FLAGS function StaticComponent(props) { return <div>Hello world!<div> }

    function StaticComponent(props) { return <div>{data}<div> } function StaticComponent(props) { return <div $HasNonKeyedChildren>{unknown}<div> }
  134. INFERNO.JS: OVERVIEW import { createTextVNode, render, Component } from 'inferno';

    class MyComponent extends Component { constructor(props) { super(props); this.state = { counter: 0 }; } _getText() { return 'Hello!'; } render() { const node = this.state.counter > 0 ? <div>0</div> : <span $HasTextChildren>{this._getText()}</span>; return ( <div> <h1>Header!</h1> <div $HasVNodeChildren>{node}</div> </div> ); } }
  135. INFERNO.JS: OVERVIEW import { createTextVNode, render, Component } from 'inferno';

    class MyComponent extends Component { constructor(props) { super(props); this.state = { counter: 0 }; } _getText() { return 'Hello!'; } render() { const node = this.state.counter > 0 ? <div>0</div> : <span $HasTextChildren>{this._getText()}</span>; return ( <div> <h1>Header!</h1> <div $HasVNodeChildren>{node}</div> </div> ); } }
  136. SOLID.JS: TRANSFORMATIONS #1 INPUT function Counter() { const [count, setCount]

    const increment () createSignal(1); setCount(count() + 1); return ( <button type="button" onClick={increment}> {count()} </button> ); = > = = }
  137. SOLID.JS: TRANSFORMATIONS #1 INPUT function Counter() { { const [count,

    setCount] const increment OUTPUT (REACT JSX) () createSignal(1); type: 'button', setCount(count() + 1); props: { return ( children: 1 <button type="button" onClick={increment}> {count()} } </button> ); = > = } = }
  138. SOLID.JS: TRANSFORMATIONS #1 INPUT function Counter() { { const [count,

    setCount] const increment OUTPUT (REACT JSX) () createSignal(1); type: 'button', setCount(count() + 1); props: { return ( children: () <button type="button" onClick={increment}> {count()} } </button> ); = > = = > } = } count()
  139. SOLID.JS: TRANSFORMATIONS #1 INPUT function Counter() { function Counter() {

    const [count, setCount] const increment OUTPUT (REACT JSX) () createSignal(1); const [count, setCount] setCount(count() + 1); const increment return ( return (() <button type="button" onClick={increment}> button.onclick </button> })(); = = > > = > = = = = = = } > } = document.createElement("button"); increment; insert(button, () ); setCount(count() + 1); { const button {count()} () createSignal(1); count())
  140. SOLID.JS: TRANSFORMATIONS #1 INPUT function Counter() { function Counter() {

    const [count, setCount] const increment OUTPUT (APPROX.) () createSignal(1); const [count, setCount] setCount(count() + 1); const increment return ( return (() <button type="button" onClick={increment}> button.onclick </button> })(); = = > > = > = = = = = = } > } = document.createElement("button"); increment; insert(button, () ); setCount(count() + 1); { const button {count()} () createSignal(1); count())
  141. SOLID.JS: TRANSFORMATIONS #1 INPUT import { template as _$template }

    from "solid-js/web"; function Counter() { import { delegateEvents as _$delegateEvents } from "solid-js/web"; const [count, setCount] const increment OUTPUT (ACTUAL) () createSignal(1); setCount(count() + 1); import { createComponent as _$createComponent } from "solid-js/web"; import { insert as _$insert } from "solid-js/web"; const _tmpl$ / # PURE /_$template(`<button type="button">`); import { createSignal } from "solid-js"; return ( <button type="button" onClick={increment}> import { render } from “solid-js/web"; function Counter() { {count()} const [count, setCount] </button> const increment return (() ); setCount(count() + 1); { const _el$ _el$.$$click } () createSignal(1); _tmpl$(); increment; _$insert(_el$, count); return _el$; })(); } render(() _$createComponent(Counter, {}), document.getElementById("app")); = > = = = * _ _ > = _ _ = = * = > = = > = _$delegateEvents([“click"]);
  142. SOLID.JS: TRANSFORMATIONS #2 const view ({ item }) const itemId

    { item.id; return <tr class={itemId === selected() ? "danger" : ""}> <td class="col-md-1">{itemId}</td> <td class="col-md-4"> <a onclick={e select(item, e)}>{item.label}</a> </td> <td class="col-md-1"> <a onclick={e del(item, e)}> <span class="glyphicon glyphicon-remove" aria-hidden="true"></span> </a> </td> <td class="col-md-6"></td> </tr>; > = > > = = = = };
  143. SOLID.JS: TRANSFORMATIONS #2 import { template as _$template } from

    "solid-js/web"; import { delegateEvents as _$delegateEvents } from "solid-js/web"; import { createComponent as _$createComponent } from "solid-js/web"; import { className as _$className } from "solid-js/web"; import { effect as _$effect } from "solid-js/web"; import { insert as _$insert } from "solid-js/web"; const _tmpl$ / # PURE /_$template(`<tr><td class="col-md-1"></td><td class="col-md-4"><a></a></td><td class="col-md-1"><a><span class="glyphicon glyphicon- remove" aria-hidden="true"></span></a></td><td class="col-md-6"></td></tr>`, 16); const view ({ item }) { const itemId item.id; return (() { const _el$ _tmpl$.cloneNode(true), _el$2 _el$.firstChild, _el$3 _el$2.nextSibling, _el$4 _el$3.firstChild, _el$5 _el$3.nextSibling, _el$6 _el$5.firstChild; _$insert(_el$2, itemId); _el$4.$$click e select(item, e); _$insert(_el$4, () item.label); _el$6.$$click e del(item, e); _$effect(() _$className(_el$, itemId === selected() ? "danger" : "")); return _el$; })(); }; * _ _ > = > > = = _ _ = = > * = = = > = = = = = = = = > = _$delegateEvents(["click"]);
  144. SOLID.JS: TRANSFORMATIONS #2 import { template as _$template } from

    "solid-js/web"; import { delegateEvents as _$delegateEvents } from "solid-js/web"; import { createComponent as _$createComponent } from "solid-js/web"; import { className as _$className } from "solid-js/web"; import { effect as _$effect } from "solid-js/web"; import { insert as _$insert } from "solid-js/web"; const _tmpl$ / # PURE /_$template(`<tr><td class="col-md-1"></td><td class="col-md-4"><a></a></td><td class="col-md-1"><a><span class="glyphicon glyphicon- remove" aria-hidden="true"></span></a></td><td class="col-md-6"></td></tr>`, 16); const view ({ item }) { const itemId item.id; return (() { const _el$ _tmpl$.cloneNode(true), _el$2 _el$.firstChild, _el$3 _el$2.nextSibling, _el$4 _el$3.firstChild, _el$5 _el$3.nextSibling, _el$6 _el$5.firstChild; _$insert(_el$2, itemId); _el$4.$$click e select(item, e); _$insert(_el$4, () item.label); _el$6.$$click e del(item, e); _$effect(() _$className(_el$, itemId === selected() ? "danger" : "")); return _el$; })(); }; * _ _ > = > > = = _ _ = = > * = = = > = = = = = = = = > = _$delegateEvents(["click"]);
  145. SOLID.JS: TRANSFORMATIONS #4 <MyComponent static={/ @once / state.wontUpdate} /> <MyComponent>{/

    @once / state.wontUpdate}</MyComponent> <div style={{ width: / @once / props.width, height: / @once / props.height, color: props.color, * * * * * * * * }} />
  146. SVELTE: OVERVIEW ↝ TRACKS VARIABLES AND DETERMINES THEIR SCOPES. ↝

    IDENTIFIES DEPENDENCIES AND DETECTS REACTIVE STATEMENTS AND EVENT HANDLERS. ↝ SCOPES STYLES TO COMPONENTS AND OPTIMIZES CSS FOR PERFORMANCE. …AND MUCH MORE!
  147. SVELTE 3 + 4: $$invalidate ↝ EVERY VARIABLE THAT HAS

    BEEN REASSIGNED OR MUTATED AND REFERENCED IN THE TEMPLATE WILL HAVE THE $$invalidate FUNCTION INSERTED RIGHT AFTER THE ASSIGNMENT OR MUTATION. ↝ IT MARKS THE VARIABLE DIRTY AND SCHEDULES AN UPDATE FOR THE COMPONENT.
  148. MARKO: OVERVIEW ↝ FINE-GRAINED COMPILE-TIME REACTIVITY: A HYBRID BETWEEN SVELTE

    + ITS COMPILER AND FINE-GRAINED REACTIVITY FOUND IN LIBRARIES LIKE VUE, SOLID, OR MOBX. ↝ SPLITS A COMPONENT INTO MULTIPLE FUNCTIONS: ONE FOR EACH REACTIVE ATOM THAT WHEN EXECUTED WITH A NEW VALUE CONDITIONALLY CALLS ANY DOWNSTREAM WORK. — FLUURT: RE-INVENTING MARKO • RYAN CARNIATO
  149. MARKO: OVERVIEW ↝ THESE FUNCTIONS ARE EXPORTED SO THAT PARENT

    CONSUMERS OF THE COMPONENT CAN SELECTIVELY IMPORT THE METHODS THEY NEED IF THE DATA THEY PASS IN IS DYNAMIC. ↝ COMPILES AWAY ANY NOTION OF REACTIVITY AND COMPONENTS. — FLUURT: RE-INVENTING MARKO • RYAN CARNIATO
  150. MARKO: DOM NODES export const template <attrs/{ a, b }

    /> <div>${a} + ${b} ${a + b}</div> export const walks ="D%c%c%l"; export function apply_a(scope, a) { if (scope.a scope.a <Sum a=10 b=5 /> scope.text0.data applyWith_a_b(scope); } } export function apply_b(scope, b) { if (scope.b scope.b scope.text1.data applyWith_a_b(scope); } } function applyWith_a_b({ text2, a, b }) { text2.data } = = = = = = = = = — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  151. MARKO: DOM NODES <attrs/{ a, b } /> export const

    template "<div><!> + <!> <!></div>"; export const walks ="D%c%c%l"; <div>${a} + ${b} export function apply_a(scope, a) { if (scope.a scope.a <Sum a=10 b=5 /> a) { a; scope.text0.data a; applyWith_a_b(scope); } } export function apply_b(scope, b) { if (scope.b scope.b b) { b; scope.text1.data b; applyWith_a_b(scope); } } function applyWith_a_b({ text2, a, b }) { text2.data a + b; } = = = = = = = = = ! ! = = = — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  152. MARKO: DOM NODES export const template "<div><!> + <!> <!></div>";

    ENCODED DOM WALKS. export const walks ="D%c%c%l"; export function apply_a(scope, a) { if (scope.a scope.a a) { a; scope.text0.data a; applyWith_a_b(scope); } } export function apply_b(scope, b) { if (scope.b scope.b b) { b; scope.text1.data b; applyWith_a_b(scope); } } function applyWith_a_b({ text2, a, b }) { text2.data a + b; } = = = = = = = = ! ! = = = — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  153. MARKO: COMPONENT INPUTS export const template "<div><!> + <!> <!></div>";

    export const walks ="D%c%c%l"; <attrs/{ a, b } /> export function apply_a(scope, a) { if (scope.a scope.a a) { <div>${a} + ${b} a; scope.text0.data a; ${a + b}</div> applyWith_a_b(scope); } <Sum a=10 b=5 /> } export function apply_b(scope, b) { if (scope.b scope.b b) { b; scope.text1.data b; applyWith_a_b(scope); } } function applyWith_a_b({ text2, a, b }) { text2.data a + b; } = = = = = = = = = ! ! = = = — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  154. MARKO: COMPONENT INPUTS export const template "<div><!> + <!> <!></div>";

    export const walks ="D%c%c%l"; export function apply_a(scope, a) { if (scope.a scope.a a) { a; scope.text0.data a; applyWith_a_b(scope); } } <attrs/{ a, b } /> export function apply_b(scope, b) { if (scope.b scope.b b) { <div>${a} + ${b} b; scope.text1.data b; ${a + b}</div> applyWith_a_b(scope); } } <Sum a=10 b=5 /> function applyWith_a_b({ text2, a, b }) { text2.data a + b; } = = = = = = = = = ! ! = = = — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  155. MARKO: COMPONENT INPUTS export const template "<div><!> + <!> <!></div>";

    export const walks ="D%c%c%l"; export function apply_a(scope, a) { if (scope.a scope.a a) { a; scope.text0.data a; applyWith_a_b(scope); } } export function apply_b(scope, b) { if (scope.b scope.b b) { b; scope.text1.data b; applyWith_a_b(scope); <attrs/{ a, b } /> } } function applyWith_a_b({ text2, a, b }) { text2.data <div>${a} + ${b} a + b; } = = = = = = = = = ! ! = = = <Sum a=10 b=5 /> ${a + b}</div>
  156. MARKO: SCOPE export const template "<div><!> + <!> export const

    walks ="D%c%c%l"; export function apply_a(scope, a) { if (scope.a scope.a a) { a; scope.text0.data a; applyWith_a_b(scope); } } export function apply_b(scope, b) { if (scope.b scope.b b) { b; scope.text1.data b; applyWith_a_b(scope); } } function applyWith_a_b({ text2, a, b }) { text2.data a + b; = = = = = = = = ! ! = = = } <!></div>";
  157. MARKO: EVENTS <let/x=10 /> import { apply_a } from "./Sum.marko"

    <let/y=5 /> export function click1(scope) { <Sum a=x b=y /> <button onClick() { x++ }>Increment X</button> apply_x(scope, scope.x + 1); } export function apply_x(scope, x) { if (scope.x apply_a(scope); } } = — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  158. MARKO: EVENTS <let/x=10 /> import { apply_a } from "./Sum.marko"

    <let/y=5 /> export function click1(scope) { <Sum a=x b=y /> <button onClick() { x++ }>Increment X</button> apply_x(scope, scope.x + 1); } export function apply_x(scope, x) { if (scope.x x) { apply_a(scope); } } = = ! — MARKO: COMPILING FINE-GRAINED REACTIVITY • RYAN CARNIATO
  159. Database, file, and socket access from JavaScript <script runat="server"> var

    resultSet Jaxer.DB.execute("SELECT * FROM myTable"); var newPrice resultSet.rows[0].price; </script> Directly call server-side functions from the browser <script runat="server-proxy"> function getPriceFromServer() { return 42; } </script> <button onclick="alert(getPriceFromServer())">Price</button> Share validation code on the browser and server <script runat="both"> function validateCreditCard(number) {} > - - > - - > - - = = - - - - - - ! ! </script> ! < < < JAXER: CODE EXTRACTION
  160. Database, file, and socket access from JavaScript <script runat="server"> var

    resultSet Jaxer.DB.execute("SELECT * FROM myTable"); var newPrice resultSet.rows[0].price; </script> Directly call server-side functions from the browser <script runat="server-proxy"> function getPriceFromServer() { return 42; } </script> <button onclick="alert(getPriceFromServer())">Price</button> Share validation code on the browser and server <script runat="both"> function validateCreditCard(number) {} > - - > - - > - - = = - - - - - - ! ! </script> ! < < < JAXER: CODE EXTRACTION
  161. V8 & COMPILERS TWO EXAMPLES: ↝ MAGLEV: GETS TYPE FEEDBACK

    FROM THE INTERPRETER AND RUNS QUICK OPTIMIZATIONS. ↝ TURBOFAN: TRANSLATES BYTE-CODE INTO HIGHLY OPTIMIZED MACHINE CODE, USING SEA OF NODES (SON) AND CONTROL-FLOW GRAPH (CFG) IR.
  162. JAVASCRIPTCORE & COMPILERS TWO EXAMPLES: ↝ DFG JIT: BUILDS A

    DATA-FLOW GRAPH IR, USES PROFILING TO SPECIALIZE TYPES, REMOVE CHECKS, AND MORE, BUT WITH MODERATE COMPILE COST. ↝ FTL JIT: USES MULTIPLE IR (INCLUDING B3 AND LLVM) FOR AGGRESSIVE OPTIMIZATIONS AND HIGHER THROUGHPUT FOR HOT CODE.
  163. COMPILERS & STATIC ANALYSIS FOR JAVASCRIPT DEVELOPERS Tooling becomes reliable

    when it #0 chooses a of n representation that preserves the distinctions needed for the question.
  164. COMPILERS & STATIC ANALYSIS FOR JAVASCRIPT DEVELOPERS Compilers are no

    #0 longer just for of n systems programming.
  165. COMPILERS & STATIC ANALYSIS FOR JAVASCRIPT DEVELOPERS AI Agents Can

    Write React. But Engineers #0 Who Understand Scheduling, of n Rendering, and DataFlow Boundaries Can Decide What Should Be Optimized.
  166. COMPILERS & STATIC ANALYSIS FOR JAVASCRIPT DEVELOPERS Internals Matter More

    in the AI Era. #0 Compilers Automate of n Optimizations. Agents Automate Code. Only Engineers Understand ff Tradeo s.
  167. COMPILERS & STATIC ANALYSIS FOR JAVASCRIPT DEVELOPERS THAT’S ALL, FOLKS!

    GRACIAS! 👋 🇪🇸 QUESTIONS? MATHEUS ALBUQUERQUE • @ythecombinator