Courses
JavaScript Advanced: Code That Holds Up in Production
Check Yourself: Ship It, Then Make It Fast
Five scenario questions on publishing, profiling and memory leaks. If you miss more than one, reread the lesson that covers it.
Course content
Join this Course
Sign in to save your progress.
-
Functions That Remember
-
JavaScript Closures in Real Code
-
this, bind and Arrow Functions: Who Is Calling
-
-
-
How JavaScript Actually Runs
-
The Event Loop: Microtasks, Macrotasks and Why setTimeout(0) Isn't Zero
-
Running Promises in Parallel: all, allSettled, race
-
Cancelling Work With AbortController
-
-
-
Data That Doesn't Fit in Memory
-
Iterators and Generators
-
Streams in Node.js: Reading Big Files a Piece at a Time
-
-
-
Catch Bugs Before You Run the Code
-
JSDoc Types and // @ts-check Without Switching to TypeScript
-
ESLint in a Real Project
-
-
-
Ship It, Then Make It Fast
-
Bundling With Vite and Publishing to npm
-
Finding Slow Code With the Performance Profiler
-
Memory Leaks: Event Listeners and Closures That Never Let Go
-
-
- Final Check: JavaScript Advanced
1.
npm pack --dry-run lists .env, src/ and an old .tgz. What do you change?
2.
Your package's exports points "import" to ./dist/index.js, but the build writes dist/peso.js. How do you catch this before users do?
3.
The Bottom-up tab shows main() with 99% total time and findCustomerOrders() with 47% self time. Where do you look first?
4.
Two heap snapshots, 10 dialogs opened and closed in between. Comparison shows OrderDialog with 10 new, 0 deleted. What does that tell you?
5.
Which of these is the most common cause of a memory leak in a long-running page?
About
Five scenario questions on publishing, profiling and memory leaks. If you miss more than one, reread the lesson that covers it.
- Duration
- 5 min
- Last update
- 08/16/2026
Was this helpful?
0
0
Comments (0)
Sign in to commentNo comments yet.