💾 Archived View for thrig.me › blog › 2022 › 10 › 14 › portability.gmi captured on 2023-04-26 at 13:28:50. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
JavaScript is not a portable language. Others will argue contrary, claiming that JavaScript is a very portable language, if not the most portable language. The difference here relates to how the term portability is being used.
SQLite, a rather portable database is coded in C, a rather portable language:
https://www.sqlite.org/whyc.html
JavaScript is not even mentioned--doubtless an oversight, if JavaScript is the most portable language--words are instead spent shooting down C++ Go Rust. The major sections "Compatibility" and "Low-Dependency" and "Stability" all capture aspects of...what is the definition of portability? The relevant dictionary entry runs along the lines of "Computing (of software) able to be transferred from one machine or system to another." By that definition, compatibility, low-dependency, and stability would all assist with making software able to move from one machine to another. C and SQLite fit this bill. JavaScript? Eh...
"Using functions to extend the base language explains why a language that is so low level can be so portable. C compilers have been built for more than 40 different machines, from the Z80 to the Cray-1." -- Johnson SC, Kernighan BW. C LANGUAGE AND MODELS FOR SYSTEMS PROGRAMMING. Byte. 1983 Jan 1;8(8):7 pages between 48 and 60.
So how did JavaScript come to be seen as highly portable, if not the most portable language on the planet? Arguments here run along the lines of JavaScript being commonly available, therefore portable. If you want to reach lots of people, use JavaScript, therefore portable. Let us instead run JavaScript by the terms used in the SQLite article. Compatible? No, I cannot enable JavaScript in `w3m` however much sites instruct me to do so. Low-Dependency? Chrome or other such heavyweight champions have rather bulky hardware and software requirements. Stability? In the latest webware du jour? But, lots and lots of people can run JavaScript! Quantity does have a quality of its own. "Portable: to be available to lots of humans" does, however, not fit the computing definition of portability. Maybe the dictionary will add this new sense, in time. Meanwhile, "availability" or "deployment" would likely be better terms: JavaScript is widely available, JavaScript is widely deployed, JavaScript is not portable.
Chrome is not portable; it lists downloads for the limited set Linux, macOS, Windows. (And consider the hardware requirements.) Those operating systems are widely available and widely deployed, popular, but that's not portability. Those who pull the strings at Google have no (or negative) interest in OpenBSD; other folks perform the thankless task of trying to make something that is not Chrome less bad on the portability front. Look at all them patches!
https://cvsweb.openbsd.org/ports/www/chromium/patches/
Binary portable/not portable is all well and good--does it compile and run on OpenBSD? or the 2009 MacBook? no? not portable!--another approach would be to devise some sort of metric and rank languages where they fall on a number line. These numbers need not be specific (especially in a quick posting such as this one) so we could start with the claim that C is extremely portable. It took unix lots of places, and that's not even touching embedded. It might be fun to determine what the least portable language on the planet is--perhaps something from Microsoft that only ran in some Internet Explorer on Windows (and what dreadful sites those were) or AppleScript or perhaps an embedded language that only works on that one CPU with a very expensive and proprietary programmer. As one towers more atop C portability goes down; vi requires some sort of unix environment, SQLite does not. X11 is more portable than Wayland, etc.
https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and
The Wayland "reference implementation" is a small set of libraries that can be used to build a compositor or a client application. These libraries currently have hard dependencies on Linux kernel APIs like epoll. In pkgsrc we've patched the libraries to add kqueue(2) support, but the patches haven't been accepted upstream. Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs.
Upstream is not portable and does not accept patches... where have I heard that song before...
So where does this put JavaScript? If shackled to the browser, the portability is not very good, but is better than something that required particular versions of Internet Explorer on Windows. Firefox cannot be compiled on a 32-bit OpenBSD because the compile takes too much memory. Heh! Bloat! Chromium (to say less of Chrome) does not work on the 2008 OpenBSD laptop, because nvidia video card. Stray outside the narrow confines of modern Wintendo systems and one quickly reaches "nope, does not work" territory. Not portable. I suppose browser-shackled JavaScript also works on smartphones, which does add portability. So perhaps not terrible on the portability front, but by no means stellar.
Minus the browser, Duktape or node can JavaScript. This increases the portability, but without a metric and good data one might be hard pressed to say whether JavaScript stands out in a room crowded with Perl, TCL, Ruby, PHP, etc. Duktape looks to have limited support for Post-ES5 features, so you're probably stuck with node if you're ES6ing. Perhaps someone has embedded JavaScript? How would that differ from, say, Pforth on the portability front? Compared to ECMAScript, Common LISP is available in the major implementations Allegro CL, ABCL, CLISP, Clozure CL, CMUCL, ECL, GCL, LispWorks, Scieneer CL, SBCL, and Symbolics Common Lisp. All deeply unpopular, but that's not what we're talking about here. If I had to guess, JavaScript's portability (minus the bloatbrowser) is about average.
Worse, JavaScript does not need to be portable. It's practically mandatory to function in the modern Internet connected economy. Do Apple or Google need to make their offerings portable? The opposite; portability would increase their costs. Why even support something marginal like OpenBSD, or hardware older than a few years? That's expensive. Or why did Microsoft lose their edge in the browser race? Signs point to less portability in the web-world. And it will be popular.
tags #c #javascript