8 ms·

It's in the domain name: catchjs. The reason that the web is slow now is javascript. That is, treating a webpage like an application instead of a document. This

It's in the domain name: catchjs. The reason that the web is slow now is javascript. That is, treating a webpage like an application instead of a document. This analysis just assumes all websites are JS-application monsters and only differentiates between them. It misses the point. What makes it even slower is the practice of serially chain loading JS from multiple domains. Once you're 3 deep in that it doesn't matter how 'fast' your webserver is or how fast and clean your JS code is, the serial loading will slow things to a crawl.

k__ 6y ago
I don't know what kind of web you are using. But The sites I'm visiting on a daily basis are, in fact, applications and not documents. Slack, Asana, GitHub, Gravit Designer, Google Docs/Sheets/Mail...
- phreeza 6y ago
  The sad reality is that many of these actual applications load faster than pages that could really just be pages but still load vast amounts of JS...
  - k__ 6y ago
    Yes. Probably because people who create "real apps" and not just "docs on steroids" know what they're in for right from the start. If you start with a doc, you can get the feeling that there is much more headroom than there actually is.
  - jug 6y ago
    Static website generators in contexts where they make sense (heaps of the web) are still criminally underused. :-(
- superkuh 6y ago
  Of those I only go to github. And for now it still works without javascript execution. Sites that want or have to serve everyone do not use the web as an application because they know it doesn't work. Gov.uk and amazon.com for example went out of their way to work for all people of the world. And Gov.uk has found approximately 1 in 96 actual people do not have JS turned on[1]. For fancy businesses with other businesses as their end users you can get away with not supporting everyone. It doesn't effect their income so it doesn't matter. But the reality is that JS-application sites fail 1% of users and for actually serving everyone that 1% matters. [1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
  - nitrogen 6y ago
    And Gov.uk has found approximately 1 in 96 actual people do not have JS turned on[1]. It's challenging to convince a PM that people who block stats don't show up in their stats, but do still have money to spend. Often, a simple try/catch in the onclick handler that fires analytics events, and a quick happy path test with ublock on, is all it would take to fix a site. Well worth the 1% of extra revenue for a few minutes effort.
    - edoceo 6y ago
      The math is $500 expense today for the test code. $0.01 each time the test runs and +$ for each client acquired. At $20/mo MRR it's 3 clients/year. Easily pays for itself.
    - jandrese 6y ago
      I suspect that 1 in 96 figure is mostly people who have uMatrix or NoScript installed, not people who have disabled JavaScript entirely. A little judicious blocking can greatly improve browsing experience at the cost of having to set up rules for sites when you first visit them sometimes. It can be a real hassle when someone has embedded a video you want to watch and there are like 8 layers of embedded scripts from different domains necessary before you get to the actual video content.
  - capitainenemo 6y ago
    gmail works without JS too . I use it routinely with w3m
- smadge 6y ago
  GitHub fits the document model pretty well in my opinion.
  - k__ 6y ago
    And the one that doesn't require JS in that list. Bad example, I give you that.
    - superkuh 6y ago
      Gmail also has a perfectly working non-javscript interface. Or you can just use pop3 or imap with a real client and avoid the web crap all together.
      - postalrat 6y ago
        I'd argue that gmail without js is an application made to act like a document when it just isn't.
      - rootusrootus 6y ago
        > Or you can just use pop3 or imap This is my choice, except that periodically I have to go back to the web interface because searching over IMAP barely works at all. Maybe it's not even implemented and I'm only really searching downloaded mail, I'm not sure.
        superkuh 6y ago
        The imap interface will also never deliver any of the mail that gmail mailservers accept but then tag spam. That's pretty much mail from any independent mailserver that's not some megacorp or spamming so much that they can use google's postmaster tools to get approved because they spam so much.
- gjs278 6y ago
  and all of those are slow as hell
- vbezhenar 6y ago
  Everyone lives in its own bubble. Among websites that I routinely visit, only Youtube could be counted as web application, but I'd argue that its main function could be simplified to a <video> tag.
skohan 6y ago
Is there a good solution to rendering something like a react app to a static page? I feel like there are a lot of pages that don't really need client-side html rendering, but they have it because react is a good solution for modular web content.
- andai 6y ago
  Probably not what you're after, but load the page in Chrome, open the Inspector, and copy the entire HTML out. (Which will be a different HTML than the empty stub that "View Source" gives you.) You could automate it with Selenium (headless Chrome). I think Googlebot does something similar?
- k__ 6y ago
  As far as I know, all major frontend frameworks can render to a static HTML document.
  - skohan 6y ago
    How would you do that? I guess through webpack?
    - k__ 6y ago
      https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export
      - jayphen 6y ago
        This outputs static HTML that gets hydrated on the client (as opposed to server rendering the HTML and then hydrating it on the client), which I don’t think what was being asked. I think what the OP was asking was more along the lines of partial hydration (where only parts of the DOM are hydrated by React/other framework) or no hydration (no JavaScript is loaded at all). 11ty does the latter: https://www.11ty.dev https://www.11ty.dev The React team are working on partial hydration and announced it in December. Vercel did a write up on it here: https://vercel.com/blog/everything-about-react-server-components https://vercel.com/blog/everything-about-react-server-compon...
dimitrios1 6y ago
I am sorry to say but this is an overly simplistic answer. We've had Javascript since 1995. We've been building great applications with it as early as the 2000s, Yahoo being on the forefront. We had complex charting applications and dashboards in an era where JavaScript was still interpreted by the latest cutting edge browser: Internet Explorer 6. This was also a time of much slower internet speeds across the board. Bad software development slows the web down. The web, for what it is and does, is an incredibly fast network. The problem is people no longer care about performance, nor do you have the engineering talent to write performant web applications. Yes some of this can be boiled down to companies not prioritizing performance, and product managers pushing for more features and tracking, but we've always had these constraints, and tight deadlines, and seemed to deliver just fine. It was part of the expectations. Our craft is degrading, I hate to say. We've allowed the vocal minority who were shouting "gatekeepers!" to water down the discipline of software development to the point where yes, you install a single npm dependency so you can reverse your array.
- joosters 6y ago
  Bad software development slows the web down This is an empty statement and another overly simplistic answer. Of course bad software development slows the web down, because you're defining slow web sites as being badly developed.
  - hansel_der 6y ago
    > because you're defining slow web sites as being badly developed whats wrong with that? living throu the computers/internet/web for 25 years i can attest that there is truth in wirth's law, if only that folks are lazy.
    - vlovich123 6y ago
      Op is pointing out the argument is tautological and doesn’t add anything insightful to the discussion. All tautological statements are true. You could similarly write: “Lazy software development is why websites are slow because slow websites are caused by lazy development.” “Greedy business practices are why websites are slow because advertising slows down the web and advertising is the result of greedy business practices”. These are feel good statements that don’t actually provide any insight on the market forces at play nor provide any path to improving things.
deleted 6y ago
[deleted]
frompdx 6y ago
Absolutely. Last night I had the misfortune of experiencing a comcast outage. Although I live in the city, my neighborhood has horrible cellular coverage. Comcast serves their outage data through their account management portal which happens to be a massive, bloated, slow javascript app. It took minutes to load on my phone to find out if there was an outage. All of this for something that should be no more complicated than entering a zip code and getting back a small page with information about whether or not there is an outage.
- nitrogen 6y ago
  I ran into the same problem last week. Customer service portals are rarely given priority when resources are allocated, but it's pretty astonishing just how slow such a critical service portal loads over mobile tethering, given that is going to be a primary usecase. I'm practically counting down the days until this summer when a new fiber ISP rollout is supposed to reach me.
dgb23 6y ago
> It's in the domain name: catchjs. The reason that the web is slow now is javascript. That is, treating a webpage like an application instead of a document. This analysis just assumes all websites are JS-application monsters and only differentiates between them. It misses the point. A large part of the web are static documents and they should be developed as such. But I 100% disagree that this is how every website should be. We're given these amazing technologies, the internet, computers, libraries, tools and creativity and now we should just stick with sending and looking at formatted text? I don't think so! https://ciechanow.ski/gears/ https://ciechanow.ski/gears/ https://www.maria.cloud/ https://www.maria.cloud/ https://nextjournal.com/ https://nextjournal.com/ > What makes it even slower is the practice of serially chain loading JS from multiple domains. Once you're 3 deep in that it doesn't matter how 'fast' your webserver is or how fast and clean your JS code is, the serial loading will slow things to a crawl. Bundling, code splitting, tree shaking and asynchronous loading, pre-optimizations help here too.
neya 6y ago
I miss the 90s where HTML pages just contained just super informative text and a bunch of links to other super informative text. Flash was fun for a while with some nice animations and interactivity, then the JS themes took over, they were double edged swords - they enabled us to do things previously we would need separate installable desktop applications for (Email, Powerpoint, etc.) on the browser itself, but it also enabled every newbie hipster to push these tools for everyday pages, the value of the informative plain text was eroded in just under a decade and replaced with subscription popups, with shallow titled articles like "4 ways you can do X..by the way give me your email so I can spam you" I miss the marquee era, truly.
1vuio0pswjnm7 6y ago
James Mickens on Javascript: https://vimeo.com/111122950 https://vimeo.com/111122950 Here's a stupid, simple Vimeo downloader instead of a using the massive, slow starting youtube-dl #!/bin/sh # usage: curl https://vimeo.com/123456789 | $0 x=$(curl -s `grep -m1 -o https://player.vimeo.com/video/[^\"?]*|sed 's>$>/config>'`|grep -o https://[^\"]*mp4|sed -n \$p) y=${x%/*};y=${y##*/};exec curl -so $y.mp4 $x More from Mickens: https://www.usenix.org/legacy/events/webapps10/tech/full_papers/Mickens.pdf https://www.usenix.org/legacy/events/webapps10/tech/full_pap... https://www.usenix.org/system/files/1403_02-08_mickens.pdf https://www.usenix.org/system/files/1403_02-08_mickens.pdf Unlike Mickens, I cannot save the world, and I am not telling anyone else what to do or not to do, but I made the web fast for myself. Hence I am very skeptical of claims that "the web is slow". Web servers, the network and computers are plenty fast and still getting faster. I do not define "the web" as certain popular browsers, CSS, Javascript, etc. or whatever web developer tell me it is. Those are someone else's follies. I define it as hyperlinks (thus, a "web") and backwards compatible HTML. Stuff that is reliable and always works. To "make the web fast", I follow some simple rules. I only load resources from one domain, I forgo graphics, and I do not use big, complex, graphical, "modern" web browsers to make HTTP requests. I do not even use wget or curl (only in examples on HN). I generate the HTTP myself using software I wrote in C for that purpose and send using TCP clients others have written over the years. There are so many of them. With a "modern" SSL-enabled forward proxy or stunnel, they all work with today's websites. "Small programs that do one thing well", as the meme goes. Obviously, I still need the ever-changing, privacy-leaking, security risk-creating, eye-straining, power-consuming, time-wasting, bloated, omnibus browsers for any sort of serious transaction done with web, e.g., commerce, financial, etc. However that is a small fraction of web use in my case. For me, using the web primarily comprises searching, reading and downloading. I never need Javascript for those tasks. I can do those them faster without the popular broswers than I can with them. The less interaction the better. I use automation where I can because IMO that is what computers were made for. "The right tool for the job", as the meme goes. To think how much time and energy (kwH) has been devoted to trying to make Javascript faster as a way to make websites faster is, well, I won't think about it. Those working in the "software industry" and now "tech" are highly adept at creating the problems they are trying solve. Unfortunately today as we try to rely on software and the web for important things, we all have to suffer through that process with them. By not using the popular browsers for a majority of web use, I have minimised the suffering of one user: me. The web is fast.
newsbinator 6y ago
If everybody would learn to voice-control their smart phones and receive 3x speed audio feedback, battery life would shoot through the roof, since illuminating the screen is so costly, and you'd never need to do it. Blind people use smartphones this way, so it's not as though the device can't support it. And it would encourage all websites to be accessible, content-only, no-image sites, and they'd be no-javascript as well. Problem solved.
- chrisco255 6y ago
  How is this going to solve the chief bandwidth problem on the internet of watching funny cat videos and perusing dank memes?
  - deleted 6y ago
    [deleted]
gfiorav 6y ago
Agreed with this. I dabbled in React for a while, but then I realized how flawed the concept is (it's like downloading a full .dll every time you run a program). I always ask myself if something can be static now, and if so, I make it static. I recently worked on a side project to transition [0] to a fully static web. Needless to say, the speed went up. [0]- https://beachboyslegacy.com/ https://beachboyslegacy.com/
jakelazaroff 6y ago
> That is, treating a webpage like an application instead of a document. That’s not why. It’s ad networks and tracking scripts. Notice that single page application frameworks show up exactly zero times on the list of worst offenders.
dwd 6y ago
Every site is a JS-application monster because of the 3rd party add-ons people feel they need to have. Running Google or FaceBook ads? You need analytics, pixels and event trackers to know if you're ads are working optimally. ReCaptcha v3 is a good way to slow down your site as are hero banner sliders (5% of sites were running GreenSock + Waypoint), also some flavour of interactive chat. Some 3rd party plugins simply don't work with async/defer or still use DOM write().
dastx 6y ago
> It's in the domain name: catchjs I'm sceptical of this statement. I think catching application errors is a necessity to ensure your application runs smoothly and doesn't mess with customer/user experience. We're already tracking all the errors in the backend, and we should also be able to do the same with frontend. At the end of the day, we're all humans, we will introduce bugs. Even if you can guarantee 100% no one will deliberately introduce bugs, there's still the accidental introduction, or the third party library issues. The issue comes with tracking users. The amount of code needed to track user interactions is insane, because of the number of possible interactions. Tracking application code generally does not need a lot of code. Sadly, the user trackers have messed it up for application error trackers too. We're blocking everything regardless of context, and this doesn't allow websites to fix their application errors.

k__ 6y ago

I don't know what kind of web you are using. But The sites I'm visiting on a daily basis are, in fact, applications and not documents. Slack, Asana, GitHub, Gravit Designer, Google Docs/Sheets/Mail...

phreeza 6y ago
The sad reality is that many of these actual applications load faster than pages that could really just be pages but still load vast amounts of JS...
- k__ 6y ago
  Yes. Probably because people who create "real apps" and not just "docs on steroids" know what they're in for right from the start. If you start with a doc, you can get the feeling that there is much more headroom than there actually is.
- jug 6y ago
  Static website generators in contexts where they make sense (heaps of the web) are still criminally underused. :-(
superkuh 6y ago
Of those I only go to github. And for now it still works without javascript execution. Sites that want or have to serve everyone do not use the web as an application because they know it doesn't work. Gov.uk and amazon.com for example went out of their way to work for all people of the world. And Gov.uk has found approximately 1 in 96 actual people do not have JS turned on[1]. For fancy businesses with other businesses as their end users you can get away with not supporting everyone. It doesn't effect their income so it doesn't matter. But the reality is that JS-application sites fail 1% of users and for actually serving everyone that 1% matters. [1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
- nitrogen 6y ago
  And Gov.uk has found approximately 1 in 96 actual people do not have JS turned on[1]. It's challenging to convince a PM that people who block stats don't show up in their stats, but do still have money to spend. Often, a simple try/catch in the onclick handler that fires analytics events, and a quick happy path test with ublock on, is all it would take to fix a site. Well worth the 1% of extra revenue for a few minutes effort.
  - edoceo 6y ago
    The math is $500 expense today for the test code. $0.01 each time the test runs and +$ for each client acquired. At $20/mo MRR it's 3 clients/year. Easily pays for itself.
  - jandrese 6y ago
    I suspect that 1 in 96 figure is mostly people who have uMatrix or NoScript installed, not people who have disabled JavaScript entirely. A little judicious blocking can greatly improve browsing experience at the cost of having to set up rules for sites when you first visit them sometimes. It can be a real hassle when someone has embedded a video you want to watch and there are like 8 layers of embedded scripts from different domains necessary before you get to the actual video content.
- capitainenemo 6y ago
  gmail works without JS too . I use it routinely with w3m
smadge 6y ago
GitHub fits the document model pretty well in my opinion.
- k__ 6y ago
  And the one that doesn't require JS in that list. Bad example, I give you that.
  - superkuh 6y ago
    Gmail also has a perfectly working non-javscript interface. Or you can just use pop3 or imap with a real client and avoid the web crap all together.
    - postalrat 6y ago
      I'd argue that gmail without js is an application made to act like a document when it just isn't.
    - rootusrootus 6y ago
      > Or you can just use pop3 or imap This is my choice, except that periodically I have to go back to the web interface because searching over IMAP barely works at all. Maybe it's not even implemented and I'm only really searching downloaded mail, I'm not sure.
      - superkuh 6y ago
        The imap interface will also never deliver any of the mail that gmail mailservers accept but then tag spam. That's pretty much mail from any independent mailserver that's not some megacorp or spamming so much that they can use google's postmaster tools to get approved because they spam so much.
gjs278 6y ago
and all of those are slow as hell
vbezhenar 6y ago
Everyone lives in its own bubble. Among websites that I routinely visit, only Youtube could be counted as web application, but I'd argue that its main function could be simplified to a <video> tag.

skohan 6y ago

Is there a good solution to rendering something like a react app to a static page? I feel like there are a lot of pages that don't really need client-side html rendering, but they have it because react is a good solution for modular web content.

andai 6y ago
Probably not what you're after, but load the page in Chrome, open the Inspector, and copy the entire HTML out. (Which will be a different HTML than the empty stub that "View Source" gives you.) You could automate it with Selenium (headless Chrome). I think Googlebot does something similar?
k__ 6y ago
As far as I know, all major frontend frameworks can render to a static HTML document.
- skohan 6y ago
  How would you do that? I guess through webpack?
  - k__ 6y ago
    https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export
    - jayphen 6y ago
      This outputs static HTML that gets hydrated on the client (as opposed to server rendering the HTML and then hydrating it on the client), which I don’t think what was being asked. I think what the OP was asking was more along the lines of partial hydration (where only parts of the DOM are hydrated by React/other framework) or no hydration (no JavaScript is loaded at all). 11ty does the latter: https://www.11ty.dev https://www.11ty.dev The React team are working on partial hydration and announced it in December. Vercel did a write up on it here: https://vercel.com/blog/everything-about-react-server-components https://vercel.com/blog/everything-about-react-server-compon...

dimitrios1 6y ago

I am sorry to say but this is an overly simplistic answer. We've had Javascript since 1995. We've been building great applications with it as early as the 2000s, Yahoo being on the forefront. We had complex charting applications and dashboards in an era where JavaScript was still interpreted by the latest cutting edge browser: Internet Explorer 6. This was also a time of much slower internet speeds across the board. Bad software development slows the web down. The web, for what it is and does, is an incredibly fast network. The problem is people no longer care about performance, nor do you have the engineering talent to write performant web applications. Yes some of this can be boiled down to companies not prioritizing performance, and product managers pushing for more features and tracking, but we've always had these constraints, and tight deadlines, and seemed to deliver just fine. It was part of the expectations. Our craft is degrading, I hate to say. We've allowed the vocal minority who were shouting "gatekeepers!" to water down the discipline of software development to the point where yes, you install a single npm dependency so you can reverse your array.

joosters 6y ago
Bad software development slows the web down This is an empty statement and another overly simplistic answer. Of course bad software development slows the web down, because you're defining slow web sites as being badly developed.
- hansel_der 6y ago
  > because you're defining slow web sites as being badly developed whats wrong with that? living throu the computers/internet/web for 25 years i can attest that there is truth in wirth's law, if only that folks are lazy.
  - vlovich123 6y ago
    Op is pointing out the argument is tautological and doesn’t add anything insightful to the discussion. All tautological statements are true. You could similarly write: “Lazy software development is why websites are slow because slow websites are caused by lazy development.” “Greedy business practices are why websites are slow because advertising slows down the web and advertising is the result of greedy business practices”. These are feel good statements that don’t actually provide any insight on the market forces at play nor provide any path to improving things.

deleted 6y ago

[deleted]

frompdx 6y ago

Absolutely. Last night I had the misfortune of experiencing a comcast outage. Although I live in the city, my neighborhood has horrible cellular coverage. Comcast serves their outage data through their account management portal which happens to be a massive, bloated, slow javascript app. It took minutes to load on my phone to find out if there was an outage. All of this for something that should be no more complicated than entering a zip code and getting back a small page with information about whether or not there is an outage.

nitrogen 6y ago
I ran into the same problem last week. Customer service portals are rarely given priority when resources are allocated, but it's pretty astonishing just how slow such a critical service portal loads over mobile tethering, given that is going to be a primary usecase. I'm practically counting down the days until this summer when a new fiber ISP rollout is supposed to reach me.

dgb23 6y ago

> It's in the domain name: catchjs. The reason that the web is slow now is javascript. That is, treating a webpage like an application instead of a document. This analysis just assumes all websites are JS-application monsters and only differentiates between them. It misses the point. A large part of the web are static documents and they should be developed as such. But I 100% disagree that this is how every website should be. We're given these amazing technologies, the internet, computers, libraries, tools and creativity and now we should just stick with sending and looking at formatted text? I don't think so! https://ciechanow.ski/gears/ https://ciechanow.ski/gears/ https://www.maria.cloud/ https://www.maria.cloud/ https://nextjournal.com/ https://nextjournal.com/ > What makes it even slower is the practice of serially chain loading JS from multiple domains. Once you're 3 deep in that it doesn't matter how 'fast' your webserver is or how fast and clean your JS code is, the serial loading will slow things to a crawl. Bundling, code splitting, tree shaking and asynchronous loading, pre-optimizations help here too.

neya 6y ago

I miss the 90s where HTML pages just contained just super informative text and a bunch of links to other super informative text. Flash was fun for a while with some nice animations and interactivity, then the JS themes took over, they were double edged swords - they enabled us to do things previously we would need separate installable desktop applications for (Email, Powerpoint, etc.) on the browser itself, but it also enabled every newbie hipster to push these tools for everyday pages, the value of the informative plain text was eroded in just under a decade and replaced with subscription popups, with shallow titled articles like "4 ways you can do X..by the way give me your email so I can spam you" I miss the marquee era, truly.

1vuio0pswjnm7 6y ago

James Mickens on Javascript: https://vimeo.com/111122950 https://vimeo.com/111122950 Here's a stupid, simple Vimeo downloader instead of a using the massive, slow starting youtube-dl #!/bin/sh # usage: curl https://vimeo.com/123456789 | $0 x=$(curl -s `grep -m1 -o https://player.vimeo.com/video/[^\"?]*|sed 's>$>/config>'`|grep -o https://[^\"]*mp4|sed -n \$p) y=${x%/*};y=${y##*/};exec curl -so $y.mp4 $x More from Mickens: https://www.usenix.org/legacy/events/webapps10/tech/full_papers/Mickens.pdf https://www.usenix.org/legacy/events/webapps10/tech/full_pap... https://www.usenix.org/system/files/1403_02-08_mickens.pdf https://www.usenix.org/system/files/1403_02-08_mickens.pdf Unlike Mickens, I cannot save the world, and I am not telling anyone else what to do or not to do, but I made the web fast for myself. Hence I am very skeptical of claims that "the web is slow". Web servers, the network and computers are plenty fast and still getting faster. I do not define "the web" as certain popular browsers, CSS, Javascript, etc. or whatever web developer tell me it is. Those are someone else's follies. I define it as hyperlinks (thus, a "web") and backwards compatible HTML. Stuff that is reliable and always works. To "make the web fast", I follow some simple rules. I only load resources from one domain, I forgo graphics, and I do not use big, complex, graphical, "modern" web browsers to make HTTP requests. I do not even use wget or curl (only in examples on HN). I generate the HTTP myself using software I wrote in C for that purpose and send using TCP clients others have written over the years. There are so many of them. With a "modern" SSL-enabled forward proxy or stunnel, they all work with today's websites. "Small programs that do one thing well", as the meme goes. Obviously, I still need the ever-changing, privacy-leaking, security risk-creating, eye-straining, power-consuming, time-wasting, bloated, omnibus browsers for any sort of serious transaction done with web, e.g., commerce, financial, etc. However that is a small fraction of web use in my case. For me, using the web primarily comprises searching, reading and downloading. I never need Javascript for those tasks. I can do those them faster without the popular broswers than I can with them. The less interaction the better. I use automation where I can because IMO that is what computers were made for. "The right tool for the job", as the meme goes. To think how much time and energy (kwH) has been devoted to trying to make Javascript faster as a way to make websites faster is, well, I won't think about it. Those working in the "software industry" and now "tech" are highly adept at creating the problems they are trying solve. Unfortunately today as we try to rely on software and the web for important things, we all have to suffer through that process with them. By not using the popular browsers for a majority of web use, I have minimised the suffering of one user: me. The web is fast.

newsbinator 6y ago

If everybody would learn to voice-control their smart phones and receive 3x speed audio feedback, battery life would shoot through the roof, since illuminating the screen is so costly, and you'd never need to do it. Blind people use smartphones this way, so it's not as though the device can't support it. And it would encourage all websites to be accessible, content-only, no-image sites, and they'd be no-javascript as well. Problem solved.

chrisco255 6y ago
How is this going to solve the chief bandwidth problem on the internet of watching funny cat videos and perusing dank memes?
- deleted 6y ago
  [deleted]

gfiorav 6y ago

Agreed with this. I dabbled in React for a while, but then I realized how flawed the concept is (it's like downloading a full .dll every time you run a program). I always ask myself if something can be static now, and if so, I make it static. I recently worked on a side project to transition [0] to a fully static web. Needless to say, the speed went up. [0]- https://beachboyslegacy.com/ https://beachboyslegacy.com/

jakelazaroff 6y ago

> That is, treating a webpage like an application instead of a document. That’s not why. It’s ad networks and tracking scripts. Notice that single page application frameworks show up exactly zero times on the list of worst offenders.

dwd 6y ago

Every site is a JS-application monster because of the 3rd party add-ons people feel they need to have. Running Google or FaceBook ads? You need analytics, pixels and event trackers to know if you're ads are working optimally. ReCaptcha v3 is a good way to slow down your site as are hero banner sliders (5% of sites were running GreenSock + Waypoint), also some flavour of interactive chat. Some 3rd party plugins simply don't work with async/defer or still use DOM write().

dastx 6y ago

> It's in the domain name: catchjs I'm sceptical of this statement. I think catching application errors is a necessity to ensure your application runs smoothly and doesn't mess with customer/user experience. We're already tracking all the errors in the backend, and we should also be able to do the same with frontend. At the end of the day, we're all humans, we will introduce bugs. Even if you can guarantee 100% no one will deliberately introduce bugs, there's still the accidental introduction, or the third party library issues. The issue comes with tracking users. The amount of code needed to track user interactions is insane, because of the number of possible interactions. Tracking application code generally does not need a lot of code. Sadly, the user trackers have messed it up for application error trackers too. We're blocking everything regardless of context, and this doesn't allow websites to fix their application errors.