How much JavaScript do you need to know to use Node.js ? - AkuCode
If you are just starting out with JavaScript, how much deeply do you need to know the language? As a beginner, it’s hard to get to a point where you are confident enough in your programming abilities. While learning to code, you might also be confused at where does JavaScript ends, and where Node.js begins, and vice versa.
I would recommend you to have a good grasp of the main JavaScript concepts before diving into Node.js:
- Lexical Structure
- Expressions
- Types
- Variables
- Functions
- This
- Arrow Functions
- Loops
- Loops and Scope
- Arrays
- Template literals
- Semicolons
- Strict Mode
- ECMAScript 6,2016,2017
With those concepts in mind, you are well on your road to become a proficient JavaScript developer, in both the browser and in Node.js. the following concepts are also key to understand asynchronous programming, which is one fundamental part of Node.js:
- Asynchronous programming and callbacks
- Timers
- Promises
- Async and Await
- Closures
- The event Loop
Luckily I wrote an article that explains all those topics, and it’s called JavaScript Fundamental. It’s the most compact resource you’ll find to learn all of this.
Differences between Node and the Browser
How writing JavaScript application in Node.js differs from programming for the web inside the browser. Both the browser and Node user JavaScript as their programming language. Building apps that run in the browser is a completely different thing than building a Node.js application. Despite the fact that it’s always JavaScript, some key differences make the experience radically different.
As a frontend developer that writes Node apps have a huge advantage – the language is still the same. You have a huge opportunity because we know how hard it is to fully, deeply learn a programming language, and by using the same language to perform all your work on the web-both on the client and on the server, you’re in a unique position of advantages.
What changes in the ecosystem. In the browser, most of the time what you are doing is interacting with the DOM or other Web Platform APIs like Cookies. Those do not exist in Node, of course. You don’t have the document, window, and all the other objects that are provided by the browser, and in the browser, we don’t have all the nice API that Node.js provides through its modules, like the filesystem access functionality.
Another big difference is that in Node.js you control the environment. Unless you are building an open source application that anyone can deploy anywhere, you know which version of Node you will run the application on. Compared to the browser environment, where you don’t get the luxury to choose what browser your visitor will use, this is very convenient. This means that you can write all the modern ES6-7-8-9 JavaScript that your Node version supports.
Since JavaScript moves so fast, but browsers can be a bit slow and users a bit slow to upgrade, sometimes on the web, you are stuck to use older JavaScript / ECMAScript releases. You can use babel to transform your code to be ES5-compatible before shipping it to the browser, but in Node, you won’t need that. Another difference is that Node uses the CommonJs module system, while in the browser we are starting to see the ES Modules standard being implemented. In practice, this means that for the time being you use require() in Node and import in the browser.
V8
V8 is the name of the JavaScript engine that powers Google Chrome. It’s the thing that takes our JavaScript and executes it while browsing with Chrome. V8 provides the runtime environment in which JavaScript executes. The DOM and the other web platform APIs are provided by the browser.
The cool thing is that the JavaScript engine is independent by the browser in which it’s hosted. This key feature enabled the rise of Node.js. V8 was chosen for being the engine chosen by Node.js back in 2009, and as the popularity of Node.js exploded, V8 became the engine that now powers an incredible amount of server-side code written in JavaScript. The Node.js ecosystem is huge and thanks to it V8 also powers the desktop app, with projects like Electron.
Other JS engines
Other browsers have their own JavaScript engine:
• Firefox has SpiderMonkey
• Safari has JavaScriptCore (also called Nitro)
• Edge has Chakra
And many others exist as well.
All those engines implement the ECMA ES-262 standard, also called ECMAScript, the standard used by JavaScript.
The quest for performance
V8 is written in C++, and it’s continuously improved. It is portable and runs on Mac, Windows, Linux, and several other systems. In this V8 introduction, I will ignore the implementation details of V8: they can be found on more authoritative sites (e.g. the V8 official site), and they change over time, often radically.
V8 is always evolving, just like the other JavaScript engines around, to speed up the web and the Node.js ecosystem. On the web, there is a race for performance that’s been going on for years, and we (as users and developers) benefit a lot from this competition because we get faster and more optimized machines year after year.
Compilation
JavaScript is generally considered an interpreted language, but modern JavaScript engines no longer just interpret JavaScript, they compile it. This happens since 2009 when the SpiderMonkey JavaScript compiler was added to Firefox 3.5, and everyone followed this idea. JavaScript is internally compiled by V8 with just-in-time (JIT) compilation to speed up the execution.
This might seem counter-intuitive, but since the introduction of Google Maps in 2004, JavaScript has evolved from a language that was generally executing a few dozens of lines of code to complete applications with thousands to hundreds of thousands of lines running in the browser. Our applications now can run for hours inside a browser, rather than being just a few form validation rules or simple scripts.
In this new world, compiling JavaScript makes perfect sense because while it might take a little bit more to have the JavaScript ready, once done it’s going to be much more performant than purely interpreted code.
Comments