4 ms·
There is no "war against Javascript" as the author suggests. It just happens to be the chosen language of the now insidious ad-driven corporate-sponsored web b
by feelin_googley 9y ago
There is no "war against Javascript" as the author suggests. It just happens to be the chosen language of the now insidious ad-driven corporate-sponsored web browser.
It is not Javascript per se, but the so-called "modern" browser that creates problems for so many users. The problem is not even that this program exists. The problem is that users are coerced to use it and it is controlled by a third party that needs to sell something, either to advertisers or to users.
Again, there is nothing inherently threatening about Javascript. There are many languages to choose from and anyone can choose not to use it. It is not tied to the web browser anymore. Unfortunately it is from that association that it gains a stigma like the one the author suggests with his "war on Javascript" comment.
Today, there are a variety of standlone JS interpreters, of all sizes, and the language is routinely used outside of the browser. Peer-to-peer projects use it. Tiny interpreters for microcontrollers use it. Javascript can live on without the corporate web browser.
The problem is the irrational assumption one must use a corporate sponsored web browser to do anything interesting with a computer. This program automatically runs code from "anonymous", commercial third parties, which today happens to be JS, using the user's computer resources. The user today does not get to choose the language, but more importantly, given the level of coercion and absence of alternatives, she does not get to choose whether or not to run the third party code.
- kbenson 9y ago> There is no "war against Javascript" as the author suggests. Well, there's my war on Javascript, that I wage in my head every time I have to use it. > Again, there is nothing inherently threatening about Javascript. Well, it's not inherent, but it exists. Javascript has (had, with WebAssembly) an inherent advantage in that even though you could compile to JavaScript, there was an inherent mismatch the farther your language semantics were from it. CoffeeScript is straightforward. Others are less straightforward. Rust requires a huge amount of runtime to be shipped even for WebAssembly. > It is not tied to the web browser anymore. So, the beachhead is secure, time to advance into the countryside, eh? ;)
- zeveb 9y ago> It is not Javascript per se, but the so-called "modern" browser that creates problems for so many users. I think that it's both-and, not either-or. JavaScript itself is a terrible, horrible, no-good language; the modern browser environment is also a terrible, horrible, no-good invasion of privacy and destruction of security. I do not believe that there is any purpose for which JavaScript is a suitable language (absent considerations of popularity, e.g. as on the web browser), although I could be wrong and am open to counterexamples.
- umilegenio 9y agoIt was more of a lighthearted joke about the attitude that many have toward JavaScript than an attack on the language itself. I have nothing against JavaScript, although it is not a splendid example of design it certainly works for what was designed for. But I think it also undeniable that would choose something else for many tasks, if they had the option. If you wanted, you could also use JavaScript for an entire operating systems just for JavaScript[1]. However this does not mean that it is good idea to do so. [1] https://github.com/NodeOS/NodeOS https://github.com/NodeOS/NodeOS
- Roboprog 9y agoNot everybody wants “Scheme in the browser”. In the spirit of “Worse is Better”, plenty of people want to run C++ in the browser. I’m not one of them, but hey, whatever floats your boat. That said, I’d like a few useful libraries (e.g. - fixed precision decimal arithmetic) written in web assembler. But otherwise, I actually prefer writing in JavaScript (as FP more than OOP) over C++/Java/C# (degenerate Simula 67 clones) for most application level tasks. Writing in C++ won’t make DOM access or async I/O go away, though :-)