In any case, the trends are clear: You'll be able to pick your language of choice (TypeScript, Python, C#, etc.) and run that on client-side or server-side.
I think this is perhaps the prevailing, oversimplified view that fails to account for the significant difference in the original development environments these languages were designed for.
TypeScript has the advantage that it transforms to the language where the runtime and supporting APIs already exist on the target platform.
Languages like Python and C# do not have that luxury on the front end; they have to bring their runtime and standard library along with them over the constrained network; it's something these languages don't have to deal with on the "install it once" back end.
Even in the upcoming, predicted "WebAssembly Golden Age" the web's deployment model isn't going to change. Sure things can be cached but they can also be just as quickly ejected if the application tends toward the same kind of bloat that is typical of back end and native development.
The mandate to stay lean won't go away even with WebAssembly. Because of that mandate minimal runtime languages like C, C++, Rust, Zig (and perhaps AssemblyScript) will likely be favoured for WebAssembly but typically those languages also come with a slower development pace.
The only reason JavaScript has migrated to the server is to allow developer skills to translate more seamlessly between the two domains.
That was the reason that was usually cited when the hype around "universal" or "isomorphic" JavaScript initially grew. However the driver behind Gen 3 is to get around the 1 App for the price of 2 problem.
It's for this very reason that the Clojure community tried to keep ClojureScript as close as possible to Clojure, so that they could maximize reuse between server and client (within limits).
In terms of the web the front end client is the most constrained party and JavaScript is the most universally supported runtime, so it makes sense for the server side to simply adopt it from the reuse perspective.
That said the server side has access to options the client side doesn't and those options may lead to "even faster server side JavaScript".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this is perhaps the prevailing, oversimplified view that fails to account for the significant difference in the original development environments these languages were designed for.
TypeScript has the advantage that it transforms to the language where the runtime and supporting APIs already exist on the target platform.
Languages like Python and C# do not have that luxury on the front end; they have to bring their runtime and standard library along with them over the constrained network; it's something these languages don't have to deal with on the "install it once" back end.
Even in the upcoming, predicted "WebAssembly Golden Age" the web's deployment model isn't going to change. Sure things can be cached but they can also be just as quickly ejected if the application tends toward the same kind of bloat that is typical of back end and native development.
The mandate to stay lean won't go away even with WebAssembly. Because of that mandate minimal runtime languages like C, C++, Rust, Zig (and perhaps AssemblyScript) will likely be favoured for WebAssembly but typically those languages also come with a slower development pace.
That was the reason that was usually cited when the hype around "universal" or "isomorphic" JavaScript initially grew. However the driver behind Gen 3 is to get around the 1 App for the price of 2 problem.
It's for this very reason that the Clojure community tried to keep ClojureScript as close as possible to Clojure, so that they could maximize reuse between server and client (within limits).
In terms of the web the front end client is the most constrained party and JavaScript is the most universally supported runtime, so it makes sense for the server side to simply adopt it from the reuse perspective.
That said the server side has access to options the client side doesn't and those options may lead to "even faster server side JavaScript".