The difference is simply where the JS code runs.

Both the browser and Node.js implement the ECMAScript standard, which defines the Javascript language. Standard Javascript built-ins like Date and String are defined in this standard, along with language semantics. Since both the browser and Node.js implement the standard, code that only uses built-in objects should run on both environments.

Where they differ is the other APIs each environment provides. The browser implements the Web API, which includes built-in objects like the document object. Node.js defines its own set of built-in's like require and Buffer . Node.js does not implement the Web API, so any code that makes use of the document object could not run. You'd get a reference error when execution reaches the part of the code that references document, although your code will be parsed and execution will start. Similarly, when run on a browser, code that makes use of Node.js built-in's will throw a reference error when it encounters the name it cannot resolve.

In practical terms, this means that front-end and Node.js serve different purposes. The purpose of the front-end is to interact with the user, so the code for the front-end needs to manipulate the page and other client-side things, and so the browser implements the Web API, which provides this functionality. Contrast this to the purpose of the server, which is to serve the front-end, interact with the database, and other server-y things, so Node provides API's that support those things. Therefore, most code is either written to run on Node.js or the browser. You also have libraries that essentially make parts of the API for one environment available in the other, allowing code to be more platform independent. Isomorphic Javascript is the buzzword for this idea.

So basically, Node.js and the browser are two separate platforms for different purposes. Both are Javascript runtimes, but have different API's above that.

Here's an article explaining what Node.js is: medium.com/@nishantagrwal/what-exactly-is-node-js…

Front ends with post/get or fetch () backend begin with get/post 😂😂😂😂

I think another answer you might be looking for, is that when you jump into a frontend project or boilerplate, what is all the backend node stuff and what's all the frontend browser JS stuff? This was pretty confusing to me for a while, because you have all this build process stuff going on, and the line starts to blur when developing if any of that webpack/gulp/grunt stuff ends up in the browser as well.

All of the build tools are using Node.js to manipulate the file system and run local dev servers and other various things. This is all being ran on your machine and not in the browser. But the browser code gets served up by this (node) dev server for you to see in your browser with localhost:8080 or whatever. Then eventually you use Node.js to package up your browser code into a bundle (or you could call it a web-package...). This bundle is going to be executed in the browser, but it was transformed into its final state using Node.js.

So basically anything that's usually in the src directory is going to be what's bundled up and sent to the browser. Anything that's in the webpack, grunt, gulp, server directories are going to be executing in the Node.js environment to assist you during development, and eventually helping you build out your production assets.

If you have a server-side-rendered (SSR) app, you'll have some of that Node.js code running as a server in production to serve up your html/javascript/css assets. But you'll usually always still have other build-process Node.js code that never is executed in production, and is only meant to help build the browser bundled JS.

I hope I wasn't too presumptuous in assuming this might be part of your question. I know that this was definitely a hazy thing for me for a while with all this isomorphic stuff going on. Especially when you're trying to download NPM packages that you think are for the browser, but it ends up only being for Node.js runtime.

Node.js is a part of front-end nowadays. There is no frontier between them. You should look Node.js as a tool.

If you mean the distinction between backend and frontend development. I would like to remind you of Universal JavaScript (aka Isomorphism JavaScript). With its appearance, the boundary between server side and client side has almost been removed.

On another point of view, JavaScript includes at least 3 areas:

• ECMAScript: the core of language
• Web APIs: anything JavaScript can do at client side
• Node.js APIs: relating to JavaScript's ability at server side

So if you really need a clear boundary, you might consider to look at there areas.

To begin with, the JS that runs on the client browser is the frontend JS. This is the JS that is downloaded every time the user asks for your web application. Nodejs sits on the server and is never downloaded to anything. There is no merged ending and beginning. They are two disjoint sets.