12 ms·

The JavaScript Black Hole: A playbook for ethical engineering on the web

106 points by orthecreedence 7y ago

wincy 7y ago
Thanks for posting, I’m interested in reading it. However, I’m reading the article on my iPhone and the scrolling hijack is really annoying. It scrolls less well than native scrolling and is jerky and makes it difficult to read. Why do people do this with their blogs?
- henriquez 7y ago
  Author here - there's no scrolling hijack on my pages. I also dislike this sort of thing. Which iOS are you using?
  - wincy 7y ago
    iOS 12.4. When I scroll up or down normally the intensity of the flick causes it to scroll faster or slower. It feels like there’s a “hard stop” on the page, the scrolling stops sooner. Scrolling slowly seems to be off by a pixel or something, almost like a judder. I didn’t see the same issue on Chrome on my Mac.
    - adrianhel 7y ago
      Scrolling on iOS browsers is an utter pain due to rubber band scrolling. It can be solved with -webkit-overflow-scrolling and hard work.
  - wincy 7y ago
    I know Firefox for iOS uses WebKit so not sure how useful the information is, but the same “issue” is present there. The scrolling is just different.
  - robocat 7y ago
    I think that is sometimes caused by using an onscroll event without the {passive: true} option set. Even better, remove all onscroll events (including from libraries or adverts you may use).
  - jmull 7y ago
    I’m not the previous poster and I’m not sure if this is the same, but on iOS Safari there is something odd about the page scroll. Normally on iOS, when you scroll a page, the title/address bar shrinks. You can tap it and it expands, and tap it again and it scrolls you back to the top of the page. None of that happens on your page. I don’t really notice that the scrolling itself is off, but I’m probably not that sensitive to that kind of thing. This is latest iPhone OS and iPad OS, 13.4.
- buffin 7y ago
  I didn't notice anything fishy with the scrolling. Using the latest firefox on MacOS.
guessmyname 7y ago
I had the opportunity to work in the analytics team at MindGeek a couple of years ago. My team would spend days researching about all these seemingly useless features in modern web browsers to find new and better ways to track users across all our websites. I still remember when the HTML Canvas Element [1] was introduced by Apple almost two decades ago, many of these adult websites managed to increase the accuracy of their corresponding device fingerprint algorithms [2] by leveraging the power of the new APIs. In fact, one of the reasons why Fabian Thylmann tried to acquire XVideos back in 2012 [3] was because their analytics team had engineered new ways to track users using WebGL [4] which was still quite new. I don’t know if device tracking is still relevant for their revenue model, but I am sure they still have the code running in most —if not all— their websites for one reason or another. [1] https://en.wikipedia.org/wiki/Canvas_fingerprinting https://en.wikipedia.org/wiki/Canvas_fingerprinting [2] https://en.wikipedia.org/wiki/Device_fingerprint https://en.wikipedia.org/wiki/Device_fingerprint [3] https://en.wikipedia.org/wiki/XVideos#History https://en.wikipedia.org/wiki/XVideos#History [4] https://en.wikipedia.org/wiki/WebGL https://en.wikipedia.org/wiki/WebGL
chrischen 7y ago
For the section about how javascript can only be added onto (such as with typescript), I disagree. Now that we have compilers and transpilers like Babel and Typescript, it means we can effectively code how we want (even with different languages like reasonml, ocaml, purescript, or ESNext), and in theory browser venders can simply make a new target language or version of JS that these compilers can target.
- timw4mail 7y ago
  I've always found this to be a strange argument. You have that layer of indirection from the transpiler (which may mean very difficult integrations with JS tools), and it isn't always trivial to interact with actual Javascript.
  - WorldMaker 7y ago
    Even C is a layer of indirection that doesn't always reflect the output machine code (much less the assembly language somewhere between). Most of programming language decision making is choosing the stack of "indirections" you feel most comfortable with. Most of programming tool design is helping you navigate those indirections, and the techniques are generally the same in most cases. C you have symbol files and tools that can read them such as debuggers. JS you have sourcemaps and tools that can read them such as debuggers and browser consoles. The tools aren't always perfect, but they get better all the time. It's also a spectrum of choice for which stack you feel comfortable with. Babel and Typescript do increasingly less transpilation with major browser releases. In many cases Typescript today really is just JS with Types. Certainly options like ReasonML and Purescript exist on the opposite end of the spectrum, very little resemble JS, do a lot of more work in transpilation (and do sometimes make JS interop intentionally hard by treating it as an FFI or equivalent boundary). The added "indirection" has trade-offs in productivity, developer "comfort", project aesthetics and synergies.
  - chrischen 7y ago
    If anything there are better JS tooling around writing your code with ESNext or Typescript than just plain javascript.
elldoubleyew 7y ago
Genuine question as a rookie developer: I write a lot of internal tools for my company used in manufacturing/fulfillment. We generally deploy these as fleets of Raspberry Pis. The front ends for these systems are generally pretty simple, they just walk an operator through what they should be scanning, and for hardware interaction I use a small node server. I serve a React App to these stations (from an internal server) to render this UI. What (modern) alternatives are there for this that do not use web technologies? I've recently grown an affinity for ruby and attempted to rewrite my frontend in Shoes, but the barebones documentation and lack of SO answers made that a huge pain in the ass, not to mention the added steps in deployment of updates. Going any other route just seems like so much more work for no true benefit.
- orthecreedence 7y ago
  Honestly, if what you're doing works, go for it. Using javascript/html as an internal tool for UI building seems like a fairly decent use-case. You could write your UI in some sort of native toolkit like QT/Gtk/etc but then you're pumping dev cycles into making something that already exists and works fine...for what? If everyone who uses your UIs already has a browser, then you've hit a sweet spot: your client software is already pre-installed on all the machines you need it to be, and the rest is serving HTML/javascript. The alternatives for you are probably pretty time-intensive for you and probably annoying for your users ("hey, install this program/app/etc"). I'd say if you want to rely less on JS and use more server-generated HTML, PHP might be the simplest option for you. People around here shit on PHP, but PHP was "serverless" before it was cool and has a lot of tools to do exactly what you're doing. But again, ask yourself what you gain by switching to another technology.
  - pdimitar 7y ago
    PHP is definitely an awful recommendation for a RPi 4 though. There are lighter weighted options that optimise for minimum latency and minimum CPU overhead.
    - orthecreedence 7y ago
tiborsaas 7y ago
Stopped reading it at "JavaScript is a toy programming language." While the author is not alone with this view, it's shared by many of my backend colleges. With such a condescending view I will hardly gain any insight I'm afraid.
- Torwald 7y ago
  JavaScript is a Scheme with a 90ies pop-art name. It runs on the server it runs in the browser. The curly brackets. What's not to love?
  - Spivak 7y ago
    JavaScript isn't Scheme: https://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/ https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- axguscbklp 7y ago
  Yeah, JavaScript has problems but come on, just the fact that it has closures and first-class functions (and did a lot to popularize both, for that matter) makes it pretty cool in my book. It's a fun and powerful language. The author also trots out the standard go-to argument of JavaScript haters. He writes that JavaScript "has deeply ingrained quirks and bugs which can never be fixed without breaking the millions of scripts that have made peace with the existence of those bugs and depend upon the well-known workaround" and he links to https://github.com/denysdovhan/wtfjs https://github.com/denysdovhan/wtfjs, a typical list of JavaScript's well-known type-casting quirks, etc. Pretty much all languages have little quirks. Actual JavaScript programmers usually learn how to avoid JavaScript's quirks pretty quickly and easily. In my experience, people who fixate on JavaScript's quirks generally do not understand the language very well. If they did, they could criticize more substantial things about JavaScript than just things like "[] == ![]; // -> true".
hn_throwaway_99 7y ago
> JavaScript is a toy programming language. Bullshit. Yes, javascript has evolved a ton over the decades, and it has a lot of cruft that it pulls with it. So what? So does virtually every other successful language. I was a Java developer for over 15 years before I switched to mainly developing in Node/Typescript, and I feel I am much more productive in this ecosystem than I was in Java.
- The_Colonel 7y ago
  I'm kind of similar although I stll work on Java/Kotlin enterprise apps professionally and do JavaScript for hobby projects. And I must actually say that it's a joy to work in modern JavaScript. It has some very nice features (async/await, destructuring, null coalescing, functional features) which make it expressive and succint. It has decent performance as well, nice (lack of) tooling (no need to compile anything!) I probably would not do a huge project with it though (TS would be better fit there).
- rhinoceraptor 7y ago
  And even if it is a toy language, it doesn't matter. If you're a web developer, you need to know Javascript.
  - pdimitar 7y ago
    But if you can afford it -- and many projects actually can -- you can work on top of it through TypeScript or Elm, and the experience is much better.
- bsmith0 7y ago
  Agreed, this type of article is such a circlejerk. People love to hate JS.
- Spivak 7y ago
  I think the problem is ultimately a combination of popularity and forced-usage that creates opinions like these. JS has remarkably less weirdness and cruft than other ubiquitous languages like Bash and Python because of how quickly browser vendors are able to iterate on it. Every little piece of the language has millions of eyeballs on it.
duxup 7y ago
This reads like sort of a grand collection of mostly legitimate individual technical complaints about a lot of things JavaScript / Browser. But I still can't get past the fact that when I work for a company that wants to write a web app it is just like magic that it works across all these operating systems, phones, and etc provided they have a capable browser. To me that utility is amazing. I don't see how to get around that, and for all the issues listed, I don't see a reason to throw the baby out with the bathwater / not really sure what the alternative is supposed to be. As for privacy, if we weren't doing things in a browser as much and you had to install an app... would OSes be a better host / not have all these issues?
- timw4mail 7y ago
  I don't understand why there's so much avoidance of server-side rendering.
  - deleted 7y ago
    [deleted]
  - duxup 7y ago
    Personally I'm really interested in it but honestly I've only started to dip my toes in it, and I don't think that really fixes most of the issues in the article. Granted the article is sort of a goulash of not incorrectly but not entirely connected ideas. Like a lot of JavaScript criticisms you couldn't possibly address them all, maybe that means something ;)
    - pdimitar 7y ago
      What would you like to see being solved by server-side rendering? Genuinely curious.
  - Turing_Machine 7y ago
    Because client-side rendering is free (at least to the site), while server-side rendering costs actual money. That matters a lot when you start running things at scale.
quickthrower2 7y ago
As for the webrtc IP adress - check your one out here: http://net.ipcalf.com/ http://net.ipcalf.com/ This works on one computer for me, and get obfuscated on another (on a different network). Interesting!
AzzieElbab 7y ago
They should have given Brandon Eich a couple more weeks...
mwcampbell 7y ago
Chrome OS is hardly a failure as the author claims. I have a non-techie friend who uses it, and I hear that it is popular in schools.
headcanon 7y ago
The issue with many of these major problems are (especially regarding 3rd party scripts): 1) They are easy to add 2) Economic incentives are not aligned with technical rigor and security. 3) No matter how much we write and post on this forum, we're shouting into a void composed of the 80% of developers who do not care, and the 100% of people who pay them who do not care. Why should they care about the occasional user getting compromised by russian hackers? "Not my problem" attitude won't get fixed by social enforcement. 4) Progressive web apps + modern stack need an expert hand, and are not straightforward to set up in most cases. Much more difficult at any rate than setting up a quick react app. Next.js and others do well at making this less difficult, but see #3. Everywhere I've worked that just shipped a "static" SPA, doing so did not materially affect the business over shipping progressive functionality. Embracing "rigor" was seen by a waste of time to anyone who had a hand in task scheduling, and why should they care? No PM or startup CEO is going to care a whit about anything this article talks about, unless it happens to be central to their business.
recursive 7y ago
As someone who has spent a significant amount of time with both QBasic and javascript, the comparison between the two languages is off the mark. QBasic has no built-in array sort. QBasic has no function references, and by extension no anonymous functions. QBasic has no objects. It does have structs, of a kind, but they're much more limited, and don't have prototypes or participate in inheritance.
axguscbklp 7y ago
>JavaScript frameworks such as React and Angular have transformed the web, bringing us fully-fledged client side applications with functionality that could only be imagined just a decade ago. It's not like one couldn't create a fully-fledged client side application before Angular and React.
draw_down 7y ago
I get a thrill from seeing people write stuff like "JavaScript is a toy programming language". It's just amazing, what kind of twat still honestly believes this? Somehow people all over the world are building apps with it, and there are more of them doing it than whatever this person considers to be not a toy, but I suppose those are just minor details.
_bxg1 7y ago
> Gmail used to be fast, and now it's slow and bloated. On my fiber connection, it takes nearly two seconds to render anything beyond a loading animation (generally a bad sign) and several more seconds to fully stream in content for various sections of the page. Why so slow? A quick trip to the Network tab in the browser console reveals that more than 4.6 megabytes of JavaScript are needed just for the list of emails to first render. After that point, 8 more megabytes of JavaScript stream in and various elements on the page render asynchronously. All this while, a further 3.5 megabytes of XHR data are transferred across more than 60 separate API calls. What this reads as, to me, is "Gmail, a highly-stateful tool, is downloaded locally and then it requests a large portion of the user's inbox and other data for usage." I highly doubt the JavaScript is re-downloaded every time the author visits Gmail. If it is, something has gone wrong. I don't think the initial load time is a good metric of performance for a true web app; on subsequent visits that 12.6MB should be loaded directly from disk, just like the binary of an installed native program. Also, JSON is leaner than HTML, so the only reason that "3.5 megabytes of XHR data" would be larger than what was already being downloaded before is if Gmail is loading data more eagerly (loading the first several hundred entire messages of your inbox, for example, instead of just the subject lines of the first 50). This eager loading would presumably be done to make subsequent actions faster, and while we can debate the decision that was made in this particular case about exactly how eager to be, that isn't exactly an endemic issue like the author makes it out to be.
- cousin_it 7y ago
  > I highly doubt the JavaScript is re-downloaded every time the author visits Gmail. If it is, something has gone wrong. I don't think the initial load time is a good metric of performance for a true web app; on subsequent visits that 12.6MB should be loaded directly from disk, just like the binary of an installed native program. I don't know about Gmail, but this argument misses something important. A web app with several megs of JS is most likely being developed and pushed to production on a schedule (daily, or weekly, or something). So you're probably re-downloading the whole thing every few days. > Also, JSON is leaner than HTML Mmmaybe. With gzip, the difference isn't that large. And since not all developers are perfectly careful, the initial JSON will often contain stuff that isn't necessary for the initial UI state, so server side rendered HTML will often be leaner and faster.
Turing_Machine 7y ago
I've never been impressed by the argument that JavaScript is somehow less secure than native apps (which are still mostly written in C, and which have full access to the hardware by default). The mere fact that JavaScript doesn't have unchecked array bounds eliminates about 70% of the really serious security hacks of the last 30 years.
- jakelazaroff 7y ago
  On the other hand, JavaScript is executed automatically; your native app needs to be downloaded and run manually.
  - Turing_Machine 7y ago
    A fair point, but we both know there's no shortage of people who will click on a link to an executable and then blindly run it, especially if it purports to be from "Microsoft Technical Support" or "Amazon Security" or some such.
  - hombre_fatal 7y ago
    But you have a lot of control over the web browser. You can run zero Javascript. You can write extensions. You can easily see network traffic and conditionally block it. You can block Google Analytics. With native apps, you have very little control. You basically either run it or you don't. You can't just pick the parts you want to run. And you need to use a mitm proxy just to see what it's doing. The OS gives you no power here unlike the browser. A native app can send a request to Google Analytics on every keystroke and it's nontrivial to find that out compared to opening a browser's network tab. Native apps have some advantages like performance, but they are no free lunch, especially when it comes to privacy.
jtdev 7y ago
Love this quote: "Imagine an operating system where all software development must be done in QBasic; it's an operating system that downloads, installs and executes any program the moment it is encountered, without your permission, and it leaks information about your activities to anyone who wants to spy on you. No it's not Windows 10; you've basically imagined a modern web browser."
cutler 7y ago
Doesn't web assembly solve this problem? The author doesn't even mention it.
- henriquez 7y ago
  Solves the issue of JavaScript being a toy language but not the issue of treating the browser as an OS and forcing the user to execute unknown app code in order to use the web.
okareaman 7y ago
Excellent article, but I think it misses the point that most people are aware that they are getting free sites and tools like gmail, reddit, twitter, facebook for the price of being tracked an advertised to. What's the alternative? Paying for everything? Just install an ad blocker, turn off JavaScript or if you are really paranoid, pick one of the many linux distributions to load up into VirtualBox and browse the web that way, changing your distro daily. Use various VPN services on top of it. Use Tor. Most people don't care enough to do anything like this.
- notechback 7y ago
  I doubt that most people understand that using Gmail (or similar) means their emails are analysed, much less that they are tracked across the web and that such info is assembled by hundreds of companies and sold and resold many times. Most people in San Francisco might understand it. Do most people in Chennai, Nairobi, Rio or even in Smalltown, USA understand that?
  - okareaman 7y ago
    I think you underestimate people
    - Shared404 7y ago
      As much as I would like to think that, I have to disagree. I've spoken to many somewhat technically savvy people who when informed $product sells your information, are shocked.

Thanks for posting, I’m interested in reading it. However, I’m reading the article on my iPhone and the scrolling hijack is really annoying. It scrolls less well than native scrolling and is jerky and makes it difficult to read. Why do people do this with their blogs?

henriquez 7y ago
Author here - there's no scrolling hijack on my pages. I also dislike this sort of thing. Which iOS are you using?
- wincy 7y ago
  iOS 12.4. When I scroll up or down normally the intensity of the flick causes it to scroll faster or slower. It feels like there’s a “hard stop” on the page, the scrolling stops sooner. Scrolling slowly seems to be off by a pixel or something, almost like a judder. I didn’t see the same issue on Chrome on my Mac.
  - adrianhel 7y ago
    Scrolling on iOS browsers is an utter pain due to rubber band scrolling. It can be solved with -webkit-overflow-scrolling and hard work.
- wincy 7y ago
  I know Firefox for iOS uses WebKit so not sure how useful the information is, but the same “issue” is present there. The scrolling is just different.
- robocat 7y ago
  I think that is sometimes caused by using an onscroll event without the {passive: true} option set. Even better, remove all onscroll events (including from libraries or adverts you may use).
- jmull 7y ago
  I’m not the previous poster and I’m not sure if this is the same, but on iOS Safari there is something odd about the page scroll. Normally on iOS, when you scroll a page, the title/address bar shrinks. You can tap it and it expands, and tap it again and it scrolls you back to the top of the page. None of that happens on your page. I don’t really notice that the scrolling itself is off, but I’m probably not that sensitive to that kind of thing. This is latest iPhone OS and iPad OS, 13.4.
buffin 7y ago
I didn't notice anything fishy with the scrolling. Using the latest firefox on MacOS.

guessmyname 7y ago

I had the opportunity to work in the analytics team at MindGeek a couple of years ago. My team would spend days researching about all these seemingly useless features in modern web browsers to find new and better ways to track users across all our websites. I still remember when the HTML Canvas Element [1] was introduced by Apple almost two decades ago, many of these adult websites managed to increase the accuracy of their corresponding device fingerprint algorithms [2] by leveraging the power of the new APIs. In fact, one of the reasons why Fabian Thylmann tried to acquire XVideos back in 2012 [3] was because their analytics team had engineered new ways to track users using WebGL [4] which was still quite new. I don’t know if device tracking is still relevant for their revenue model, but I am sure they still have the code running in most —if not all— their websites for one reason or another. [1] https://en.wikipedia.org/wiki/Canvas_fingerprinting https://en.wikipedia.org/wiki/Canvas_fingerprinting [2] https://en.wikipedia.org/wiki/Device_fingerprint https://en.wikipedia.org/wiki/Device_fingerprint [3] https://en.wikipedia.org/wiki/XVideos#History https://en.wikipedia.org/wiki/XVideos#History [4] https://en.wikipedia.org/wiki/WebGL https://en.wikipedia.org/wiki/WebGL

chrischen 7y ago

For the section about how javascript can only be added onto (such as with typescript), I disagree. Now that we have compilers and transpilers like Babel and Typescript, it means we can effectively code how we want (even with different languages like reasonml, ocaml, purescript, or ESNext), and in theory browser venders can simply make a new target language or version of JS that these compilers can target.

timw4mail 7y ago
I've always found this to be a strange argument. You have that layer of indirection from the transpiler (which may mean very difficult integrations with JS tools), and it isn't always trivial to interact with actual Javascript.
- WorldMaker 7y ago
  Even C is a layer of indirection that doesn't always reflect the output machine code (much less the assembly language somewhere between). Most of programming language decision making is choosing the stack of "indirections" you feel most comfortable with. Most of programming tool design is helping you navigate those indirections, and the techniques are generally the same in most cases. C you have symbol files and tools that can read them such as debuggers. JS you have sourcemaps and tools that can read them such as debuggers and browser consoles. The tools aren't always perfect, but they get better all the time. It's also a spectrum of choice for which stack you feel comfortable with. Babel and Typescript do increasingly less transpilation with major browser releases. In many cases Typescript today really is just JS with Types. Certainly options like ReasonML and Purescript exist on the opposite end of the spectrum, very little resemble JS, do a lot of more work in transpilation (and do sometimes make JS interop intentionally hard by treating it as an FFI or equivalent boundary). The added "indirection" has trade-offs in productivity, developer "comfort", project aesthetics and synergies.
- chrischen 7y ago
  If anything there are better JS tooling around writing your code with ESNext or Typescript than just plain javascript.

elldoubleyew 7y ago

Genuine question as a rookie developer: I write a lot of internal tools for my company used in manufacturing/fulfillment. We generally deploy these as fleets of Raspberry Pis. The front ends for these systems are generally pretty simple, they just walk an operator through what they should be scanning, and for hardware interaction I use a small node server. I serve a React App to these stations (from an internal server) to render this UI. What (modern) alternatives are there for this that do not use web technologies? I've recently grown an affinity for ruby and attempted to rewrite my frontend in Shoes, but the barebones documentation and lack of SO answers made that a huge pain in the ass, not to mention the added steps in deployment of updates. Going any other route just seems like so much more work for no true benefit.

orthecreedence 7y ago
Honestly, if what you're doing works, go for it. Using javascript/html as an internal tool for UI building seems like a fairly decent use-case. You could write your UI in some sort of native toolkit like QT/Gtk/etc but then you're pumping dev cycles into making something that already exists and works fine...for what? If everyone who uses your UIs already has a browser, then you've hit a sweet spot: your client software is already pre-installed on all the machines you need it to be, and the rest is serving HTML/javascript. The alternatives for you are probably pretty time-intensive for you and probably annoying for your users ("hey, install this program/app/etc"). I'd say if you want to rely less on JS and use more server-generated HTML, PHP might be the simplest option for you. People around here shit on PHP, but PHP was "serverless" before it was cool and has a lot of tools to do exactly what you're doing. But again, ask yourself what you gain by switching to another technology.
- pdimitar 7y ago
  PHP is definitely an awful recommendation for a RPi 4 though. There are lighter weighted options that optimise for minimum latency and minimum CPU overhead.
  - orthecreedence 7y ago

tiborsaas 7y ago

Stopped reading it at "JavaScript is a toy programming language." While the author is not alone with this view, it's shared by many of my backend colleges. With such a condescending view I will hardly gain any insight I'm afraid.

Torwald 7y ago
JavaScript is a Scheme with a 90ies pop-art name. It runs on the server it runs in the browser. The curly brackets. What's not to love?
- Spivak 7y ago
  JavaScript isn't Scheme: https://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/ https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
axguscbklp 7y ago
Yeah, JavaScript has problems but come on, just the fact that it has closures and first-class functions (and did a lot to popularize both, for that matter) makes it pretty cool in my book. It's a fun and powerful language. The author also trots out the standard go-to argument of JavaScript haters. He writes that JavaScript "has deeply ingrained quirks and bugs which can never be fixed without breaking the millions of scripts that have made peace with the existence of those bugs and depend upon the well-known workaround" and he links to https://github.com/denysdovhan/wtfjs https://github.com/denysdovhan/wtfjs, a typical list of JavaScript's well-known type-casting quirks, etc. Pretty much all languages have little quirks. Actual JavaScript programmers usually learn how to avoid JavaScript's quirks pretty quickly and easily. In my experience, people who fixate on JavaScript's quirks generally do not understand the language very well. If they did, they could criticize more substantial things about JavaScript than just things like "[] == ![]; // -> true".

hn_throwaway_99 7y ago

> JavaScript is a toy programming language. Bullshit. Yes, javascript has evolved a ton over the decades, and it has a lot of cruft that it pulls with it. So what? So does virtually every other successful language. I was a Java developer for over 15 years before I switched to mainly developing in Node/Typescript, and I feel I am much more productive in this ecosystem than I was in Java.

The_Colonel 7y ago
I'm kind of similar although I stll work on Java/Kotlin enterprise apps professionally and do JavaScript for hobby projects. And I must actually say that it's a joy to work in modern JavaScript. It has some very nice features (async/await, destructuring, null coalescing, functional features) which make it expressive and succint. It has decent performance as well, nice (lack of) tooling (no need to compile anything!) I probably would not do a huge project with it though (TS would be better fit there).
rhinoceraptor 7y ago
And even if it is a toy language, it doesn't matter. If you're a web developer, you need to know Javascript.
- pdimitar 7y ago
  But if you can afford it -- and many projects actually can -- you can work on top of it through TypeScript or Elm, and the experience is much better.
bsmith0 7y ago
Agreed, this type of article is such a circlejerk. People love to hate JS.
Spivak 7y ago
I think the problem is ultimately a combination of popularity and forced-usage that creates opinions like these. JS has remarkably less weirdness and cruft than other ubiquitous languages like Bash and Python because of how quickly browser vendors are able to iterate on it. Every little piece of the language has millions of eyeballs on it.

duxup 7y ago

This reads like sort of a grand collection of mostly legitimate individual technical complaints about a lot of things JavaScript / Browser. But I still can't get past the fact that when I work for a company that wants to write a web app it is just like magic that it works across all these operating systems, phones, and etc provided they have a capable browser. To me that utility is amazing. I don't see how to get around that, and for all the issues listed, I don't see a reason to throw the baby out with the bathwater / not really sure what the alternative is supposed to be. As for privacy, if we weren't doing things in a browser as much and you had to install an app... would OSes be a better host / not have all these issues?

timw4mail 7y ago
I don't understand why there's so much avoidance of server-side rendering.
- deleted 7y ago
  [deleted]
- duxup 7y ago
  Personally I'm really interested in it but honestly I've only started to dip my toes in it, and I don't think that really fixes most of the issues in the article. Granted the article is sort of a goulash of not incorrectly but not entirely connected ideas. Like a lot of JavaScript criticisms you couldn't possibly address them all, maybe that means something ;)
  - pdimitar 7y ago
    What would you like to see being solved by server-side rendering? Genuinely curious.
- Turing_Machine 7y ago
  Because client-side rendering is free (at least to the site), while server-side rendering costs actual money. That matters a lot when you start running things at scale.

quickthrower2 7y ago

As for the webrtc IP adress - check your one out here: http://net.ipcalf.com/ http://net.ipcalf.com/ This works on one computer for me, and get obfuscated on another (on a different network). Interesting!

AzzieElbab 7y ago

They should have given Brandon Eich a couple more weeks...

mwcampbell 7y ago

Chrome OS is hardly a failure as the author claims. I have a non-techie friend who uses it, and I hear that it is popular in schools.

headcanon 7y ago

The issue with many of these major problems are (especially regarding 3rd party scripts): 1) They are easy to add 2) Economic incentives are not aligned with technical rigor and security. 3) No matter how much we write and post on this forum, we're shouting into a void composed of the 80% of developers who do not care, and the 100% of people who pay them who do not care. Why should they care about the occasional user getting compromised by russian hackers? "Not my problem" attitude won't get fixed by social enforcement. 4) Progressive web apps + modern stack need an expert hand, and are not straightforward to set up in most cases. Much more difficult at any rate than setting up a quick react app. Next.js and others do well at making this less difficult, but see #3. Everywhere I've worked that just shipped a "static" SPA, doing so did not materially affect the business over shipping progressive functionality. Embracing "rigor" was seen by a waste of time to anyone who had a hand in task scheduling, and why should they care? No PM or startup CEO is going to care a whit about anything this article talks about, unless it happens to be central to their business.

recursive 7y ago

As someone who has spent a significant amount of time with both QBasic and javascript, the comparison between the two languages is off the mark. QBasic has no built-in array sort. QBasic has no function references, and by extension no anonymous functions. QBasic has no objects. It does have structs, of a kind, but they're much more limited, and don't have prototypes or participate in inheritance.

axguscbklp 7y ago

>JavaScript frameworks such as React and Angular have transformed the web, bringing us fully-fledged client side applications with functionality that could only be imagined just a decade ago. It's not like one couldn't create a fully-fledged client side application before Angular and React.

draw_down 7y ago

I get a thrill from seeing people write stuff like "JavaScript is a toy programming language". It's just amazing, what kind of twat still honestly believes this? Somehow people all over the world are building apps with it, and there are more of them doing it than whatever this person considers to be not a toy, but I suppose those are just minor details.

_bxg1 7y ago

> Gmail used to be fast, and now it's slow and bloated. On my fiber connection, it takes nearly two seconds to render anything beyond a loading animation (generally a bad sign) and several more seconds to fully stream in content for various sections of the page. Why so slow? A quick trip to the Network tab in the browser console reveals that more than 4.6 megabytes of JavaScript are needed just for the list of emails to first render. After that point, 8 more megabytes of JavaScript stream in and various elements on the page render asynchronously. All this while, a further 3.5 megabytes of XHR data are transferred across more than 60 separate API calls. What this reads as, to me, is "Gmail, a highly-stateful tool, is downloaded locally and then it requests a large portion of the user's inbox and other data for usage." I highly doubt the JavaScript is re-downloaded every time the author visits Gmail. If it is, something has gone wrong. I don't think the initial load time is a good metric of performance for a true web app; on subsequent visits that 12.6MB should be loaded directly from disk, just like the binary of an installed native program. Also, JSON is leaner than HTML, so the only reason that "3.5 megabytes of XHR data" would be larger than what was already being downloaded before is if Gmail is loading data more eagerly (loading the first several hundred entire messages of your inbox, for example, instead of just the subject lines of the first 50). This eager loading would presumably be done to make subsequent actions faster, and while we can debate the decision that was made in this particular case about exactly how eager to be, that isn't exactly an endemic issue like the author makes it out to be.

cousin_it 7y ago
> I highly doubt the JavaScript is re-downloaded every time the author visits Gmail. If it is, something has gone wrong. I don't think the initial load time is a good metric of performance for a true web app; on subsequent visits that 12.6MB should be loaded directly from disk, just like the binary of an installed native program. I don't know about Gmail, but this argument misses something important. A web app with several megs of JS is most likely being developed and pushed to production on a schedule (daily, or weekly, or something). So you're probably re-downloading the whole thing every few days. > Also, JSON is leaner than HTML Mmmaybe. With gzip, the difference isn't that large. And since not all developers are perfectly careful, the initial JSON will often contain stuff that isn't necessary for the initial UI state, so server side rendered HTML will often be leaner and faster.

Turing_Machine 7y ago

I've never been impressed by the argument that JavaScript is somehow less secure than native apps (which are still mostly written in C, and which have full access to the hardware by default). The mere fact that JavaScript doesn't have unchecked array bounds eliminates about 70% of the really serious security hacks of the last 30 years.

jakelazaroff 7y ago
On the other hand, JavaScript is executed automatically; your native app needs to be downloaded and run manually.
- Turing_Machine 7y ago
  A fair point, but we both know there's no shortage of people who will click on a link to an executable and then blindly run it, especially if it purports to be from "Microsoft Technical Support" or "Amazon Security" or some such.
- hombre_fatal 7y ago
  But you have a lot of control over the web browser. You can run zero Javascript. You can write extensions. You can easily see network traffic and conditionally block it. You can block Google Analytics. With native apps, you have very little control. You basically either run it or you don't. You can't just pick the parts you want to run. And you need to use a mitm proxy just to see what it's doing. The OS gives you no power here unlike the browser. A native app can send a request to Google Analytics on every keystroke and it's nontrivial to find that out compared to opening a browser's network tab. Native apps have some advantages like performance, but they are no free lunch, especially when it comes to privacy.

jtdev 7y ago

Love this quote: "Imagine an operating system where all software development must be done in QBasic; it's an operating system that downloads, installs and executes any program the moment it is encountered, without your permission, and it leaks information about your activities to anyone who wants to spy on you. No it's not Windows 10; you've basically imagined a modern web browser."

cutler 7y ago

Doesn't web assembly solve this problem? The author doesn't even mention it.

henriquez 7y ago
Solves the issue of JavaScript being a toy language but not the issue of treating the browser as an OS and forcing the user to execute unknown app code in order to use the web.

okareaman 7y ago

Excellent article, but I think it misses the point that most people are aware that they are getting free sites and tools like gmail, reddit, twitter, facebook for the price of being tracked an advertised to. What's the alternative? Paying for everything? Just install an ad blocker, turn off JavaScript or if you are really paranoid, pick one of the many linux distributions to load up into VirtualBox and browse the web that way, changing your distro daily. Use various VPN services on top of it. Use Tor. Most people don't care enough to do anything like this.

notechback 7y ago
I doubt that most people understand that using Gmail (or similar) means their emails are analysed, much less that they are tracked across the web and that such info is assembled by hundreds of companies and sold and resold many times. Most people in San Francisco might understand it. Do most people in Chennai, Nairobi, Rio or even in Smalltown, USA understand that?
- okareaman 7y ago
  I think you underestimate people
  - Shared404 7y ago
    As much as I would like to think that, I have to disagree. I've spoken to many somewhat technically savvy people who when informed $product sells your information, are shocked.