4 ms·
JavaScript really illustrates the ultimate path-dependence of evolution. It got widely deployed during a boom time and therefore we are stuck with it forever.
by api 2y ago
JavaScript really illustrates the ultimate path-dependence of evolution. It got widely deployed during a boom time and therefore we are stuck with it forever.
- Der_Einzige 2y agoBut I feel like other languages that we were de-facto "stuck with" in certain domains boomed and then busted - i.e. Lua, Pearl, etc
- actionfromafar 2y agoJavascript is the only language which straddled the Client Server Gap. If it weren't for Node, Javascript would not have been as popular.
- api 2y agoThere was something long ago called GWT -- Google Web Toolkit -- that tried to make Java into that language by having it compile to JavaScript. It actually worked decently well, but was due to Java needlessly verbose. WASM lets us run other languages efficiently in the browser but that just opens the field to a lot of languages, not one language to rule them all.
- actionfromafar 2y agoAlso GWT apps were pretty slow to load and start, and were very "app"-like as opposed to web-page like at a time when that was not as familiar as it is today. That's how I remember it anyway. And pretty heavy, developer wise, at a time when "update a file on the FTP" was still normal.
- bigstrat2003 2y agoIt's still absolutely baffling to me that anyone is willing to run JS server side. There are so many options which are much better suited, why are people willing to jam that square peg into the round hole?
- homebrewer 2y agoBecause they don't know and don't want to know anything else. Not a single polyglot developer I personally know have ever chosen JS for server side, not once.
- deleted 2y ago[deleted]
- sjamaan 2y agoPerhaps the siren song of "isomorphic JS", where you can run the same code on the server and on the client? I can see the use case for having complex model and validation code running on the client for speedy feedback and on the server for security, and perhaps also the idea you could render something entirely on the server when needed (eg for indexing and non-JS clients) and on the client when it's capable. Personally, I wouldn't want to touch server-side JS with a 10 foot barge pole.
- GiorgioG 2y agoWe don’t have to be stuck with it forever. Start pushing WASM instead of React, etc. We can get there, but as technologists we have to make a concerted effort to do so.
- adastra22 2y agoWe will still be stuck with it forever for compatibility reasons
- auggierose 2y agoWASM instead of React? That does not even make sense.
- pjmlp 2y agoOnly if the tooling was half as good as Flash.
- adamc 2y agoBut the essay lays out the reality: For WASM to replace JavaScript, it needs to be better (in the sense of easy to adopt, solves a problem right now) every step of the way. That is not, as yet, true.
- jll29 2y agoThe task of devising a novel application model for distributed Web applications is left to the reader as an exercise. (It's not _just_ JavaScript that one should get rid off, but the abuse of the whole HTML+X set of stacks to implement interactive Web applications. There must be a better way than HTML/CGI, HTML/XML, Java applets etc.; WASM could be part of a solution, but not a solution in itself., as there should be standard UI elements etc.)