<aside>
⚠️ This note serves as a reminder of the book's content, including additional research on the mentioned topics. It is not a substitute for the book. Most images are sourced from the book or referenced.
</aside>
<aside>
🚨 I've noticed that taking notes on this site while reading the book significantly extends the time it takes to finish the series. I've stopped noting everything, as in previous chapters, and instead continue reading by highlighting or hand-writing notes and use . I plan to return to this series when I have more time.
</aside>
All notes in this series
Infor & Preface
Chap 1 — What is JS?
What's With That Name?
- Not related with Java at all, not just a script but a programming language.
- "Java" → attract mostlty Java programmers, "Script" → light weight.
- Official name specified by TC39 as "ECMAScript" (ES).
- JS in browsers or Node.js is an implementation of ES2019 standard.
- Hosted by ECMA.
- Don't use "JS6" or "ES8", use "ES20xx" or "JS".
Language Specification
- Who decides a new version of JS? → TC39 (~50-100 members) by votes via 5 stages.
- There is just one JS in the wild (not multiple versions).
- Environments run JS: browsers, servers, robots, lightbulbs,....
- Not all are JS, eg.
alert("Hello, JS!")
or console.log()
← they're just APIs of JS environments.
- There are many "JS-looking" APIs:
fetch()
, getCurrentLocation()
, getUserMedia()
,...
- They follow JS rules but just "guests", not official JS specifications.
- Complain "JS is so inconsistent!" ← it's because the environment hehaviors work, not because of JS itself!
- Developer Tools (Inspect Element in Chrome, for example) are... tools for developers. They're NOT JS environment!
- Something works in Dev Tool, doesn't mean JS compiler will understand it.
Many Faces
- Paradigm-level code categories
- Procedural: organizes codes in a top-down, linear progression. ← eg. C
- Object-oriented (OO/classes): organizes codes into classes. ← eg. Java/C++
- Functional (FP): organizes codes into functions. ← eg. Haskell
- JS is a multi-paradigm language. → "meaning the syntax and capabilities allow a developer to mix and match (and bend and reshape!) concepts from various major paradigms"
Backwards & Forwards
- Backwards compatibility:
- Code from the past should still work today — "we don't break the web" (TC39)
- Idea: JS developer can write code with confidence → their code won't stop working in new released versions.
- Once it’s in JS, it can’t be taken out because it might break programs, even if we’d really, really like to remove it!
- My idea to remember: old codes work with new engines but old engines may not work with new codes.