We Keep Coding

I got some questions while studying nodejs. Could you please help me?

I got some questions while studying nodejs.
Does nodejs support all Java scripts? The official document says it uses the latest v8 engine. I don't think all JavaScript engines will be supported because they follow the JavaScript used by the v8 engine.
How can I update to the latest v8 engine while using the old version nodejs?
When implementing and running a server using nodejs express or nestjs, which portion of memory does most of the time occupy? I thought it would take up the most memory as soon as I build it.

Does nodejs support all Java scripts? The official document says it uses the latest v8 engine. I don't think all JavaScript engines will be supported because they follow the JavaScript used by the v8 engine.
All spec-compliant JS engines implement the same language specification, so the fact that Node uses V8 doesn't matter for this question. (This is very similar to how all (modern) browsers support the same JavaScript.)
How can I update to the latest v8 engine while using the old version nodejs?
You can't.
Sometimes, there is a bit of wiggle room (e.g. early Node 14.x releases used V8 8.1, later 14.x releases updated to V8 8.4), but you couldn't just take e.g. an old Node 10.x build and stick V8 9.2 into it.
And as Bergi says: just update Node.
What accounts for the most memory when implementing and running a server using nodejs Express or nestjs?
That totally depends on how you write your server.
Once you observe a problem (whether it's memory, or performance, or something else), profile it to figure out what's going on.

How do you ensure compatibility JavaScript libraries for the browser and for node.js

I'm working with a team on a TypeScript librabry called Classical.js, and we would very much like the core module of this library to be JavaScript environment agnostic. In my mind, that means it should not only function correctly cross-browser, but also as a dependency in a node.js project.
First of all, am I missing any major JavaScript environments in my test matrix that I should be aware of?
Unfortunately no one on the team develops with node. Therefore we're not quite sure what APIs to avoid (obviously the DOM) to ensure compatibility. Are there are a standard set of GOTCHAs that node developers run into when using code that has only been tested in the browser?
One discrepancy that we did (hopefully) account for the name of the global scope, which, if memory serves me correctly, is represented by an object named global in node and window in the browser. These are the sort of GOTCHAs that we are looking for.

I think you have an important issue here, one that that's currently underexposed: you want to create an isomorphic library, and you want to know which libraries you depend on are isomorphic. I think it would be a good thing when isomorphic modules would be clearly marked as such in for example npm.
There is a nice blog on this topic here: http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
Basically, isomorphic libraries should only use functionality build in JavaScript the language itself (ES3, ES5, ES6, ...).
You should avoid anything related to the DOM (window, document, navigator, ...), as this is only available inside a browser environment.
Many core modules of node.js cannot be used in a browser (like file system, os, process, network, streams, etc). For many core modules there are browser safe versions available (for example for crypto and http). Browserify uses these versions when bundling a node.js app for use in the browser.
There are a lot of JavaScript engines out in the wild, implemented in all kind of languages like C, Java, Python, etc. Also running directly on hardware like Espruino. These engines may not be 100% compliant with the language specs. For example, I encountered one day that the JS engine in Java (I think it was Rhino) didn't like a variable to have the name boolean. In these cases I would argue that these engines should get better compliancy rather than you having to work around their bugs/limitations.
Anyway, there is an easy way to test whether your library is isomorphic: try to run it in both node.js and the 5 biggest browsers :)

Differences between Node environment and browser javascript environment

I've always been a bit annoyed that there are two major realms of javascript projects -- Node and "the browser" -- and while most browser JS can be easily run inside Node with a couple libraries for DOM stuff if needed, porting Node stuff to the browser is usually an afterthought.
This all seems like a lot of wasted energy on the part of developer communities, which could be alleviated by all JS developers just developing for the "least common denominator" (the browser) and using various shims to use features only available in Node or other JS environments besides the plain old browser.
This would not only cut out a lot ecosystem cruft and make development-in-the-browser more realistic, it also makes it commonplace to give the browser superpowers…Look for example at browserver, which sets up an http server inside the browser, but because the browser cannot actually accept http requests, uses websockets to talk to a proxy Node server that can.
So I want to ask, what are the real technical constraints of a web browser's javascript environment versus Node?
I thought Node was just "a javascript environment, plus http server and local filesystem, minus the DOM and the chrome". Are there technical reasons why developers could not potentially move to the approach I described above, developing for the browser JS environment (does this have an official name?) and using shims for Node?

Code that runs on the client usually have very different goals from the code that runs on the server. However when it makes sense to use some libarary's features in both environments there are a lot of them that are defined using a universal AMD form which makes them platform independent (e.g. Q).
The major difference between both environments is that one is subject to rigorous security policies and restrictions (browser) while the other isin't. The browser is also an untrustable environment for security-related operations such as enforcing security permissions.
I'll also add #jfriend00 comment in here since I believe it's also very relevant a exposes other differences:
The biggest practical difference is that you have to design a browser
application to work in an installed base of existing browsers
including older versions (lowest common denominator). When deploying a
node application, you get to select the ONE version of node that you
want to develop for and deploy with. This allows node developers to
use the latest greatest features in node which won't be available
across the general browser population for years. #jfriend00
Projects like browserver are interesting and I am all for experimental development, but are they truly useful in practice? Libraries should be designed for the environment in which they are truly useful. There are no benefits in making all libraries available in both environments. Not only that it will generally result in an increased code complexity, some features will sometimes not be shimmable resulting in an inconsistent API between platforms.

Here are some of the differences between these two environments:
Node.js has built-in libraries for HTTP and socket communication with which it can create a web server and thus be a replacement for other types of servers such as. Apache or Nginx
Node.js does not have browser APIs related to DOM, CSS, performance, document, as well as all APIs associated with the "window" object. Precisely because of the lack of a window object, the global object was renamed "global".
Node.js has full access to the system like any other source application. This means it can read and write directly to or from the file system, it can also have unlimited network access, and it can execute software...
Since the development of JavaScript is moving very fast, browsers often lag behind the implementation of new features of JavaScript, so you need to use an older version of JavaScript in the Browser, but this does not apply to Node.js, you can use it all modern ES6-7-8-9 JavaScript if your version of Node.js supports it.
Although within ES6 there is a syntax for working with modules (import/export syntax), it has only recently been added to node.js as an experimental option. Node.js mainly uses CommonJS syntax to work with modules.

V8 and ECMAScript differences

Where can I find a list of all the differences between V8 and ECMAScript? For example V8 supports const, which isn't part of the ECMAScript standard.

Edit: Direct answer: Track status of ES5 implementations in progress which indicates the V8 googlecode issues tagged es5
or https://github.com/joyent/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8
V8 implements all of ES5 currently aside from a handful of edge cases, and only then in order to be compliant with the majority of how other current browsers handle the given situation.
Because it won't be living on its own nearly all of the differences you'll be dealing with will be in the host environment implementation wrapped around it. For most uses this is the various APIs web browsers provide. As a non-browser example, Node.js provides custom APIs for file system and network interaction. In terms of core language there's just not that much wiggle room. Minus the DOM, JavaScript is a pretty damn simple language to use (part of why it's so awesome) and has a really specific Specification document.
ES5 is an iteration up from ES3 and nearly 100% backwards compatible if not using 'use strict'. After nearly a decade of stagnation along with inability to gain a consensus among major JavaScript engine implementers ES5 was born and limited primarily to cut out and address the worst issues with the language. The extent of mainstream use ES5 is Array extras, Object extras (mainly Object.create), Function.bind, and strict mode (which is entirely about stripping features out), and a handful of natives helpers like built in JSON and base64.
Most of this 240 page specification is spent in laboriously defining every detail about behavior that has existed in JavaScript for almost 15 years, as well as the list of features which will be deprecated and eventually removed (with, various uses of eval, etc.).
Harmony (ES6) is the first real big change we're going to see. ES5 accomplished the goal of getting engine implementations on the same page and gutting most of the problematic parts of JS. Looking forward to ES6, it's time to address some fundamental language issues that require syntax changes to fix. ES6 is scheduled for finalization in late 2013 but large chunks are already implemented in JS engines in order to test them and see how they work in practical usage. The web is a living thing and implementing new standards isn't a matter of creating a new spec and then unleashing it on the world like it is most other industries. Ideas are floated and must past muster at both the implementer level (the guys who write V8, Spidermonkey, JSC, Chakra, etc.) and then the actual user level (user in this case being web developers writing code to run in those engines). Ivory tower dictation just results in lack of use.
Specifically in the case of const: this is currently not exactly defined entirely. It's a keyword with similar but not exactly the same functionality in V8 and Spidermonkey, and has a similar but not exactly the same meaning for ES6. You're probably safe to use it if you expect your target audience's engine to support it currently, but as implemented it wasn't technically part of any official spec. migrating let' andconst'
Beyond that there's "Host Objects" which are exposed by the given engine a JS script is running in. JavaScript existed first as an implementation and second as a specification, so until recently it wasn't obvious to non-experts to know where the diving line is. When it's running in a browser (as is usually the case) the Document Object Model is exposed as a host object for automatic usage. The functionality of the DOM is largely described using IDL and is under the purview of the W3C. The multitude of specification implementations encompass 6 top level sections, almost 50 separate working groups, and around 1000 separate specifications. These are interfaces exposed to JavaScript but completely ungoverned by the requirements of any JavaScript specification. The DOM encompasses a huge space of described functionality and continuously changing implementations thereof.

SpiderMonkey vs JavaScriptCore vs?

I have a C++ desktop application (written in wxWidgets) and I want to add support for some scripting language.
Scripting would mostly be used for run-time conversions of strings, numbers and dates by user supplied JavaScript code.
I'd like to use JavaScript because it is widely used and everyone is familiar with the syntax.
Googling around, it seems I have two options:
SpiderMonkey from Mozilla
JavaScriptCore from WebKit
Has anyone tried those? Which one would be easier to set up?
Do you know of some other implementation that is better for my needs?
BTW, I target Windows and Linux platforms.

There is also Google's V8 JavaScript engine, builds nicely on Linux, embedding API seems quite straightforward too: (Compared to SpiderMonkey's, never looked at the JavaScriptCore API)
http://code.google.com/apis/v8/get_started.html

Of course, you could also use Lua, which not only is designed specifically for this, it's vastly faster than any JS.
Also, it's has well-designed semantics, a very minimal core, simple C API, great portability, a very mature JIT, the most helpful online community I've seen, etc...

JavaScriptCore has a stable C API (and ABI), and has been available (and used as) a standard system framework on macos.
[edit: oh, and it works on linux and windows as a standalone library, although i believe only debian distributes it as such]