Hacker News Reader

Comment by superkuh | Hacker News Reader

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.

View on HN

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...

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...

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.

Static website generators in contexts where they make sense (heaps of the web) are still criminally underused. :-(

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-missi...

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.

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.

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.

gmail works without JS too . I use it routinely with w3m

GitHub fits the document model pretty well in my opinion.

And the one that doesn't require JS in that list.

Bad example, I give you that.

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.

I'd argue that gmail without js is an application made to act like a document when it just isn't.

> 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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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.

It's a misreading of the point I was making. I was refuting the claim "javascript slows the web down" by qualifying it with "bad javascript slows the web down"

Right, but then you conclude that it is just incompetent engineering. That may be true in some cases, but in a lot of cases it's because it's not worth it to the business in terms of time or resources to do good engineering. Great engineering is not just about having great engineers, but a huge budget because it's very, very expensive.

Whatever the causes may be, the end result is poor engineering. I didn't say incompetent, but rather lazy and lower quality. Reading further into my point, I mention that often time this carelessness comes as a result of businesses pressing without giving attention to proper resources. But nonetheless, the end result of all of a businesses choices: hiring decisions, budget decisions, scheduling decisions, feature prioritizations, all the same result in the root cause of poor engineering.

> "Whatever the causes may be, the end result is poor engineering. I didn't say incompetent, but rather lazy and lower quality."

The engineering might be perfectly fine if you take into account the deadlines, budgets and requirements from the clients/managers.

If you pay someone to build a house on a short deadline with a small budget, then you'll obviously get a crappy house. But the skill that went into building that house in such a short time, and on such a low budget, might be extremely high.

Good engineering doesn't mean a perfect product. It just means you managed to deliver the best possible one out of the situation you were in. It's up to the owner of the product to decide if it's good enough.

No true scotsman would slow the Web down

argumentum ad logicam. And around and around we go.

Nope. From https://en.wikipedia.org/wiki/Argument_from_fallacy

> Argument from fallacy is the formal fallacy of analyzing an argument and inferring that, since it contains a fallacy, its conclusion must be false.

Nobody here is claiming that the parent's statement is false. We're saying it's true! However, we're also saying it's useless (i.e. "vacuously true" or "tautologically true"). The parent is saying that many Web sites contain JS; the slow ones are due to "bad JS" (and implicitly, that the non-slow ones have non-bad JS).

How can we tell whether some JS is "bad"? By checking if it's slow. Let's say we do that, and find that the site is slow, and hence our JS is "bad". How can we improve it, to get non-bad JS? No idea; maybe getting a bunch of developers to make random refactorings, measuring the speed of each, using that to tell whether the JS is still "bad", and stopping once it's no longer slow and hence no longer "bad"? In which case, the whole notion of "bad JS" is irrelevant; it's conceptually indistinguishable from "slow page", and hence adds nothing to the discussion (i.e. if we followed the above steps, we would get exactly the same result if we ignore all the stuff about "bad JS" and just use the timing measurements directly).

Note that the concepts of "slow page" and "page with JS" are not vacuous, since we can measure them (with a clock, and by parsing the page source, respectively) and hence make falsifiable predictions about correlations and causal relationships between them.

i see. thx for explaining and sry for the noise

Touché -- I am attempting to make a distinction between the general statement of "javascript slows the web down" to a certain type of Javascript slows the web down, namely lazy and careless Javascript slows the web down. We reach for the dependency first instead of carefully analyzing our requirements and making an engineering decision. I've seen it countless times, fallen victim to it a few times myself. It's really easy to do. No one stops to ask, "perhaps we do not need a hard dependency, and need to include that 15kb library, but rather just need a few functions from it?" or "perhaps a simple algorithm would indeed suffice." We mindlessly reach for complex regex engines to solve simple parsing problems, try to garner "functional programming cred" by reaching for a series of collection functions from our favorite 50kb utility package when a simple c-style for loop would have not only sufficed, but indeed got the job done much faster.

All this results in bloated, unoptimized javascript bundles. To top it off, we under cache, and aggressively cache bust, and ship unminified bundles with oodles of source maps because of "developer experience" I can't tell you how many times I see, to this day, a fortune 500 company bundling an entire unminified javascript framework. Wirth's law indeed.

Hope this was a little less empty. These are my observations having done this for a few decades now and managing developers these days.

I agree with all you are saying, but I wonder how much this actually comes down to software developers. I suspect (but have absolutely no data!) that for many sites, the pressure to add extra stats, tracking, advertising, monitoring, etc etc, comes from 'above' and it's not the developers' choice to add these mountains of javascript libraries to their sites. Perhaps they should push back, but what leverage do the developers have?

pretty much like enterprise software. The similar situation allows for an obvious for many conclusion - there is no money in performance, or more exactly the opportunity cost of performance is higher than benefit.

I'll try and offer the more controversial point.

Good software development can slow the web down. People are often optimizing for code reusability, code quality, ease of debugging and other advantages of some heavyweight frameworks rather than raw load time. Often this is the right call as engineering is a cost centre. Where it goes wrong is when things get too slow and too bloated to the point you're actually having people abandon the site before load but most of the major frameworks used properly don't offer that extreme a tradeoff. I also have no idea what % of these sites have reached that level.

> The problem is people no longer care about performance, nor do you have the engineering talent to write performant web applications.

I don't think that's the whole story. I don't have hard numbers but Electron-based applications seem to reliably be far more bloated than applications using ordinary GUI frameworks.

I agree that deprioritising performance is part of the problem, but as far as I can tell the web is a very poorly performing GUI framework, when it's used as such.

> the engineering talent to write performant web applications

Which, for the most part, is celebrated. Nearly nobody actually understands what they're doing anymore - I challenge anybody to point to the Javascript in their web app and explain what the purpose of each file is. Just the purpose, just the top level files. I doubt the majority of web devs can (if they could, they'd realize they don't need at least half of them).

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.

How is this going to solve the chief bandwidth problem on the internet of watching funny cat videos and perusing dank memes?

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.

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?

As far as I know, all major frontend frameworks can render to a static HTML document.

How would you do that? I guess through webpack?

https://nextjs.org/docs/advanced-features/static-html-export

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

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-compon...

You can look into the Gatsby and Next JS frameworks for this, among others

There's the likes of Gatsby [0], which is generally well supported and pairs well with Netlify and a headless CMS such as contentful.

0: https://www.gatsbyjs.com/

react-static (https://github.com/react-static/react-static) is both good and enough. You don't need Gatsby/Next or anything else.

> 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://www.maria.cloud/

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.

> 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.

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().

> 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.

James Mickens on Javascript:

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