[klodolph]

You may technically be coding in one language, but JS written for Node looks radically different from JS written to run in the browser. In my experience, there’s rarely more than some small chunks of code that you touch that will run in both environments.

If you get some better tooling for multi-language development, it will usually pay off a lot faster than choosing Node for your backend will.

[excursionist]

JS in Node and JS in browser is not that different. It's the same language, using the same JavaScript engine (v8 for chrome). The difference is in the APIs provided by Node vs Browser, which is pretty minor. Many popular JS libraries will run in Node just as well as Browser. That being said, JS is a pretty shit language and I don't know why anyone would want to use it for backend work.

[klodolph]

My experience is different. I write a decent amount of JS code each year and try to catch up with current best practices where I can, but every year it’s been a bit of a pain to write any code that’s shared between browser and client. Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async (shockingly, with backend support lagging).

These days my main strategy is to have three TypeScript projects—frontend, backend, and common. I then whitelist imports in the common libraries.

> It's the same language, using the same JavaScript engine (v8 for chrome).

I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.

[excursionist]

> Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async

New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code.

> I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.

The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.

[klodolph]

> New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code.

For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client.

My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place. Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc. There’s a whole pipeline between your source code and the JavaScript engine, and that pipeline has a different shape for backend and frontend, and typically uses completely different libraries to make it work.

> The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.

I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine. I haven’t figured out a way to leverage that fact to give me any additional productivity.

For the projects I’ve worked on, it can end up taking me quite a bit of time figuring out how to make one piece of code work in both frontend and backend, even though I can trivially make it work in either environment as I please.

Maybe other people have already solved this, but I recently went through and made a bunch of PRs to fix a common issue I saw in other people’s codebases and it was super rare to see any code shared between frontend and backend.

[excursionist]

> For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client.

You still have to identify which polyfills you need, add them in, test them, etc. Polyfills are also quite buggy especially for new features from my experience. Also, the fact that you're typically running your build, packaging, linting, testing etc. on Node for your frontend code, says a lot.

> My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place.

When is that really even a consideration though? When do you actually need to deploy your frontend app to Node? If you have common model code, or say, input validation/sanitation, business logic, etc - that can easily be identical for both browser and Node.

> Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc.

That really depends on your setup. You can do imports at runtime or build time for both Node and browser. If you're transpiling the setup is pretty much identical.

> I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine.

How do you run your unit tests, your static code analysis, your packaging and traspiling? Do you run it in the browser or in Node? There is no fundamental difference between JS of the same version in Node vs Browser. Any browser specific or Node specific libraries/features you use are generally not part of any stable JS spec.

> it was super rare to see any code shared between frontend and backend.

Well I'm assuming these are different applications, so that's expected. I don't know why you wouldn't share your model definitions and/or validation/sanitation code though. People do this even for backends/frontends written in different languages.

[everybodyknows]

>same JavaScript engine (v8 for chrome)

That way lies surrender by default to the Google empire.

[excursionist]

What? It's just a simple fact that Node, Chrome and Chromium all use V8 - which is an open source BSD licensed project.

[honopu]

Depends. It sure is nice to write helper functions that I can import on the serverside js and in the client side. Also if you use next or nuxt or something like that you get universal rendering, which is nice. Totally depends on your use case.

You just have to keep an eye on your client bundle size if these shares functions ref something like underscore, moment or something like that where you’re pulling in the entire thing for one function. I’m aware you can just pick pieces with {} and import, but not everyone is aware and often require the entire thing.

[egeozcan]

The purpose of next (and perhaps nuxt, I've never used it) is more in the direction of a front-backend. The API-implementing level is usually very different than the one consuming it, even when the consumer is on the server-side. If this wasn't the case, IMHO, projects like Meteor would be immensely more popular.