4 ms·

The argument of "JavaScript is bad" or even "JavaScript is necessary but only in small amounts" is getting pretty tired. I don't think anybody could possibly h

The argument of "JavaScript is bad" or even "JavaScript is necessary but only in small amounts" is getting pretty tired. I don't think anybody could possibly hope to argue that all client-side code is bad, but that's all web+JavaScript is: an easy deployment platform, for both content creator and consumer, for client-side code. Where else could you deploy and within seconds your customers have your new code? If you're worried about how easy it's becoming to track people in the browser, or to track people in the Internet ecosystem in general, that's an entirely different conversation. JavaScript has absolutely nothing to do with the security and privacy status of the web aside from what it is allowed to do per web standards. Stop blaming a language or the ability to write anything Turing complete when, clearly, it's just a tool and the same problems exist in every single code distribution arena.

deleted 8y ago
[deleted]
ricardobeat 8y ago
Sorry, the point of the article went way past your head. This is not about javascript or the qualities of the platform. The word 'tracking' is nowhere to be found in the text. There is just an insane amount of tolerance for what's acceptable performance today, and a huge disconnect with the reality of the average user. Here we are with supercomputers all around, and the web is slow. Slower than it was ten years ago. This has nothing to do with javascript as a language.
- andrewstuart2 8y ago
  > Sorry, the point of the article went way past your head. This is not useful or helpful tone and really does not belong on HN [1]. My comments addressing security and privacy were in response to the current top comment [2]. I fully realize that performance is the goal of the article. What I strongly disagree with is the article's projected viewpoint of the universality of JS being slower. > despite the best effort of (...) tools that send less JS be default > Video of a single slow-loading page lands in a visceral way; abstract graphs don’t. Saying JavaScript is universally slower is as true as saying client side code is always slower. This is obviously not the case. Just imagine if the next CounterStrike game tried to do everything with server side rendering rather than transferring 5GB of game code one time and tiny fractions of that from then on. Obviously the argument is not universal. Costs can be amortized. Code can be cached and intelligently replaced. There are entire industries where nobody would even think to debate that a lot of client side code is the only way to achieve their goals. I'm not saying everybody does this well, but I'm confident saying that the answer is not going to be universally less JavaScript. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html [2] https://news.ycombinator.com/item?id=17963207 https://news.ycombinator.com/item?id=17963207
  - Izkata 8y ago
    > Just imagine if the next CounterStrike game tried to do everything with server side rendering Okay: https://parsecgaming.com/ https://parsecgaming.com/
    - andrewstuart2 8y ago
      :-D https://news.ycombinator.com/item?id=17963838 https://news.ycombinator.com/item?id=17963838 Edited because I had the wrong link. I had posted that exact service earlier as an example of things being feasible but not best for latency, which is a very real component of user-perceived speed.
jondubois 8y ago
Agreed, it's a poor argument. I once worked for a hardware company which manufactured Set Top Boxes (like TiVO). They could have developed the UI engine in any language, but they chose JavaScript (running on their own custom JS engine). It's surprising how many companies use JavaScript to implement the UI for their hardware devices; to infer that developers only use JS because they don't have a choice is inaccurate. JavaScript has become a great language. I've programmed in pretty much everything else so I think I'm qualified to say this. In my opinion, if a developer needs to know just two languages today, it's JavaScript and C/C++. With knowledge of JavaScript and C/C++, you can do anything on any device. A developer who knows JavaScript and C/C++ is usually a pragmatic developer; a good developer.
- scarface74 8y ago
  I once worked for a hardware company which manufactured Set Top Boxes (like TiVO). They could have developed the UI engine in any language, but they chose JavaScript (running on their own custom JS engine). It's surprising how many companies use JavaScript to implement the UI for their hardware devices; to infer that developers only use JS because they don't have a choice is inaccurate. This is true. Another example is the 2nd and 3rd gen AppleTVs. They were based on iOS but the “apps” for it were all hosted on top of WebKit using Apple’s own markup language - TVML. While I’m definitely not a fan of the movement toward JS everywhere, I have to admit that of you want to tie your horse to one language, JS is the way to go.
  - jondubois 8y ago
    I remember at the company I worked for, we used AppleTV as inspiration for our own UI so it makes sense why we would use similar tech.
- pjmlp 8y ago
  You named three languages.
  - jondubois 8y ago
    C and C++ are not separate languages, one is a subset of the other. I just mentioned C explicitly because some hardware devices don't have a C++ compiler.
ken 8y ago
> Where else could you deploy and within seconds your customers have your new code? Applets, Flash, JNLP, 0install, ClickOnce? JS is the most popular but it isn't unique.
paulie_a 8y ago
"easy deployment platform" It's a fucking nightmare.
- FridgeSeal 8y ago
  "Write your code here, here and here, sacrifice 4 goats under a full moon, run your through 3 (no more, no less) seperate tools (each with their own config files), send that to an intermediate compiler to generate a dozen more files, don robes and perform ceremony to Elder God(s) of your choice, to send to another sort-of-compiler, sacrifice your intern for good measure, run everything through a packaging tool (chosen using a carnival spin wheel, different for each run). Discover your code has errors that get silently ignored, repeat the whole again, any remaining errors are clearly blessed by said Elder Gods, deploy it, ignore warnings and go onto the next project. :P
iamaelephant 8y ago
Can you quote the part of the article that blames the language? I read the article but I must have missed that part. Thanks.

deleted 8y ago

[deleted]

ricardobeat 8y ago

Sorry, the point of the article went way past your head. This is not about javascript or the qualities of the platform. The word 'tracking' is nowhere to be found in the text. There is just an insane amount of tolerance for what's acceptable performance today, and a huge disconnect with the reality of the average user. Here we are with supercomputers all around, and the web is slow. Slower than it was ten years ago. This has nothing to do with javascript as a language.

andrewstuart2 8y ago
> Sorry, the point of the article went way past your head. This is not useful or helpful tone and really does not belong on HN [1]. My comments addressing security and privacy were in response to the current top comment [2]. I fully realize that performance is the goal of the article. What I strongly disagree with is the article's projected viewpoint of the universality of JS being slower. > despite the best effort of (...) tools that send less JS be default > Video of a single slow-loading page lands in a visceral way; abstract graphs don’t. Saying JavaScript is universally slower is as true as saying client side code is always slower. This is obviously not the case. Just imagine if the next CounterStrike game tried to do everything with server side rendering rather than transferring 5GB of game code one time and tiny fractions of that from then on. Obviously the argument is not universal. Costs can be amortized. Code can be cached and intelligently replaced. There are entire industries where nobody would even think to debate that a lot of client side code is the only way to achieve their goals. I'm not saying everybody does this well, but I'm confident saying that the answer is not going to be universally less JavaScript. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html [2] https://news.ycombinator.com/item?id=17963207 https://news.ycombinator.com/item?id=17963207
- Izkata 8y ago
  > Just imagine if the next CounterStrike game tried to do everything with server side rendering Okay: https://parsecgaming.com/ https://parsecgaming.com/
  - andrewstuart2 8y ago
    :-D https://news.ycombinator.com/item?id=17963838 https://news.ycombinator.com/item?id=17963838 Edited because I had the wrong link. I had posted that exact service earlier as an example of things being feasible but not best for latency, which is a very real component of user-perceived speed.

jondubois 8y ago

Agreed, it's a poor argument. I once worked for a hardware company which manufactured Set Top Boxes (like TiVO). They could have developed the UI engine in any language, but they chose JavaScript (running on their own custom JS engine). It's surprising how many companies use JavaScript to implement the UI for their hardware devices; to infer that developers only use JS because they don't have a choice is inaccurate. JavaScript has become a great language. I've programmed in pretty much everything else so I think I'm qualified to say this. In my opinion, if a developer needs to know just two languages today, it's JavaScript and C/C++. With knowledge of JavaScript and C/C++, you can do anything on any device. A developer who knows JavaScript and C/C++ is usually a pragmatic developer; a good developer.

scarface74 8y ago
I once worked for a hardware company which manufactured Set Top Boxes (like TiVO). They could have developed the UI engine in any language, but they chose JavaScript (running on their own custom JS engine). It's surprising how many companies use JavaScript to implement the UI for their hardware devices; to infer that developers only use JS because they don't have a choice is inaccurate. This is true. Another example is the 2nd and 3rd gen AppleTVs. They were based on iOS but the “apps” for it were all hosted on top of WebKit using Apple’s own markup language - TVML. While I’m definitely not a fan of the movement toward JS everywhere, I have to admit that of you want to tie your horse to one language, JS is the way to go.
- jondubois 8y ago
  I remember at the company I worked for, we used AppleTV as inspiration for our own UI so it makes sense why we would use similar tech.
pjmlp 8y ago
You named three languages.
- jondubois 8y ago
  C and C++ are not separate languages, one is a subset of the other. I just mentioned C explicitly because some hardware devices don't have a C++ compiler.

ken 8y ago

> Where else could you deploy and within seconds your customers have your new code? Applets, Flash, JNLP, 0install, ClickOnce? JS is the most popular but it isn't unique.

paulie_a 8y ago

"easy deployment platform" It's a fucking nightmare.

FridgeSeal 8y ago
"Write your code here, here and here, sacrifice 4 goats under a full moon, run your through 3 (no more, no less) seperate tools (each with their own config files), send that to an intermediate compiler to generate a dozen more files, don robes and perform ceremony to Elder God(s) of your choice, to send to another sort-of-compiler, sacrifice your intern for good measure, run everything through a packaging tool (chosen using a carnival spin wheel, different for each run). Discover your code has errors that get silently ignored, repeat the whole again, any remaining errors are clearly blessed by said Elder Gods, deploy it, ignore warnings and go onto the next project. :P

iamaelephant 8y ago

Can you quote the part of the article that blames the language? I read the article but I must have missed that part. Thanks.