[rsp1984]

> What exactly needs to happen to make server-side JavaScript run in the browser?

That sounds like an oxymoron to me. I have honestly no idea what they mean by that. To me, a browser is client-side software, so saying you want to run server-side JS on it doesn't make any sense. They mention it several times in the article but I simply can't follow.

Could someone with a deeper understanding ELI5 this to me?

[pphysch]

It doesn't make a lot of practical sense, but basically they want to reuse substantial amounts of server code as client code. A fundamental misunderstanding of the client-server model, methinks.

[aheieosnssisowi]

You can't see a good reason to validate form inputs client side and use the exact same validations server side?

[pphysch]

That's nonsense. There are many validations that you don't trust to client to handle (or will require API calls, making "exact same" an unreasonable expectation). Ultimately, frontend validation is for UX and backend validation is for security.

Different concerns, different capabilities, different code.

[deckard1]

Code reuse. If I need to render on the server (for SEO purposes, as most people do not rely on Google's dubious and unknown JavaScript processing ability) then it makes sense to want to share as much code as possible between the server and the client. If you're doing a single-page-application (SPA) you can also share routing code, as your client will need a way to route to pages client-side.

With that said, I've seen people argue against node APIs and this desire to only use web APIs on the server. I don't get that. Node's API is generally pretty good and using JS as a replacement for Python/Ruby/etc. locally is rather excellent today. You don't need neutered APIs to also write code that works in both client and server. Unless you're selling cloud native bullshit (ahem, Nextjs)

[tomtheelder]

I think what they are really saying is "What needs to happen to allow us to run server-side _style_, module-based JS run in the browser.

Basically the point being that the browser "version" of JS has a lot of limitations w.r.t dependency resolution and standard library usage, and that by either using a bundling tool or whatever is being proposed here you can avoid those. In that way you end up writing "server-side JS," basically NodeJS style JS, for the browser.

Major added benefit is that it allows you to use the same libraries/packages/whatever on both client and server. That's highly convenient.

[thex10]

Full stack devs working with JS on the backend love to be able to reuse their code on front and back end when desired. This question is relevant to them and them only.

[jagged-chisel]

Like using libraries, or packages. I can reuse those on the front-end, the back-end, command line tools, or wherever else I want.

[Ygg2]

A bit simplistic of a take, consider games. First client server games made server deal with logic, exclusively.

Modern (post Quake) games make server authoritative but allow server logic to run locally.

What modern JS app do is something hybrid client/server rendering. It's akin to moving/transmitting code from server for faster rendering.

I think they use it for offline web apps and to fix problems with server side rendering (usage of resource, time to first render).

[agumonkey]

We're going to have locality optimizing migrating code.

[kerryoco]

it has nothing to do with server side business logic. It's simply that javascripts package manager, npm, was widely adopted to server / node needs. And then the notorious "node_modules" folder, which was before handled by server compilation, became a part of clientside dev too because it had so many goodies in it, so now the client was de facto having to do the same build as the server, so, by "server side code", I think it's safe to say what they mean is "node modules".