[{"data":1,"prerenderedAt":2149},["ShallowReactive",2],{"page-\u002Fjs\u002F01-introduction-and-setup":3},{"id":4,"title":5,"body":6,"description":263,"extension":2143,"meta":2144,"navigation":34,"path":2145,"seo":2146,"stem":2147,"__hash__":2148},"content\u002Fjs\u002F01-introduction-and-setup.md","01 — Introduction & Setup",{"type":7,"value":8,"toc":2109},"minimark",[9,13,111,190,244,366,462,533,593,741,872,941,1053,1191,1313,1456,1529,1670,1748,1893,2041,2105],[10,11,5],"h1",{"id":12},"_01-introduction-setup",[14,15,16,21,64],"question-wrapper",{},[17,18,20],"h3",{"id":19},"q1-what-is-v8-in-the-context-of-javascript","Q1. What is V8, in the context of JavaScript?",[22,23,26,46,52,58],"ul",{"className":24},[25],"contains-task-list",[27,28,31,36,37,41,42,45],"li",{"className":29},[30],"task-list-item",[32,33],"input",{"disabled":34,"type":35},true,"checkbox"," A JavaScript runtime that provides ",[38,39,40],"code",{},"fs",", ",[38,43,44],{},"http",", and other OS-level APIs",[27,47,49,51],{"className":48},[30],[32,50],{"disabled":34,"type":35}," A JavaScript engine that parses and executes JavaScript source code",[27,53,55,57],{"className":54},[30],[32,56],{"disabled":34,"type":35}," A package manager bundled with Node.js",[27,59,61,63],{"className":60},[30],[32,62],{"disabled":34,"type":35}," A transpiler that converts modern JavaScript into ES5",[65,66,67,71,79],"details",{},[68,69,70],"summary",{},"Show Answer",[72,73,74,78],"p",{},[75,76,77],"strong",{},"Answer:"," B — A JavaScript engine that parses and executes JavaScript source code",[72,80,81,84,85,41,88,91,92,95,96,98,99,101,102,106,107,110],{},[75,82,83],{},"Explanation:"," V8 (built by Google) is an engine — it parses, compiles (via JIT), and executes JS code, and implements the ECMAScript spec plus the language's core objects (",[38,86,87],{},"Array",[38,89,90],{},"Promise",", etc.). It does ",[75,93,94],{},"not"," provide ",[38,97,40],{}," or ",[38,100,44],{},"; those come from a ",[103,104,105],"em",{},"runtime"," built around the engine. Option A describes Node.js, which embeds V8 but adds its own APIs. Option C confuses V8 with ",[38,108,109],{},"npm",". Option D describes tools like Babel — V8 runs JS natively, it doesn't transpile.",[14,112,113,117,153],{},[17,114,116],{"id":115},"q2-which-statement-correctly-distinguishes-nodejs-from-v8","Q2. Which statement correctly distinguishes Node.js from V8?",[22,118,120,126,141,147],{"className":119},[25],[27,121,123,125],{"className":122},[30],[32,124],{"disabled":34,"type":35}," They are the same thing — \"Node.js\" is just another name for the V8 engine",[27,127,129,131,132,41,134,136,137,140],{"className":128},[30],[32,130],{"disabled":34,"type":35}," Node.js is a runtime that embeds V8 and adds APIs like ",[38,133,40],{},[38,135,44],{},", and ",[38,138,139],{},"process"," that aren't part of JavaScript itself",[27,142,144,146],{"className":143},[30],[32,145],{"disabled":34,"type":35}," V8 is a superset of Node.js that adds browser-specific APIs",[27,148,150,152],{"className":149},[30],[32,151],{"disabled":34,"type":35}," Node.js replaces V8 with its own custom-built engine",[65,154,155,157,168],{},[68,156,70],{},[72,158,159,161,162,41,164,136,166],{},[75,160,77],{}," B — Node.js is a runtime that embeds V8 and adds APIs like ",[38,163,40],{},[38,165,44],{},[38,167,139],{},[72,169,170,172,173,41,175,178,179,182,183,185,186,189],{},[75,171,83],{}," Node.js embeds the V8 engine and layers on host APIs (filesystem, networking, ",[38,174,139],{},[38,176,177],{},"Buffer",") that are not defined by the ECMAScript spec at all. ",[75,180,181],{},"Portability:"," because ",[38,184,40],{}," and ",[38,187,188],{},"window"," are host APIs, not language features, code using them isn't portable between Node and the browser even though both run \"JavaScript.\" Option A collapses the runtime\u002Fengine distinction. Option C reverses the relationship. Option D is false — Node has always used V8, not a custom engine.",[14,191,192,196,223],{},[17,193,195],{"id":194},"q3-es6-and-es2015-refer-to","Q3. \"ES6\" and \"ES2015\" refer to:",[22,197,199,205,211,217],{"className":198},[25],[27,200,202,204],{"className":201},[30],[32,203],{"disabled":34,"type":35}," Two different, incompatible versions of JavaScript",[27,206,208,210],{"className":207},[30],[32,209],{"disabled":34,"type":35}," The same ECMAScript edition — ES6 is the older name, ES2015 is the year-based name adopted afterward",[27,212,214,216],{"className":213},[30],[32,215],{"disabled":34,"type":35}," ES6 is the browser implementation, ES2015 is the Node.js implementation",[27,218,220,222],{"className":219},[30],[32,221],{"disabled":34,"type":35}," ES2015 is a strict superset of ES6 released a year later",[65,224,225,227,232],{},[68,226,70],{},[72,228,229,231],{},[75,230,77],{}," B — The same edition; ES6 is the older name, ES2015 is the year-based name",[72,233,234,236,237,41,240,243],{},[75,235,83],{}," TC39 switched to annual, year-based release naming starting with the edition that introduced ",[38,238,239],{},"let",[38,241,242],{},"const",", classes, arrow functions, and Promises. That edition is interchangeably called \"ES6\" or \"ES2015\" — they are not different versions. Options A, C, and D all invent a distinction that doesn't exist.",[14,245,247,255,314,341],{"language":246},"javascript",[17,248,250,251,254],{"id":249},"q4-where-must-a-use-strict-directive-appear-to-enable-strict-mode-for-an-entire-script","Q4. Where must a ",[38,252,253],{},"\"use strict\""," directive appear to enable strict mode for an entire script?",[256,257,258],"code-wrapper",{"language":246},[259,260,264],"pre",{"className":261,"code":262,"language":246,"meta":263,"style":263},"language-javascript shiki shiki-themes github-light github-dark","function example() {\n  \"use strict\";\n  x = 10;\n}\n","",[38,265,266,283,293,308],{"__ignoreMap":263},[267,268,271,275,279],"span",{"class":269,"line":270},"line",1,[267,272,274],{"class":273},"svdQ7","function",[267,276,278],{"class":277},"sIsaT"," example",[267,280,282],{"class":281},"ssxIu","() {\n",[267,284,286,290],{"class":269,"line":285},2,[267,287,289],{"class":288},"sJ6F3","  \"use strict\"",[267,291,292],{"class":281},";\n",[267,294,296,299,302,306],{"class":269,"line":295},3,[267,297,298],{"class":281},"  x ",[267,300,301],{"class":273},"=",[267,303,305],{"class":304},"snvgF"," 10",[267,307,292],{"class":281},[267,309,311],{"class":269,"line":310},4,[267,312,313],{"class":281},"}\n",[22,315,317,323,329,335],{"className":316},[25],[27,318,320,322],{"className":319},[30],[32,321],{"disabled":34,"type":35}," Anywhere in the file, even after other executable statements",[27,324,326,328],{"className":325},[30],[32,327],{"disabled":34,"type":35}," As the very first statement in the file (or function body), before any other statements",[27,330,332,334],{"className":331},[30],[32,333],{"disabled":34,"type":35}," Inside a comment at the top of the file",[27,336,338,340],{"className":337},[30],[32,339],{"disabled":34,"type":35}," It must be passed as a CLI flag to Node; it cannot appear in source",[65,342,343,345,350],{},[68,344,70],{},[72,346,347,349],{},[75,348,77],{}," B — As the very first statement in the file (or function body), before any other statements",[72,351,352,354,355,357,358,361,362,365],{},[75,353,83],{}," ",[38,356,253],{}," is a ",[103,359,360],{},"directive prologue"," — the parser only recognizes it as special when it is literally the first statement. ",[75,363,364],{},"Debug:"," if any other statement (even a variable declaration) precedes it, it's silently treated as a harmless, no-op string literal expression instead of enabling strict mode — a common silent-failure trap. Option A is the tempting wrong answer for exactly that reason. It's a plain string literal, not a comment (C), and works in any JS file, not just via a Node flag (D).",[14,367,368,387,417],{},[17,369,371,372,375,376,41,379,382,383,386],{"id":370},"q5-by-default-how-does-a-browser-handle-a-plain-script-srcappjsscript-tag-with-no-async-defer-or-typemodule-attributes","Q5. By default, how does a browser handle a plain ",[38,373,374],{},"\u003Cscript src=\"app.js\">\u003C\u002Fscript>"," tag with no ",[38,377,378],{},"async",[38,380,381],{},"defer",", or ",[38,384,385],{},"type=\"module\""," attributes?",[22,388,390,396,402,408],{"className":389},[25],[27,391,393,395],{"className":392},[30],[32,394],{"disabled":34,"type":35}," It downloads and executes the script without blocking HTML parsing",[27,397,399,401],{"className":398},[30],[32,400],{"disabled":34,"type":35}," It blocks HTML parsing while the script downloads and executes, then resumes parsing",[27,403,405,407],{"className":404},[30],[32,406],{"disabled":34,"type":35}," It waits until the entire document is parsed before downloading the script",[27,409,411,413,414],{"className":410},[30],[32,412],{"disabled":34,"type":35}," It downloads the script in parallel but always executes it after ",[38,415,416],{},"DOMContentLoaded",[65,418,419,421,426],{},[68,420,70],{},[72,422,423,425],{},[75,424,77],{}," B — It blocks HTML parsing while the script downloads and executes, then resumes parsing",[72,427,428,430,431,434,435,438,439,442,443,445,446,448,449,452,453,455,456,458,459,461],{},[75,429,83],{}," A classic synchronous ",[38,432,433],{},"\u003Cscript>"," tag is parser-blocking: the browser must fetch and run it before continuing to parse the rest of the HTML. ",[75,436,437],{},"Performance:"," this is why render-blocking scripts placed in ",[38,440,441],{},"\u003Chead>"," are a common cause of slow page loads, and why ",[38,444,381],{},"\u002F",[38,447,378],{},"\u002Fplacing scripts before ",[38,450,451],{},"\u003C\u002Fbody>"," are recommended. Option A describes ",[38,454,378],{},". Option C is closer to ",[38,457,381],{},"'s execution timing but still wrong about parsing being blocked. Option D is incorrect — plain scripts run as soon as they're evaluated, not after ",[38,460,416],{},".",[14,463,464,472,507],{},[17,465,467,468,471],{"id":466},"q6-a-script-typemodule-tag-behaves-like-which-combination-of-attributes-by-default","Q6. A ",[38,469,470],{},"\u003Cscript type=\"module\">"," tag behaves like which combination of attributes by default?",[22,473,475,481,490,498],{"className":474},[25],[27,476,478,480],{"className":477},[30],[32,479],{"disabled":34,"type":35}," Like a plain script — blocking, synchronous",[27,482,484,486,487,489],{"className":483},[30],[32,485],{"disabled":34,"type":35}," Like ",[38,488,378],{}," — non-blocking, execution order not guaranteed",[27,491,493,486,495,497],{"className":492},[30],[32,494],{"disabled":34,"type":35},[38,496,381],{}," — non-blocking, and execution is deferred until after parsing, in document order",[27,499,501,503,504,506],{"className":500},[30],[32,502],{"disabled":34,"type":35}," Modules cannot be loaded via ",[38,505,433],{}," tags at all; they require a bundler",[65,508,509,511,519],{},[68,510,70],{},[72,512,513,515,516,518],{},[75,514,77],{}," C — Like ",[38,517,381],{}," — non-blocking, deferred, and in document order",[72,520,521,523,524,526,527,529,530,532],{},[75,522,83],{}," ES module scripts are deferred by default: the browser fetches them without blocking parsing, and executes them in document order after parsing completes (unless ",[38,525,378],{}," is also explicitly added, which then allows out-of-order execution). Option A is the common beginner assumption — that \"module\" means \"just a normal script with import support\" — but the loading semantics are different. Option B is wrong unless ",[38,528,378],{}," is explicitly added. Option D is false; native ",[38,531,470],{}," works without any bundler in modern browsers.",[14,534,535,539,566],{},[17,536,538],{"id":537},"q7-what-is-a-defining-characteristic-of-deno-compared-to-nodejs","Q7. What is a defining characteristic of Deno compared to Node.js?",[22,540,542,548,554,560],{"className":541},[25],[27,543,545,547],{"className":544},[30],[32,546],{"disabled":34,"type":35}," Deno cannot execute TypeScript without a separate compile step",[27,549,551,553],{"className":550},[30],[32,552],{"disabled":34,"type":35}," Deno runs scripts with no filesystem, network, or environment access by default, requiring explicit permission flags",[27,555,557,559],{"className":556},[30],[32,558],{"disabled":34,"type":35}," Deno does not support ES modules",[27,561,563,565],{"className":562},[30],[32,564],{"disabled":34,"type":35}," Deno uses the SpiderMonkey engine instead of V8",[65,567,568,570,575],{},[68,569,70],{},[72,571,572,574],{},[75,573,77],{}," B — Deno runs scripts with no filesystem, network, or environment access by default, requiring explicit permission flags",[72,576,577,354,579,582,583,41,586,41,589,592],{},[75,578,83],{},[75,580,581],{},"Safety:"," Deno is secure-by-default — a script needs ",[38,584,585],{},"--allow-read",[38,587,588],{},"--allow-net",[38,590,591],{},"--allow-env",", etc. explicitly granted, unlike Node where any script has full system access the moment it runs. Deno actually supports TypeScript natively without a separate build step (making A false), supports ES modules as its primary module system (making C false), and uses V8 just like Node (making D false).",[14,594,595,599,643,687],{"language":246},[17,596,598],{"id":597},"q8-what-is-the-key-syntacticbehavioral-difference-between-commonjs-and-es-modules-in-nodejs","Q8. What is the key syntactic\u002Fbehavioral difference between CommonJS and ES modules in Node.js?",[256,600,601],{"language":246},[259,602,604],{"className":261,"code":603,"language":246,"meta":263,"style":263},"const fs = require('fs');\nmodule.exports = { readConfig };\n",[38,605,606,628],{"__ignoreMap":263},[267,607,608,610,613,616,619,622,625],{"class":269,"line":270},[267,609,242],{"class":273},[267,611,612],{"class":304}," fs",[267,614,615],{"class":273}," =",[267,617,618],{"class":277}," require",[267,620,621],{"class":281},"(",[267,623,624],{"class":288},"'fs'",[267,626,627],{"class":281},");\n",[267,629,630,633,635,638,640],{"class":269,"line":285},[267,631,632],{"class":304},"module",[267,634,461],{"class":281},[267,636,637],{"class":304},"exports",[267,639,615],{"class":273},[267,641,642],{"class":281}," { readConfig };\n",[22,644,646,666,672,681],{"className":645},[25],[27,647,649,651,652,445,655,658,659,445,662,665],{"className":648},[30],[32,650],{"disabled":34,"type":35}," CommonJS uses ",[38,653,654],{},"require",[38,656,657],{},"module.exports"," and loads synchronously; ESM uses ",[38,660,661],{},"import",[38,663,664],{},"export"," and is loaded asynchronously with static analysis",[27,667,669,671],{"className":668},[30],[32,670],{"disabled":34,"type":35}," There is no real difference — Node treats both identically at runtime",[27,673,675,677,678,680],{"className":674},[30],[32,676],{"disabled":34,"type":35}," CommonJS supports ",[38,679,661],{}," statements but ESM does not",[27,682,684,686],{"className":683},[30],[32,685],{"disabled":34,"type":35}," ESM is only available in the browser, never in Node.js",[65,688,689,691,706],{},[68,690,70],{},[72,692,693,695,696,445,698,700,701,445,703,705],{},[75,694,77],{}," A — CommonJS uses ",[38,697,654],{},[38,699,657],{}," synchronously; ESM uses ",[38,702,661],{},[38,704,664],{},", resolved asynchronously and statically analyzable",[72,707,708,710,711,714,715,445,717,719,720,722,723,445,726,729,730,733,734,737,738,740],{},[75,709,83],{}," CommonJS ",[38,712,713],{},"require()"," calls are synchronous function calls that can happen conditionally anywhere in code. ESM ",[38,716,661],{},[38,718,664],{}," bindings are statically analyzed at parse time (enabling tree-shaking) and top-level ",[38,721,661],{}," cannot be conditional. Node determines which system to use per-file based on ",[38,724,725],{},".mjs",[38,727,728],{},".cjs"," extensions or the ",[38,731,732],{},"\"type\""," field in ",[38,735,736],{},"package.json",". Option B ignores real interop pitfalls (e.g., CJS's ",[38,739,654],{}," is unavailable by default in ESM files). Option C is backwards. Option D is false — Node has supported ESM natively since Node 12+.",[14,742,743,747,794,844],{"language":246},[17,744,746],{"id":745},"q9-what-happens-when-you-assign-to-an-undeclared-variable-inside-strict-mode-code","Q9. What happens when you assign to an undeclared variable inside strict-mode code?",[256,748,749],{"language":246},[259,750,752],{"className":261,"code":751,"language":246,"meta":263,"style":263},"\"use strict\";\nfunction setTotal() {\n  total = 42;\n}\nsetTotal();\n",[38,753,754,760,769,781,785],{"__ignoreMap":263},[267,755,756,758],{"class":269,"line":270},[267,757,253],{"class":288},[267,759,292],{"class":281},[267,761,762,764,767],{"class":269,"line":285},[267,763,274],{"class":273},[267,765,766],{"class":277}," setTotal",[267,768,282],{"class":281},[267,770,771,774,776,779],{"class":269,"line":295},[267,772,773],{"class":281},"  total ",[267,775,301],{"class":273},[267,777,778],{"class":304}," 42",[267,780,292],{"class":281},[267,782,783],{"class":269,"line":310},[267,784,313],{"class":281},[267,786,788,791],{"class":269,"line":787},5,[267,789,790],{"class":277},"setTotal",[267,792,793],{"class":281},"();\n",[22,795,797,806,819,833],{"className":796},[25],[27,798,800,354,802,805],{"className":799},[30],[32,801],{"disabled":34,"type":35},[38,803,804],{},"total"," is silently created as a global variable, same as in non-strict mode",[27,807,809,811,812,815,816,818],{"className":808},[30],[32,810],{"disabled":34,"type":35}," A ",[38,813,814],{},"ReferenceError"," is thrown because ",[38,817,804],{}," was never declared",[27,820,822,811,824,815,827,829,830],{"className":821},[30],[32,823],{"disabled":34,"type":35},[38,825,826],{},"TypeError",[38,828,804],{}," is ",[38,831,832],{},"undefined",[27,834,836,838,839,841,842],{"className":835},[30],[32,837],{"disabled":34,"type":35}," It works fine, but ",[38,840,804],{}," is scoped only to ",[38,843,790],{},[65,845,846,848,857],{},[68,847,70],{},[72,849,850,852,853,815,855,818],{},[75,851,77],{}," B — A ",[38,854,814],{},[38,856,804],{},[72,858,859,861,862,864,865,867,868,871],{},[75,860,83],{}," In non-strict mode, assigning to an undeclared identifier silently creates a global variable — a notorious source of bugs. Strict mode closes this hole: it throws a ",[38,863,814],{}," instead. ",[75,866,581],{}," the correct fix is to declare the variable explicitly (",[38,869,870],{},"let total = 42;",") rather than rely on implicit globals. Option A describes the (bug-prone) non-strict behavior. Option C names the wrong error type. Option D is wrong because the assignment never succeeds at all.",[14,873,874,886,913],{},[17,875,877,878,98,880,882,883,885],{"id":876},"q10-do-es-modules-script-typemodule-or-mjs-files-require-an-explicit-use-strict-directive-to-run-in-strict-mode","Q10. Do ES modules (",[38,879,470],{},[38,881,725],{}," files) require an explicit ",[38,884,253],{}," directive to run in strict mode?",[22,887,889,895,901,907],{"className":888},[25],[27,890,892,894],{"className":891},[30],[32,893],{"disabled":34,"type":35}," Yes — without it, modules run in sloppy (non-strict) mode",[27,896,898,900],{"className":897},[30],[32,899],{"disabled":34,"type":35}," No — ES modules are automatically strict mode, with no directive needed",[27,902,904,906],{"className":903},[30],[32,905],{"disabled":34,"type":35}," Only if the module also uses classes",[27,908,910,912],{"className":909},[30],[32,911],{"disabled":34,"type":35}," Only in Node.js, not in browsers",[65,914,915,917,922],{},[68,916,70],{},[72,918,919,921],{},[75,920,77],{}," B — No, ES modules are automatically strict mode",[72,923,924,926,927,930,931,933,934,936,937,940],{},[75,925,83],{}," The ECMAScript spec mandates that all module code is implicitly strict — there's no opt-out and no need for the directive. ",[75,928,929],{},"Idiom:"," adding ",[38,932,253],{}," at the top of a ",[38,935,725],{}," file is harmless but redundant. Option A is the common false assumption carried over from script-tag habits. Option C invents a class-specific rule (classes are ",[103,938,939],{},"always"," strict-mode bodies regardless of module status, but that's a separate rule). Option D is false — this is a language-level guarantee, not runtime-specific.",[14,942,943,951,995],{},[17,944,946,947,950],{"id":945},"q11-what-does-top-level-this-refer-to-in-each-of-a-classic-non-module-browser-script-an-es-module-and-a-nodejs-commonjs-file","Q11. What does top-level ",[38,948,949],{},"this"," refer to in each of: a classic (non-module) browser script, an ES module, and a Node.js CommonJS file?",[22,952,954,966,974,986],{"className":953},[25],[27,955,957,354,959,41,961,136,963,965],{"className":956},[30],[32,958],{"disabled":34,"type":35},[38,960,188],{},[38,962,188],{},[38,964,657],{}," respectively",[27,967,969,354,971,973],{"className":968},[30],[32,970],{"disabled":34,"type":35},[38,972,832],{}," in all three",[27,975,977,354,979,981,982,136,984,965],{"className":976},[30],[32,978],{"disabled":34,"type":35},[38,980,188],{}," (global object), ",[38,983,832],{},[38,985,657],{},[27,987,989,354,991,994],{"className":988},[30],[32,990],{"disabled":34,"type":35},[38,992,993],{},"globalThis"," in all three, since ES2020 unified them",[65,996,997,999,1010],{},[68,998,70],{},[72,1000,1001,1003,1004,41,1006,136,1008,965],{},[75,1002,77],{}," C — ",[38,1005,188],{},[38,1007,832],{},[38,1009,657],{},[72,1011,1012,1014,1015,1017,1018,1020,1021,829,1023,1025,1026,1028,1029,1031,1032,1034,1035,1037,1038,1040,1041,1043,1044,357,1046,1049,1050,1052],{},[75,1013,83],{}," In a classic script, top-level ",[38,1016,949],{}," is the global object (",[38,1019,188],{}," in browsers). In an ES module, top-level ",[38,1022,949],{},[38,1024,832],{}," by spec — modules don't have an implicit global receiver. In a Node CommonJS file, top-level ",[38,1027,949],{}," refers to ",[38,1030,657],{}," because the file is wrapped in a function by Node's module loader. ",[75,1033,364],{}," relying on top-level ",[38,1036,949],{}," for global access is fragile precisely because it varies by context — use ",[38,1039,993],{}," instead when you genuinely need the global object. Option D wrongly claims ",[38,1042,993],{}," replaced these semantics; ",[38,1045,993],{},[103,1047,1048],{},"new, separate"," way to reliably reach the global object, it didn't change what ",[38,1051,949],{}," means.",[14,1054,1056,1063,1120,1154],{"language":1055},"html",[17,1057,1059,1060,1062],{"id":1058},"q12-given-two-scripts-loaded-with-async-in-what-order-do-they-execute-relative-to-each-other","Q12. Given two scripts loaded with ",[38,1061,378],{},", in what order do they execute relative to each other?",[256,1064,1065],{"language":1055},[259,1066,1069],{"className":1067,"code":1068,"language":1055,"meta":263,"style":263},"language-html shiki shiki-themes github-light github-dark","\u003Cscript src=\"a.js\" async>\u003C\u002Fscript>\n\u003Cscript src=\"b.js\" async>\u003C\u002Fscript>\n",[38,1070,1071,1099],{"__ignoreMap":263},[267,1072,1073,1076,1080,1083,1085,1088,1091,1094,1096],{"class":269,"line":270},[267,1074,1075],{"class":281},"\u003C",[267,1077,1079],{"class":1078},"sk71V","script",[267,1081,1082],{"class":277}," src",[267,1084,301],{"class":281},[267,1086,1087],{"class":288},"\"a.js\"",[267,1089,1090],{"class":277}," async",[267,1092,1093],{"class":281},">\u003C\u002F",[267,1095,1079],{"class":1078},[267,1097,1098],{"class":281},">\n",[267,1100,1101,1103,1105,1107,1109,1112,1114,1116,1118],{"class":269,"line":285},[267,1102,1075],{"class":281},[267,1104,1079],{"class":1078},[267,1106,1082],{"class":277},[267,1108,301],{"class":281},[267,1110,1111],{"class":288},"\"b.js\"",[267,1113,1090],{"class":277},[267,1115,1093],{"class":281},[267,1117,1079],{"class":1078},[267,1119,1098],{"class":281},[22,1121,1123,1136,1142,1148],{"className":1122},[25],[27,1124,1126,1128,1129,1132,1133],{"className":1125},[30],[32,1127],{"disabled":34,"type":35}," Always in document order: ",[38,1130,1131],{},"a.js"," then ",[38,1134,1135],{},"b.js",[27,1137,1139,1141],{"className":1138},[30],[32,1140],{"disabled":34,"type":35}," In whichever order each script finishes downloading first — order is not guaranteed",[27,1143,1145,1147],{"className":1144},[30],[32,1146],{"disabled":34,"type":35}," Always in reverse document order",[27,1149,1151,1153],{"className":1150},[30],[32,1152],{"disabled":34,"type":35}," Simultaneously, on separate threads",[65,1155,1156,1158,1163],{},[68,1157,70],{},[72,1159,1160,1162],{},[75,1161,77],{}," B — In whichever order each script finishes downloading first; order is not guaranteed",[72,1164,1165,354,1167,1169,1170,1172,1173,1175,1176,1178,1179,1181,1182,1184,1185,1187,1188,1190],{},[75,1166,83],{},[38,1168,378],{}," scripts download in parallel and each executes immediately as soon as it finishes downloading, independent of the other or of document order. ",[75,1171,181],{}," this means a smaller\u002Ffaster-to-fetch ",[38,1174,1135],{}," can easily execute before ",[38,1177,1131],{},", so ",[38,1180,378],{}," is unsafe for scripts with ordering dependencies (use ",[38,1183,381],{}," for that instead). Option A describes ",[38,1186,381],{},"'s guarantee, not ",[38,1189,378],{},"'s. Option C and D describe behaviors JavaScript's single-threaded execution model doesn't produce — script execution itself is never literally parallel\u002Fsimultaneous even though downloads are.",[14,1192,1193,1197,1253,1291],{"language":246},[17,1194,1196],{"id":1195},"q13-what-happens-when-a-strict-mode-function-is-declared-with-duplicate-parameter-names","Q13. What happens when a strict-mode function is declared with duplicate parameter names?",[256,1198,1199],{"language":246},[259,1200,1202],{"className":261,"code":1201,"language":246,"meta":263,"style":263},"\"use strict\";\nfunction add(a, a, b) {\n  return a + b;\n}\n",[38,1203,1204,1210,1235,1249],{"__ignoreMap":263},[267,1205,1206,1208],{"class":269,"line":270},[267,1207,253],{"class":288},[267,1209,292],{"class":281},[267,1211,1212,1214,1217,1219,1223,1225,1227,1229,1232],{"class":269,"line":285},[267,1213,274],{"class":273},[267,1215,1216],{"class":277}," add",[267,1218,621],{"class":281},[267,1220,1222],{"class":1221},"sCrzJ","a",[267,1224,41],{"class":281},[267,1226,1222],{"class":1221},[267,1228,41],{"class":281},[267,1230,1231],{"class":1221},"b",[267,1233,1234],{"class":281},") {\n",[267,1236,1237,1240,1243,1246],{"class":269,"line":295},[267,1238,1239],{"class":273},"  return",[267,1241,1242],{"class":281}," a ",[267,1244,1245],{"class":273},"+",[267,1247,1248],{"class":281}," b;\n",[267,1250,1251],{"class":269,"line":310},[267,1252,313],{"class":281},[22,1254,1256,1265,1275,1283],{"className":1255},[25],[27,1257,1259,1261,1262,1264],{"className":1258},[30],[32,1260],{"disabled":34,"type":35}," It runs fine; the last ",[38,1263,1222],{}," argument silently shadows the first",[27,1266,1268,1270,1271,1274],{"className":1267},[30],[32,1269],{"disabled":34,"type":35}," It throws a ",[38,1272,1273],{},"SyntaxError"," at parse time",[27,1276,1278,1270,1280,1282],{"className":1277},[30],[32,1279],{"disabled":34,"type":35},[38,1281,826],{}," only when the function is called",[27,1284,1286,1288,1289],{"className":1285},[30],[32,1287],{"disabled":34,"type":35}," It works the same as in non-strict mode, using the first ",[38,1290,1222],{},[65,1292,1293,1295,1302],{},[68,1294,70],{},[72,1296,1297,1299,1300,1274],{},[75,1298,77],{}," B — It throws a ",[38,1301,1273],{},[72,1303,1304,1306,1307,1309,1310,1312],{},[75,1305,83],{}," Non-strict mode silently allows duplicate parameter names (later ones shadow earlier ones) — a foot-gun strict mode explicitly forbids by making it a parse-time ",[38,1308,1273],{},", so the code never even runs. ",[75,1311,581],{}," the fix is simply to rename parameters uniquely. Option A and D describe the permissive non-strict behavior. Option C is wrong about timing — this is caught before execution, not at call time.",[14,1314,1315,1323,1364,1416],{"language":246},[17,1316,1318,1319,1322],{"id":1317},"q14-how-does-eval-behave-differently-in-strict-mode-versus-non-strict-mode-regarding-variable-declarations","Q14. How does ",[38,1320,1321],{},"eval()"," behave differently in strict mode versus non-strict mode regarding variable declarations?",[256,1324,1325],{"language":246},[259,1326,1328],{"className":261,"code":1327,"language":246,"meta":263,"style":263},"\"use strict\";\neval(\"var leaked = 1;\");\nconsole.log(typeof leaked);\n",[38,1329,1330,1336,1348],{"__ignoreMap":263},[267,1331,1332,1334],{"class":269,"line":270},[267,1333,253],{"class":288},[267,1335,292],{"class":281},[267,1337,1338,1341,1343,1346],{"class":269,"line":285},[267,1339,1340],{"class":277},"eval",[267,1342,621],{"class":281},[267,1344,1345],{"class":288},"\"var leaked = 1;\"",[267,1347,627],{"class":281},[267,1349,1350,1353,1356,1358,1361],{"class":269,"line":295},[267,1351,1352],{"class":281},"console.",[267,1354,1355],{"class":277},"log",[267,1357,621],{"class":281},[267,1359,1360],{"class":273},"typeof",[267,1362,1363],{"class":281}," leaked);\n",[22,1365,1367,1383,1397,1407],{"className":1366},[25],[27,1368,1370,1372,1373,1375,1376,1379,1380],{"className":1369},[30],[32,1371],{"disabled":34,"type":35}," In strict mode, ",[38,1374,1340],{}," still leaks ",[38,1377,1378],{},"leaked"," into the surrounding scope, logging ",[38,1381,1382],{},"\"number\"",[27,1384,1386,1372,1388,1390,1391,1393,1394],{"className":1385},[30],[32,1387],{"disabled":34,"type":35},[38,1389,1340],{}," gets its own variable scope, so ",[38,1392,1378],{}," never escapes; this logs ",[38,1395,1396],{},"\"undefined\"",[27,1398,1400,354,1402,1404,1405],{"className":1399},[30],[32,1401],{"disabled":34,"type":35},[38,1403,1340],{}," is entirely disabled in strict mode and throws a ",[38,1406,1273],{},[27,1408,1410,1412,1413,1415],{"className":1409},[30],[32,1411],{"disabled":34,"type":35}," Both strict and non-strict ",[38,1414,1340],{}," behave identically — there's no scoping difference",[65,1417,1418,1420,1432],{},[68,1419,70],{},[72,1421,1422,1424,1425,1427,1428,1393,1430],{},[75,1423,77],{}," B — In strict mode, ",[38,1426,1340],{}," gets its own scope, so ",[38,1429,1378],{},[38,1431,1396],{},[72,1433,1434,1436,1437,1440,1441,1443,1444,1446,1447,1449,1450,1452,1453,1455],{},[75,1435,83],{}," In non-strict mode, ",[38,1438,1439],{},"var"," declarations inside ",[38,1442,1321],{}," leak into the calling scope — a well-known danger of ",[38,1445,1340],{},". Strict mode contains this: code run via ",[38,1448,1340],{}," gets its own variable environment, so declarations inside it stay local. ",[75,1451,581],{}," this is one of several reasons strict mode is recommended even when not using classes\u002Fmodules. Option A describes the leaky non-strict behavior. Option C overstates it — ",[38,1454,1340],{}," still works in strict mode, it's just scoped. Option D ignores this real, spec-mandated difference.",[14,1457,1458,1469,1502],{},[17,1459,1461,1462,1464,1465,1468],{"id":1460},"q15-is-it-necessary-to-add-use-strict-at-the-top-of-a-file-that-only-contains-es-class-declarations-and-no-other-top-level-code","Q15. Is it necessary to add ",[38,1463,253],{}," at the top of a file that only contains ES ",[38,1466,1467],{},"class"," declarations and no other top-level code?",[22,1470,1472,1478,1484,1493],{"className":1471},[25],[27,1473,1475,1477],{"className":1474},[30],[32,1476],{"disabled":34,"type":35}," Yes, classes are not strict by default and need the directive",[27,1479,1481,1483],{"className":1480},[30],[32,1482],{"disabled":34,"type":35}," No — class bodies are always executed in strict mode regardless of any directive, though it's still good practice to add it for non-class code in the same file",[27,1485,1487,1489,1490,1492],{"className":1486},[30],[32,1488],{"disabled":34,"type":35}," No, and adding it would cause a ",[38,1491,1273],{}," inside a class",[27,1494,1496,1498,1499],{"className":1495},[30],[32,1497],{"disabled":34,"type":35}," It depends on whether the class uses ",[38,1500,1501],{},"extends",[65,1503,1504,1506,1511],{},[68,1505,70],{},[72,1507,1508,1510],{},[75,1509,77],{}," B — No, class bodies are always strict regardless of a directive; still good practice for non-class code in the same file",[72,1512,1513,1515,1516,1518,1519,1521,1522,1524,1525,1528],{},[75,1514,83],{}," The ECMAScript spec mandates that the body of every ",[38,1517,1467],{}," (constructor and methods) runs in strict mode automatically, independent of directives or module status. ",[75,1520,929],{}," if a file mixes classes with regular top-level function code, you may still want an explicit ",[38,1523,253],{}," (or use a module) so that ",[103,1526,1527],{},"non-class"," code in the same file also gets strict-mode protections. Option A misunderstands the spec rule. Option C is false — the directive is legal syntax anywhere a directive prologue is allowed. Option D invents an irrelevant condition.",[14,1530,1531,1542,1598,1638],{"language":1055},[17,1532,1534,1535,1537,1538,1541],{"id":1533},"q16-what-is-the-idiomatic-reason-modern-projects-prefer-script-typemodule-over-the-older-script-nomodule-fallback-pattern","Q16. What is the idiomatic reason modern projects prefer ",[38,1536,470],{}," over the older ",[38,1539,1540],{},"\u003Cscript nomodule>"," fallback pattern?",[256,1543,1544],{"language":1055},[259,1545,1547],{"className":1067,"code":1546,"language":1055,"meta":263,"style":263},"\u003Cscript type=\"module\" src=\"modern.js\">\u003C\u002Fscript>\n\u003Cscript nomodule src=\"legacy.js\">\u003C\u002Fscript>\n",[38,1548,1549,1576],{"__ignoreMap":263},[267,1550,1551,1553,1555,1558,1560,1563,1565,1567,1570,1572,1574],{"class":269,"line":270},[267,1552,1075],{"class":281},[267,1554,1079],{"class":1078},[267,1556,1557],{"class":277}," type",[267,1559,301],{"class":281},[267,1561,1562],{"class":288},"\"module\"",[267,1564,1082],{"class":277},[267,1566,301],{"class":281},[267,1568,1569],{"class":288},"\"modern.js\"",[267,1571,1093],{"class":281},[267,1573,1079],{"class":1078},[267,1575,1098],{"class":281},[267,1577,1578,1580,1582,1585,1587,1589,1592,1594,1596],{"class":269,"line":285},[267,1579,1075],{"class":281},[267,1581,1079],{"class":1078},[267,1583,1584],{"class":277}," nomodule",[267,1586,1082],{"class":277},[267,1588,301],{"class":281},[267,1590,1591],{"class":288},"\"legacy.js\"",[267,1593,1093],{"class":281},[267,1595,1079],{"class":1078},[267,1597,1098],{"class":281},[22,1599,1601,1610,1619,1630],{"className":1600},[25],[27,1602,1604,354,1606,1609],{"className":1603},[30],[32,1605],{"disabled":34,"type":35},[38,1607,1608],{},"nomodule"," scripts always execute first regardless of load order",[27,1611,1613,1615,1616,1618],{"className":1612},[30],[32,1614],{"disabled":34,"type":35}," The fallback pattern exists to serve modern ESM bundles to browsers that support modules and a transpiled\u002Fbundled fallback to those that don't; with legacy browser support largely dropped, many modern projects skip the fallback and ship ",[38,1617,385],{}," only",[27,1620,1622,354,1624,1626,1627,1629],{"className":1621},[30],[32,1623],{"disabled":34,"type":35},[38,1625,385],{}," scripts cannot import other modules, so ",[38,1628,1608],{}," is required as a workaround",[27,1631,1633,354,1635,1637],{"className":1632},[30],[32,1634],{"disabled":34,"type":35},[38,1636,1608],{}," is deprecated syntax that throws an error in all current browsers",[65,1639,1640,1642,1647],{},[68,1641,70],{},[72,1643,1644,1646],{},[75,1645,77],{}," B — The pattern serves modern ESM to capable browsers and a fallback bundle to legacy ones; many projects now skip the fallback entirely",[72,1648,1649,1651,1652,1654,1655,1657,1658,1660,1661,1663,1664,1666,1667,1669],{},[75,1650,83],{}," The dual-script pattern exploited the fact that browsers old enough to not understand ",[38,1653,385],{}," also don't recognize ",[38,1656,1608],{}," as special and thus ignore it as an unknown attribute (loading the legacy bundle), while modern browsers understand ",[38,1659,1608],{}," and skip that script. ",[75,1662,929],{}," since evergreen browsers dominate today, many teams now ship ESM-only bundles and drop the legacy fallback and its build complexity entirely. Option A misdescribes the loading logic. Option C is false — modules import other modules constantly via ",[38,1665,661],{},". Option D is false; ",[38,1668,1608],{}," isn't deprecated, it's just often unnecessary now.",[14,1671,1672,1685,1718],{},[17,1673,1675,1676,1678,1679,1681,1682,1684],{"id":1674},"q17-why-is-defer-generally-preferred-over-placing-multiple-plain-script-tags-right-before-body","Q17. Why is ",[38,1677,381],{}," generally preferred over placing multiple plain ",[38,1680,433],{}," tags right before ",[38,1683,451],{},"?",[22,1686,1688,1696,1704,1710],{"className":1687},[25],[27,1689,1691,354,1693,1695],{"className":1690},[30],[32,1692],{"disabled":34,"type":35},[38,1694,381],{}," scripts execute before the DOM is parsed, which is faster",[27,1697,1699,354,1701,1703],{"className":1698},[30],[32,1700],{"disabled":34,"type":35},[38,1702,381],{}," lets the browser download scripts in parallel with HTML parsing (non-blocking) while still guaranteeing document order execution after parsing — plain end-of-body scripts still block parsing when the parser reaches them",[27,1705,1707,1709],{"className":1706},[30],[32,1708],{"disabled":34,"type":35}," There is no real difference; both approaches are functionally identical",[27,1711,1713,354,1715,1717],{"className":1712},[30],[32,1714],{"disabled":34,"type":35},[38,1716,381],{}," scripts run once per animation frame instead of once on load",[65,1719,1720,1722,1730],{},[68,1721,70],{},[72,1723,1724,1726,1727,1729],{},[75,1725,77],{}," B — ",[38,1728,381],{}," downloads in parallel with parsing, non-blocking, and still preserves document order after parsing completes",[72,1731,1732,354,1734,1736,1737,1740,1741,1743,1744,1747],{},[75,1733,83],{},[75,1735,437],{}," even scripts placed at the bottom of ",[38,1738,1739],{},"\u003Cbody>"," still block parsing for the moment the parser reaches them (they just do so after most content is already visible); ",[38,1742,381],{}," avoids blocking entirely by downloading concurrently with parsing and only executing once parsing is fully done, in document order. Option A gets the timing backwards — deferred scripts run ",[103,1745,1746],{},"after"," parsing, not before. Option C ignores the real performance and blocking difference. Option D describes something scripts don't do at all.",[14,1749,1751,1762,1803,1850],{"language":1750},"json",[17,1752,1754,1755,1758,1759,1761],{"id":1753},"q18-setting-type-module-in-a-nodejs-packagejson-changes-what","Q18. Setting ",[38,1756,1757],{},"\"type\": \"module\""," in a Node.js ",[38,1760,736],{}," changes what?",[256,1763,1764],{"language":1750},[259,1765,1768],{"className":1766,"code":1767,"language":1750,"meta":263,"style":263},"language-json shiki shiki-themes github-light github-dark","{\n  \"name\": \"app\",\n  \"type\": \"module\"\n}\n",[38,1769,1770,1775,1789,1799],{"__ignoreMap":263},[267,1771,1772],{"class":269,"line":270},[267,1773,1774],{"class":281},"{\n",[267,1776,1777,1780,1783,1786],{"class":269,"line":285},[267,1778,1779],{"class":304},"  \"name\"",[267,1781,1782],{"class":281},": ",[267,1784,1785],{"class":288},"\"app\"",[267,1787,1788],{"class":281},",\n",[267,1790,1791,1794,1796],{"class":269,"line":295},[267,1792,1793],{"class":304},"  \"type\"",[267,1795,1782],{"class":281},[267,1797,1798],{"class":288},"\"module\"\n",[267,1800,1801],{"class":269,"line":310},[267,1802,313],{"class":281},[22,1804,1806,1816,1833,1844],{"className":1805},[25],[27,1807,1809,1811,1812,1815],{"className":1808},[30],[32,1810],{"disabled":34,"type":35}," It only affects TypeScript files, not ",[38,1813,1814],{},".js"," files",[27,1817,1819,1821,1822,1824,1825,445,1827,1829,1830,1832],{"className":1818},[30],[32,1820],{"disabled":34,"type":35}," It makes Node interpret ",[38,1823,1814],{}," files in that package as ES modules (",[38,1826,661],{},[38,1828,664],{},") instead of the CommonJS default, while ",[38,1831,728],{}," files remain CommonJS regardless",[27,1834,1836,1838,1839,1841,1842,1815],{"className":1835},[30],[32,1837],{"disabled":34,"type":35}," It disables ",[38,1840,713],{}," globally, even in ",[38,1843,728],{},[27,1845,1847,1849],{"className":1846},[30],[32,1848],{"disabled":34,"type":35}," It has no effect unless a bundler like webpack is also configured",[65,1851,1852,1854,1865],{},[68,1853,70],{},[72,1855,1856,1858,1859,1861,1862,1864],{},[75,1857,77],{}," B — It makes ",[38,1860,1814],{}," files in that package parse as ES modules; ",[38,1863,728],{}," files stay CommonJS regardless",[72,1866,1867,1869,1870,41,1872,1874,1875,1877,1878,1880,1881,1883,1884,1886,1887,1889,1890,1892],{},[75,1868,83],{}," Node picks a module system per file: without ",[38,1871,1757],{},[38,1873,1814],{}," defaults to CommonJS; with it set, ",[38,1876,1814],{}," defaults to ESM. The explicit extensions ",[38,1879,725],{}," (always ESM) and ",[38,1882,728],{}," (always CommonJS) override the ",[38,1885,736],{}," setting entirely — this is the escape hatch for mixed codebases. Option A is wrong; this setting is about ",[38,1888,1814],{}," resolution, unrelated to TypeScript compilation. Option C is too broad — ",[38,1891,728],{}," files are unaffected. Option D is false; this is native Node behavior with zero bundler involvement.",[14,1894,1895,1904,1953,1991],{"language":1750},[17,1896,1898,1899,733,1902,1684],{"id":1897},"q19-what-is-the-purpose-of-the-engines-field-in-packagejson","Q19. What is the purpose of the ",[38,1900,1901],{},"\"engines\"",[38,1903,736],{},[256,1905,1906],{"language":1750},[259,1907,1909],{"className":1766,"code":1908,"language":1750,"meta":263,"style":263},"{\n  \"name\": \"app\",\n  \"engines\": {\n    \"node\": \">=18.0.0\"\n  }\n}\n",[38,1910,1911,1915,1925,1933,1943,1948],{"__ignoreMap":263},[267,1912,1913],{"class":269,"line":270},[267,1914,1774],{"class":281},[267,1916,1917,1919,1921,1923],{"class":269,"line":285},[267,1918,1779],{"class":304},[267,1920,1782],{"class":281},[267,1922,1785],{"class":288},[267,1924,1788],{"class":281},[267,1926,1927,1930],{"class":269,"line":295},[267,1928,1929],{"class":304},"  \"engines\"",[267,1931,1932],{"class":281},": {\n",[267,1934,1935,1938,1940],{"class":269,"line":310},[267,1936,1937],{"class":304},"    \"node\"",[267,1939,1782],{"class":281},[267,1941,1942],{"class":288},"\">=18.0.0\"\n",[267,1944,1945],{"class":269,"line":787},[267,1946,1947],{"class":281},"  }\n",[267,1949,1951],{"class":269,"line":1950},6,[267,1952,313],{"class":281},[22,1954,1956,1966,1979,1985],{"className":1955},[25],[27,1957,1959,1961,1962,1965],{"className":1958},[30],[32,1960],{"disabled":34,"type":35}," It automatically installs the specified Node.js version when ",[38,1963,1964],{},"npm install"," runs",[27,1967,1969,1971,1972,1974,1975,1978],{"className":1968},[30],[32,1970],{"disabled":34,"type":35}," It declares the Node.js (and optionally npm) version range the package expects; by default ",[38,1973,1964],{}," only warns (doesn't block) if the current version doesn't match, unless ",[38,1976,1977],{},"engine-strict"," is enabled",[27,1980,1982,1984],{"className":1981},[30],[32,1983],{"disabled":34,"type":35}," It sets the JavaScript engine (V8, SpiderMonkey, etc.) the app requires",[27,1986,1988,1990],{"className":1987},[30],[32,1989],{"disabled":34,"type":35}," It is required for ES modules to work",[65,1992,1993,1995,2003],{},[68,1994,70],{},[72,1996,1997,1999,2000,2002],{},[75,1998,77],{}," B — It declares the expected Node\u002Fnpm version range; npm warns by default rather than blocking, unless ",[38,2001,1977],{}," is set",[72,2004,2005,354,2007,2009,2010,2013,2014,2017,2018,2021,2022,445,2025,2028,2029,2032,2033,2035,2036,2038,2039,461],{},[75,2006,83],{},[75,2008,929],{}," teams add ",[38,2011,2012],{},"engines"," to document compatibility and catch version mismatches early, but by default npm treats a mismatch as a warning, not a hard failure — many developers are surprised the install still succeeds. Setting ",[38,2015,2016],{},"engine-strict=true"," in ",[38,2019,2020],{},".npmrc"," (or using tools like ",[38,2023,2024],{},"volta",[38,2026,2027],{},"nvm"," with ",[38,2030,2031],{},".nvmrc",") is needed to actually enforce it. Option A confuses it with a version manager's job — npm doesn't install Node versions. Option C confuses \"engine\" as used in ",[38,2034,736],{}," (meaning runtime version) with a JS engine like V8. Option D is unrelated; ESM support depends on the ",[38,2037,732],{}," field and Node version, not ",[38,2040,2012],{},[14,2042,2043,2047,2082],{},[17,2044,2046],{"id":2045},"q20-what-is-the-recommended-way-to-check-whether-a-javascript-runtime-supports-a-given-feature-eg-optional-chaining-before-using-it-in-production-code","Q20. What is the recommended way to check whether a JavaScript runtime supports a given feature (e.g., optional chaining) before using it in production code?",[22,2048,2050,2060,2066,2072],{"className":2049},[25],[27,2051,2053,2055,2056,2059],{"className":2052},[30],[32,2054],{"disabled":34,"type":35}," Parse the ",[38,2057,2058],{},"navigator.userAgent"," string and branch based on browser name\u002Fversion",[27,2061,2063,2065],{"className":2062},[30],[32,2064],{"disabled":34,"type":35}," Use feature detection — check for the existence of the API\u002Fbehavior directly (or rely on a transpiler\u002Fpolyfill pipeline), rather than inferring support from the browser or engine identity",[27,2067,2069,2071],{"className":2068},[30],[32,2070],{"disabled":34,"type":35}," Assume all evergreen browsers support all features equally, so no check is needed",[27,2073,2075,2077,2078,2081],{"className":2074},[30],[32,2076],{"disabled":34,"type":35}," Wrap all code in ",[38,2079,2080],{},"try\u002Fcatch"," and silently ignore failures",[65,2083,2084,2086,2091],{},[68,2085,70],{},[72,2087,2088,2090],{},[75,2089,77],{}," B — Use feature detection rather than inferring support from browser\u002Fengine identity",[72,2092,2093,354,2095,2097,2098,41,2101,2104],{},[75,2094,83],{},[75,2096,929],{}," UA sniffing (option A) is notoriously unreliable — user agents can be spoofed, forks and embedded webviews report misleading strings, and new browser versions ship features unpredictably. Feature detection (checking ",[38,2099,2100],{},"typeof obj?.prop !== 'undefined'",[38,2102,2103],{},"'querySelector' in document",", etc.) or using build tooling (Babel\u002FTypeScript targets, Browserslist-driven polyfills) checks reality directly. Option C is risky since even \"evergreen\" runtimes lag on brand-new proposals. Option D silently swallowing errors trades a clear compatibility failure for a much harder-to-debug silent one, which is the opposite of good practice.",[2106,2107,2108],"style",{},"html pre.shiki code .svdQ7, html code.shiki .svdQ7{--shiki-default:#D73A49;--shiki-github-dark:#F97583}html pre.shiki code .sIsaT, html code.shiki .sIsaT{--shiki-default:#6F42C1;--shiki-github-dark:#B392F0}html pre.shiki code .ssxIu, html code.shiki .ssxIu{--shiki-default:#24292E;--shiki-github-dark:#E1E4E8}html pre.shiki code .sJ6F3, html code.shiki .sJ6F3{--shiki-default:#032F62;--shiki-github-dark:#9ECBFF}html pre.shiki code .snvgF, html code.shiki .snvgF{--shiki-default:#005CC5;--shiki-github-dark:#79B8FF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .github-dark .shiki span {color: var(--shiki-github-dark);background: var(--shiki-github-dark-bg);font-style: var(--shiki-github-dark-font-style);font-weight: var(--shiki-github-dark-font-weight);text-decoration: var(--shiki-github-dark-text-decoration);}html.github-dark .shiki span {color: var(--shiki-github-dark);background: var(--shiki-github-dark-bg);font-style: var(--shiki-github-dark-font-style);font-weight: var(--shiki-github-dark-font-weight);text-decoration: var(--shiki-github-dark-text-decoration);}html pre.shiki code .sk71V, html code.shiki .sk71V{--shiki-default:#22863A;--shiki-github-dark:#85E89D}html pre.shiki code .sCrzJ, html code.shiki .sCrzJ{--shiki-default:#E36209;--shiki-github-dark:#FFAB70}",{"title":263,"searchDepth":285,"depth":285,"links":2110},[2111,2112,2113,2114,2116,2118,2120,2121,2122,2123,2125,2127,2129,2130,2132,2134,2136,2138,2140,2142],{"id":19,"depth":295,"text":20},{"id":115,"depth":295,"text":116},{"id":194,"depth":295,"text":195},{"id":249,"depth":295,"text":2115},"Q4. Where must a \"use strict\" directive appear to enable strict mode for an entire script?",{"id":370,"depth":295,"text":2117},"Q5. By default, how does a browser handle a plain \u003Cscript src=\"app.js\">\u003C\u002Fscript> tag with no async, defer, or type=\"module\" attributes?",{"id":466,"depth":295,"text":2119},"Q6. A \u003Cscript type=\"module\"> tag behaves like which combination of attributes by default?",{"id":537,"depth":295,"text":538},{"id":597,"depth":295,"text":598},{"id":745,"depth":295,"text":746},{"id":876,"depth":295,"text":2124},"Q10. Do ES modules (\u003Cscript type=\"module\"> or .mjs files) require an explicit \"use strict\" directive to run in strict mode?",{"id":945,"depth":295,"text":2126},"Q11. What does top-level this refer to in each of: a classic (non-module) browser script, an ES module, and a Node.js CommonJS file?",{"id":1058,"depth":295,"text":2128},"Q12. Given two scripts loaded with async, in what order do they execute relative to each other?",{"id":1195,"depth":295,"text":1196},{"id":1317,"depth":295,"text":2131},"Q14. How does eval() behave differently in strict mode versus non-strict mode regarding variable declarations?",{"id":1460,"depth":295,"text":2133},"Q15. Is it necessary to add \"use strict\" at the top of a file that only contains ES class declarations and no other top-level code?",{"id":1533,"depth":295,"text":2135},"Q16. What is the idiomatic reason modern projects prefer \u003Cscript type=\"module\"> over the older \u003Cscript nomodule> fallback pattern?",{"id":1674,"depth":295,"text":2137},"Q17. Why is defer generally preferred over placing multiple plain \u003Cscript> tags right before \u003C\u002Fbody>?",{"id":1753,"depth":295,"text":2139},"Q18. Setting \"type\": \"module\" in a Node.js package.json changes what?",{"id":1897,"depth":295,"text":2141},"Q19. What is the purpose of the \"engines\" field in package.json?",{"id":2045,"depth":295,"text":2046},"md",{},"\u002Fjs\u002F01-introduction-and-setup",{"title":5,"description":263},"js\u002F01-introduction-and-setup","057e7M3dBnyPZbrNFkox6JTX-lHc414h7f3Yg0IbFMU",1787335397331]