JavaScript was conceived as a "just good enough" light scripting language to be replaced by something more strongly typed w/ a JIT compiler like Java (hence the name & perpetual confusion). As more & more UX has moved to the browser, it's inevitable that we've practically gone full circle to that with TypeScript making the language more robust (and easier for compilers to optimize) and WASM being the new closer-to-the-metal run-time.
(Aside: I think history will show that while Flash/ActionScript helped lead the way toward richer client-side interaction it was a huge, decade-long distraction that delayed adoption of more mature and non-proprietary tool chains that we're only getting now.)
The only reason JavaScript has migrated to the server is to allow developer skills to translate more seamlessly between the two domains.
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. Then, as always, your choice of framework/stack will make the most difference for long term productivity more than the language.
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".
It probably should be like that. And it very well may be someday.
This is a bit more like that sci-fi plot where aliens come to Earth to find what they need to save their failing homeworld. JavaScript on the server might come in under the banner of business but there is very specific purpose for it being there. The move in frameworks and tooling is an attempt to save the declarative application model popularized in client side web dev.
I think the frontend is probably more sensitive to this as we sort of caused this problem. But so much of the intent of going to the server is to solve the issues already happening in the browser. And WASM is still too far out to keep up with the steady rate of growth of JavaScript on websites.
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.
JavaScript was conceived as a "just good enough" light scripting language to be replaced by something more strongly typed w/ a JIT compiler like Java (hence the name & perpetual confusion). As more & more UX has moved to the browser, it's inevitable that we've practically gone full circle to that with TypeScript making the language more robust (and easier for compilers to optimize) and WASM being the new closer-to-the-metal run-time.
(Aside: I think history will show that while Flash/ActionScript helped lead the way toward richer client-side interaction it was a huge, decade-long distraction that delayed adoption of more mature and non-proprietary tool chains that we're only getting now.)
The only reason JavaScript has migrated to the server is to allow developer skills to translate more seamlessly between the two domains.
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. Then, as always, your choice of framework/stack will make the most difference for long term productivity more than the language.
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".
It probably should be like that. And it very well may be someday.
This is a bit more like that sci-fi plot where aliens come to Earth to find what they need to save their failing homeworld. JavaScript on the server might come in under the banner of business but there is very specific purpose for it being there. The move in frameworks and tooling is an attempt to save the declarative application model popularized in client side web dev.
I think the frontend is probably more sensitive to this as we sort of caused this problem. But so much of the intent of going to the server is to solve the issues already happening in the browser. And WASM is still too far out to keep up with the steady rate of growth of JavaScript on websites.