Running Node.js in the browser 🔗 **Source:** [Running Node.js in the browser](https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/) > [!note]+ Document Notes > tags: [WordPress, Node.js, Gutenberg] > author: [MISSING] > source: Adam's Perspective > reference: [https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/] > date created: 2025-10-11 00:00 > > # 🏷️ Title: Running Node.js in the browser > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: A working prototype runs Node.js tooling (npm, webpack) in the browser by loading Node’s JS standard library and polyfilling internal bindings, aiming to enable building Gutenberg blocks fully in-browser. - Why it matters: Unlocks @wordpress/scripts in the browser to compile JSX-based blocks without local Node installs, accelerating WordPress Playground use cases. - Key stakeholders: WordPress block developers, WordPress Playground maintainers, education and training programs, hosting-constrained users. - Risks and tradeoffs: Missing features (child_process, workers, shared FS), performance/compatibility nuances; not compiling Node to WASM to avoid size/complexity penalties. - Bottom line: “Promising, but there’s still a long way to go”—useful proof-of-concept, paused while Playground priorities (Xdebug, phpMyAdmin) ship. ## 📖 Main Content - Core idea: “Node.js programs are just JavaScript… We can take advantage of that!” The author loads Node’s JS stdlib in the browser and polyfills “internalBinding” surfaces to satisfy modules like fs, enabling npm/webpack. - Context/terms: - Gutenberg blocks: typically built with JSX and compiled via @wordpress/scripts (webpack, Babel) into JS/CSS/PHP assets. - Alternative avoided: compiling V8/libuv/Node to WASM—too heavy, slower, complex. - Uncertainties: - Completeness of polyfills for nuanced Node stdlib behaviors used by ecosystem tools. - Multi-worker, process, and shared FS constraints for real-world builds. ### 🗒️ Notes - “It can already run npm, webpack, and more.” - Why Node for blocks: WordPress docs encourage JSX + @wordpress/scripts, which “use webpack, babel… to replace import { Paragraph } from '@wordpress/blocks' with window.wp.blocks.Paragraph.” - Not WASM: Native Node is ~80MB; static WASM likely larger and slower (“JS VM inside a JS VM”). - Approach: Load Node’s JS stdlib; polyfill internalBinding surfaces (e.g., fs → internalBinding('fs').rmdir()) and globals; then run common packages. - Tried and moved past: browserify-like stdlib reimplementations lacked nuanced behaviors needed by npm and friends. - Gaps to production: - child_process (spawning) - workers/worker_threads - Filesystem shared across workers - Shared FS with WordPress Playground - Priority shift: Paused to finalize Xdebug, phpMyAdmin, and other Playground work. ## 📚 References - Node.js standard library design (internalBinding): https://nodejs.org/api/ - child_process docs: https://nodejs.org/api/child_process.html - worker_threads docs: https://nodejs.org/api/worker_threads.html - @wordpress/scripts: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/ - Webpack: https://webpack.js.org/ - Babel: https://babeljs.io/ - npm: https://www.npmjs.com/ - WordPress Playground: https://developer.wordpress.org/playground/ - Prototype repo (mentioned): https://github.com/adamziel/node-js-in-the-browser - V8: https://v8.dev/ - libuv: https://libuv.org/ ## 🗣️ Paraphrase - Paragraph A: The missing piece to build Gutenberg blocks in-browser was Node.js; a prototype now runs npm and webpack, pointing toward @wordpress/scripts support. - Paragraph B: Rather than compile Node to WASM, the approach loads Node’s JS stdlib and polyfills its internal C binding surfaces so browser JS can run Node-oriented tooling. ## 📰 Newsletter - This week in WordPress dev: A prototype runs Node tooling directly in the browser, aiming to make @wordpress/scripts work inside WordPress Playground. That could mean zero-install block development: write JSX, build, and test—all in a tab. It’s early: multi-process, workers, and shared FS support are still missing. Meanwhile, Playground priorities like Xdebug and phpMyAdmin are moving forward. Explore @wordpress/scripts and Webpack to prep for a browser-first dev future, and keep an eye on Playground’s evolving capabilities. ## ✅ Action Items #### DevRel - Developer advocacy: Demo in-browser npm/webpack builds; gather feedback via office hours; track success by prototype runs and block build completions. - Education: Create a “Build a block in your browser” workshop; step-by-step labs for JSX→@wordpress/scripts→block assets. - Developer experience: Minimal examples/templates for Playground builds; document constraints (no child_process, limited workers). - Developer marketing: Launch a “No-install blocks” content series; measure signups and Playground sessions. - Community management: Run surveys on browser-only dev needs; maintain a known-issues board. - Internal/external/cross-project: Align with Playground roadmap; set SLAs for demo reliability; feedback loops with @wordpress/scripts maintainers. #### OSPO - Policy & Governance: Clarify contribution guidelines for polyfills touching Node semantics. - License Compliance: Review stdlib code usage and license compatibilities. - Security Management: Threat model polyfills; define vuln intake for browser-exec context. - Software Inventory: Track versions of stdlib/polyfills; SBOM for browser build toolchain. - Developer Support: Provide guardrails for running third-party packages in-browser. - Community Engagement: Coordinate with Node/Webpack communities on compat gaps. - Strategic Alignment: Report KPIs on compatibility coverage and performance. #### Community - Maintainers: Host roadmap clinics on enabling @wordpress/scripts in-browser. - Contributors: “First issue” polyfill tasks and test matrices. - Sponsors: Fund performance profiling and worker/FS features; publish outcomes. - Ecosystem: Cross-project incident drills for build regressions. #### WordPress - Core: Monitor implications of browser-based builds on block scaffolding. - Core Performance: Benchmark build times and memory; publish dashboards. - Core AI: N/A directly; ensure tooling doesn’t hinder AI-assisted dev flows. - Core Program Team: Sync milestones with Playground deliverables. - Mobile: Explore remote-build previews in mobile dev workflows. - Playground: Add labs, reproducible bug repros, educational modules; design shared FS. - Community: Provide meetup kits for “blocks in the browser” sessions. - Training: Author lesson plans for zero-install dev. - Marketing: Narrative around accessibility of block dev for newcomers. - Support: KB entries for common browser-build issues. - Design: UX for terminal/file explorer; error surfacing. - Documentation: Examples-first docs; compatibility notes and workarounds. - Photos/TV: N/A - Polyglots: Translate tutorials. - Accessibility: Ensure terminal/file explorer meet WCAG; keyboard-first ops. - Meta: Reliable .org APIs for templates/examples. - CLI: Explore parity guides between WP-CLI scaffolds and browser flow. - Hosting: Guidance on moving from browser builds to hosted pipelines. - Tide: Consider scoring guidance for browser-built artifacts. - Openverse: N/A - Themes: Add theme-block examples built in-browser. - Plugins: Provenance checks for browser-built assets. #### The WPOCC - Programs: Microgrants for polyfill and worker/FS work. - Projects: Docs sprints on browser-based workflows. - Funding experiments: Milestone payouts for feature parity. ### FAIR - Technical independence: Local metadata and signatures for built artifacts. - Policies and covenants: Transparent funding for polyfills; sunset plans if unmaintainable. - Productized governance artifacts: Compatibility scorecards and operator agreements. ## 🧪 Hypotheses - Enabling @wordpress/scripts in-browser increases new block developer conversions by ≥20%. - Browser-based builds reduce setup time by ≥80% vs local Node installs. - Missing child_process/worker features are the primary blockers for full compatibility. - Polyfilling internalBinding surfaces can support ≥90% of top npm build tools used in WP block workflows. ### 📊 Methodology - A/B onboarding: browser build vs local setup; measure time-to-first-build and completion rate. - Compatibility matrix: run top WP block starter repos; record pass/fail and required shims. - Performance profiling: latency and memory across sample projects; compare against local Node. - Developer surveys: perceived friction, reliability, and willingness to adopt. ### ❓ Questions - What minimal API surface is required for @wordpress/scripts to be fully functional? - How can a shared filesystem across workers be implemented safely in-browser? - What are the security boundaries for running arbitrary npm scripts client-side? ### 🔮 Future Research - Worker/worker_threads emulation with shared FS. - Deterministic, cacheable builds in-browser. - Sandboxing and provenance for third-party build steps. ### 💡 Implications - Practice: Zero-install training and rapid prototyping. - Policy: Clear guidance on executing third-party code in-browser. - Security: Sandboxing, permission prompts, and provenance tracking. - Education: Lower barrier for block curriculum worldwide. - Funding: Sponsor compatibility and performance milestones. ### 🧠 Learning Styles Assessment - Reading level: Flesch-Kincaid Grade ≈ 10–11. #### 👀 Visual learners - Present: Screenshot of terminal. - Improve: Architecture diagram of stdlib + polyfills + tooling. #### 🔊 Aural learners - Present: None. - Improve: Short audio walkthrough. #### 🗣️ Verbal learners - Present: Clear explanations and contrasts (WASM vs polyfill). - Improve: Glossary for Node/Playground terms. #### 🧩 Kinesthetic learners - Present: Repo to try. - Improve: Step-by-step lab in Playground. #### 🧠 Logical learners - Present: Tradeoff reasoning. - Improve: Decision tree for approaches. #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion potential. - Improve: Cohort-based workshops. #### 🧘‍♀️ Solitary learners - Present: Article format. - Improve: Self-check quiz. #### 🌿 Naturalistic learners - Present: N/A. - Improve: N/A. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Basic headings. - Improve: Ensure alt text for screenshots; proper landmarks. #### Keyboard navigation - Present: Standard page. - Improve: Ensure all interactive labs are keyboard-accessible. #### Contrast and readability - Present: Likely adequate. - Improve: Confirm 4.5:1 for code/terminal captures. #### Text resizing and reflow - Present: Responsive page. - Improve: Support prefers-reduced-motion where demos exist. #### Media and captions - Present: Screenshot only. - Improve: Text alternatives and downloadable instructions. #### Forms and interactions - Present: Minimal. - Improve: Inline validation for any embedded labs. #### Standards reference - Map to WCAG 2.2 AA: 1.1.1, 1.4.x, 2.1.x, 2.4.x, 3.3.x. ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global relevance (browser-based lowers barrier). - Improve: Multilingual tutorials and region-friendly bandwidth notes. #### Inclusive language - Present: Neutral, clear. - Improve: More plain-language summaries for newcomers. #### Neurodiversity support - Present: Chunked sections. - Improve: Consistent icon+text labels; predictable patterns in labs. #### Representation - Present: N/A imagery. - Improve: Inclusive visuals if added. #### Psychological safety - Present: Respectful tone. - Improve: Community guidelines and moderation in related forums. ### ✅ Logical Validity #### Strong reasoning - Inductive tradeoff: Not compiling Node to WASM due to size/complexity/perf costs—well motivated by practical constraints. - Causal claim: Polyfilling internalBinding enables stdlib to run—supported by prototype results (npm/webpack run). #### Fallacies - None apparent; limitations clearly acknowledged. #### Tone of voice - Pragmatic and transparent: “It’s promising, but there’s still a long way to go!” ### 🛡️ DARVO Analysis - No denial/attack/reversal patterns; collaborative, problem-focused framing. ## 🎯 Conclusion - Bottom line: Running Node tooling in-browser via stdlib + polyfills is viable and promising for WordPress block development, but key features are missing for parity. - Next steps: Define minimal APIs for @wordpress/scripts; implement worker/FS features; document constraints; ship Playground enhancements; run onboarding A/B tests. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: H3. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Polyfilled Node stdlib runs in-browser > [!quote] Running Node.js in the browser (https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/) by [an unnamed author] via [[Adam's Perspective]]. Published 2025. Accessed 2025-10-11. > “You can polyfill them, initialize all the expected global variables, load the Node.js stdlib in the browser.” Prototype shows npm/webpack running with polyfilled internal bindings. [view highlight](https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] WASM approach is too heavy > [!quote] Running Node.js in the browser (https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/) > “I’m not compiling Node.js to WASM!” Tradeoffs: size, speed, complexity disfavor a WASM-based Node. [view highlight](https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] Polyfilled internalBinding enables browser Node tooling - Scope: Common build tools (npm/webpack). - Pointer: Article section on internalBinding/fs. - Links: [[Node-Polyfills]] [[Browser-Build-Tooling]] #### [Z2] Browser-based block builds need shared FS across workers - Scope: @wordpress/scripts parity. - Pointer: Limitations list. - Links: [[Playground-Filesystem]] [[Worker-Threads]] --- ### ✏️ Fleeting Queue (Extract by Selection) - [F1] Map minimal API surface for @wordpress/scripts compatibility — context/https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/ #fleeting #inbox - [F2] Design shared FS for browser workers — context/https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/ #fleeting #inbox - [F3] Create “Build a block in-browser” lab — context/https://adamadam.blog/2025/10/10/running-node-js-in-the-browser/ #fleeting #inbox --- <!-- deep-read:sections end -->