6 ms·

> There is a reason why JS was invented. I disagree. As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script

> There is a reason why JS was invented. I disagree. As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script languages such as BASH, for doing small amounts of interactive stuff. What JS has morphed into is a Jeckyll & Hyde monstrosity. Frontend devs now routinely dump 200kb+ of junk down the pipe at people's browsers because its somehow "better" to dump the processing/rendering on the user's desktop instead of server side. And then there's the monstrosity of server-side JS. I think few people can argue that JS was ever supposed to be server-side. Things like Node are basically square-pegging JS into that round hole.

EamonnMR 4y ago
Of course it's better to do processing client side. You pay for server side compute, you don't pay for client side compute.
horsawlarway 4y ago
I think you're failing to address the elephant in the room: The browser is simply the single best application distribution method humanity has ever created. Full stop. There are literally no other tools that give anywhere close to the same benefits. So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of applications 200kb is ridiculously small. When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB? Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care. Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds. Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience. That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. Music player? It's a website now. JS. See my point? So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.
- masklinn 4y ago
  > So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing. That web application delivery is "fucking amazing" doesn't mean javascript is. Javascript very much is not. What javascript is, is the only complete option until wasm is way more fleshed out than it currently is. > Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb With an entire browser and server farm to do that. > and load in less than a few seconds. Instead of instantaneously. > That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. 10% the functionality, 20% the performance, at twice the heft. Amazing. > Music player? It's a website now. JS. Your music library? Doesn't exist now.
- traceroute66 4y ago
  > See my point? No. Because your point only works if you make (at least) two prior assumptions which are not always true. Number one you assume everyone has high-speed broadband and "unlimited" 5G on mobile. This might well be the case in many parts of the Western world. But I can point you to a number of rural areas in the Western world and beyond that, in Africa and Asia where this assumption falls flat. Number two, given most developers use JS to outsource the processing duties, you assume everyone has a half-decent computer. Many people use cheap laptops with lousy Celeron processors and a minuscule amount of RAM, likely also with an ancient browser that has not been updated for ages. Their experience of a browser-app will likely be very different to the cool-kid developer sitting on his bean-bag in a fancy office coding on a spec'd out beast of a machine.
  - lnenad 4y ago
    What is your counter point with these statements? That having everything in canvas negates these potential issues? That having a native application negates them? In an ideal scenario of application design, these two assumptions apply as well. So I don't think there is any merit in mentioning them as they're not counter points in any way.
- devmor 4y ago
  Your point and explanation are completely disjointed from eachother. Javascript is not the sole domain of small executables, its not even its primary feature - hell, one of your own examples isn't even very good. Outlook loads nearly 30MB of javascript immediately when you load your inbox, and they update it nearly every other day so you end up downloading hundreds of megabytes just to read your email every single week instead of just once.

EamonnMR 4y ago

Of course it's better to do processing client side. You pay for server side compute, you don't pay for client side compute.

horsawlarway 4y ago

I think you're failing to address the elephant in the room: The browser is simply the single best application distribution method humanity has ever created. Full stop. There are literally no other tools that give anywhere close to the same benefits. So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of applications 200kb is ridiculously small. When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB? Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care. Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds. Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience. That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. Music player? It's a website now. JS. See my point? So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.

masklinn 4y ago
> So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing. That web application delivery is "fucking amazing" doesn't mean javascript is. Javascript very much is not. What javascript is, is the only complete option until wasm is way more fleshed out than it currently is. > Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb With an entire browser and server farm to do that. > and load in less than a few seconds. Instead of instantaneously. > That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. 10% the functionality, 20% the performance, at twice the heft. Amazing. > Music player? It's a website now. JS. Your music library? Doesn't exist now.
traceroute66 4y ago
> See my point? No. Because your point only works if you make (at least) two prior assumptions which are not always true. Number one you assume everyone has high-speed broadband and "unlimited" 5G on mobile. This might well be the case in many parts of the Western world. But I can point you to a number of rural areas in the Western world and beyond that, in Africa and Asia where this assumption falls flat. Number two, given most developers use JS to outsource the processing duties, you assume everyone has a half-decent computer. Many people use cheap laptops with lousy Celeron processors and a minuscule amount of RAM, likely also with an ancient browser that has not been updated for ages. Their experience of a browser-app will likely be very different to the cool-kid developer sitting on his bean-bag in a fancy office coding on a spec'd out beast of a machine.
- lnenad 4y ago
  What is your counter point with these statements? That having everything in canvas negates these potential issues? That having a native application negates them? In an ideal scenario of application design, these two assumptions apply as well. So I don't think there is any merit in mentioning them as they're not counter points in any way.
devmor 4y ago
Your point and explanation are completely disjointed from eachother. Javascript is not the sole domain of small executables, its not even its primary feature - hell, one of your own examples isn't even very good. Outlook loads nearly 30MB of javascript immediately when you load your inbox, and they update it nearly every other day so you end up downloading hundreds of megabytes just to read your email every single week instead of just once.