> 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.
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.