Related: [[Node.JS]], [[TypeScript]]. ## Historic Reputation Long, long time ago, before [[Gmail]], before AJAX... We all thought that JavaScript was a toy [[Programming Languages]]. In reality, it was a language with toy runtime (web browser). However, this runtime became the most important runtime of the computing history, and it just took over. In the late 2000s - we thought that JavaScript was going to be the “assembly of the web”. It’s too “low level” and we would be writing applications in other high level languages. These included: * [[GWT]] - Google Web Toolkit ([[Java]]) 🪦 * [cappucino](https://www.cappuccino.dev/). 🪦 * [luna](https://blog.asana.com/2010/02/lunascript-our-in-house-language-for-writing-great-web-apps-really-quickly/) 🪦 * [CoffeeScript](https://coffeescript.org/) 🪦 --- What was the actual problem of the early 2010s JavaScript, and what was the solution? **World class developer tooling** - Chrome DevTools was *miles* ahead of everything else out there. Firefox/[Firebug](https://en.wikipedia.org/wiki/Firebug_(software)) was the state of the art, and it felt archaic as soon as Chrome came out. **Javascript got better over time** * Tooling Development - packaging javascript, polyfill * Convention - [[JavaScript - The Good Parts]] [[Asynchronous Programming#Promise|Promise]] * Language development - Many libraries and conventions (JSON, promises, async-await) started to be part of the main language. [[Asynchronous Programming]] was the crux of the problem. * Promises and `async-await` was the real game changer that allowed us to have sustainable software engineering in Javascript. However, none of the aforementioned solutions tackled this. They were still "syntactic sugar" over JS that didn't fundamentally change how we interacted with JavaScript. * GWT was promising, but Java as a base language doesn't have `async-await`, so it was terribly inadequate. [AsyncCallback](https://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideGettingUsedToAsyncCalls) interface resembles promises (with `onSuccess` and `onFailure`) **Web Standards got better over time** - HTML+CSS “just worked” for the most advanced rendering. The amount of IE6 hacks we needed to do to render the page decreased over time. `<!doctype html>` is enough to get started with. [^ie6] [[TypeScript]] was legitimately better than everything else, and it took over. *DefinitelyTyped* helped with its adoption also. **Failure of other frameworks** - Most of the above frameworks took the approach of “X is the current bleeding edge; this framework allows you to do X better”. However, the industry kept moving, and X became terribly outdated. [[Leaky Abstraction#Ruby on Rails *wannabes*]] [^ie6]: I want to revisit the literature on IE6 compatibility hacks. This is only of historical interest, but this was truly a dark and gloomy days of the web. Some [links](https://stackoverflow.com/questions/495050/list-of-css-features-not-supported-by-ie6). # [[ECMAScript]] Versions # Runtimes - ChakraCore / [SpiderMonkey](https://en.wikipedia.org/wiki/SpiderMonkey) - V8 - Chromium-based browsers (including Microsoft Edge) - Node.js - Electron (which is combination of Node.JS and Chromium) - Edge Runtimes ## [[WebAssembly]] ## Edge Runtime # Build Systems and Modules > [!warn] > A lot of the JS ecosystems' complexity comes from this. - [[ESM & CJS Modules]] - Babel and Webpack - more "traditional" builds - Importing non-js files (ex: `.css` via css modules) - **Inability to depend on symbol names due to minification.** - Transpilers such as SWC and esbuilds - written in [[Go]] / [[Rust]]. # Advanced JavaScript Features and functionalities that we tend to not use. > [!note] See [[Typescript - Advanced Types]] also. - symbols - decorators - Templates & Tagged Templates - Tagged Templates are quite powerful as it can be used to write very ergonomic code. - [[JavaScript Trick to name a function]] - [[JavaScript Advanced Async-await]] - [[What Color is your Function?|Function Coloring]] is less of a concern, but where it's frustrating is application startup; a lot of logic assumes synchronous execution, and `readFileSync` may be needed (ex: dotfiles) to ensure that it executes correctly. Some abstractions that I've previously built (like reading from AWS SSM) behaves poorly as it cannot become synchronous. - [[TC39 Explicit Resource Management]] - `using` statement. ## Tricks - **IIFE** - Immediately Invoked Function Expression