I recently started to fork webkit to make it a Webview with a reduced attack surface. [2]<p>The most interesting part was the Quirks.cpp file [1] that contains literally randomized css classnames inside the web browser code because a major website was so shitty and spec violating in their implementations.<p>I mean, fixing a website in a browser source code...this shit got out of hand real quick yo.<p>The problem with all those drafts is that Google keeps doing their own thing, and others are forced to try to catch-up or implement the same bugs/quirks that chromium does. Everything is rushed so QUICly that even Microsoft gave up at some point. And at some point in the past google realized that they can own the web if they own the Browser. And that's what they effectively do now, because the competition isn't really a competition at all anymore.<p>[1] <a href="https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp" rel="nofollow">https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...</a><p>[2] <a href="https://github.com/tholian-network/retrokit" rel="nofollow">https://github.com/tholian-network/retrokit</a>
Finally. I am so happy someone else noticed how much of a garbage fire Twitter is when you limit (not even <i>block</i>) JavaScript.<p>I use uMatrix and a hardened Firefox profile so I notice pretty quickly if websites are poorly made. Spoiler: the vast majority are, and the big players like Twitter, Facebook, Google, etc. are absolutely the worst offenders.<p>But Twitter is so frustrating because of exactly what the article's author says: they re-invent everything, including the text in the Tweet box. As soon as you start typing a tweet it gets converted into some horrific swamp of HTML elements which starts to break really fast if you limit JS as I do.<p>At some point the concept of "graceful degradation", which used to be taught as an essential part of high-quality web development, was totally abandoned.<p>I feel like I'm transitioning into "old man yells at cloud" more and more every day, but the web's going down the shitter real fast.
Now that it's 2021, most of the concessions the author makes are possible with CSS. You can change the styling of an element using hyperlinks with the `target` pseudo selector:<p><pre><code> <style>
#dropdown {
display: none;
}
#dropdown:target {
display: block;
}
</style>
<a href="#dropdown">Show dropdown</a>
<div id="dropdown">
Dropped down!
<a href="#">Close</a>
</div>
</code></pre>
This works for dropdowns, tooltips, modals, even navigation if you're navigating to known places (or if you use JS to pre-insert the destination into the DOM). And of course, you can animate the changes with pure CSS.
No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement, it's unfortunate but these days no one should be asking it about web pages either.<p>The web is an application platform, it stopped being about documents years ago. Whatever you may feel about Xforms, its spec was published nearly 20 years ago and even now HTML forms still cannot do something as basic as a PUT request without JS or workarounds.<p>It's clear that browser vendors expect you to use JS for basic functionality, and for document distribution you'll be using PDF anyway so why try to pigeonhole the web onto something it is not? What's to be gained by pretending otherwise?
>here is a screenshot of a tweet, with all of the parts that do not work without JavaScript highlighted in red<p>And this is when I realized this article was written a long time ago. Now if you attempt read a text post on twitter you get nothing at all unless you execute javascript first. The entire screenshot would be red in 2021.
This blog loads 2mb of scripts, and if you disable JS you can't leave a comment or even read any comments. Personally, I don't have a problem with this, but I'd have expected a blog hosting an anti-js essay to be less dependent on JS. The author notes in the noscript block that using disqus is part of hosting a static blog, but that definition of "static" is an implementation detail - i.e. a convenience for the developer - but from a user's perspective the result is identical to rolling your own js comment system, the site doesn't work if you disable JS, thus calling into question the value of building a "static" website, especially in the context of an anti-js essay. The author could have instead supported non-js comments, but when the rubber hits the road they appeal to the same developer convenience and UX benefits that typical js developers espouse.
It's been thus, nigh on two decades now.<p>Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls."
Also Product Designer: "Why don't our custom controls work as well as system controls?"
I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll quickly realise how unmanageable it is let alone, as the author says, "iffy".
I honestly thought this attitude had died out with everything being Vue and React and all that<p>I used Huel's site earlier and it even had a splash overlay saying what it was loading, it was one reticulating splines away from being The Sims<p>Edit: ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore
Off topic, but eev.ve has some outstanding articles on game design and is the author of one of my favourite custom doom levels<p>Specifically, the articles of how graphical fidelity is ruining video games and the ones about doom and doom mapping
This is a big reason I’m really enjoying using Remix.<p>They by default aim to make building JS less apps super easy through their framework. And of course you can progressively enhance your app with JS if available.
I agree with this guy.<p>I generally try to do as much as I possibly can using pure CSS because half the time I regret using JS for things unless it is absolutely necessary
Maybe developers need to start testing their javascript heavy webpages on low end phones and computers to realize the terrible impact of javascript heavy webpages and how it's not very "inclusive" since it discriminates against the people who can't afford high end phones or PC? Especially when most administrative tasks now rely on filling forms on the internet, mobile or desktop.
It's not really JavaScript that's the problem but the way it's used, right?<p>No one says JS has to be used for weird and creepy tracking purposes.
I tried a bunch of different browsers today on a lark, because Firefox has become the monstrosity it was once created to replace, and new Linux distros just keep getting slower and slower on this aging Core i7-6500U laptop. The browsers included Edge, Epiphany, Vivaldi, Opera, Otter, Palemoon, Netsurf, Dillo.<p>Let me tell you, it was a gas. So many broken pages. Such a wide range of performance and "user experience". Browsing with Dillo was like looking at the internet through an abstract art painting, which was even more striking because I still remember when I could actually browse most websites with Dillo, and now <i>links2 -g</i> (remember how Links has graphics mode?) is literally more usable for browsing the web.<p>Turns out Epiphany is extremely minimal, fast, and renders pages well (and even supports Firefox Sync? that's cool), so I'm gonna try that as a daily driver.
I think this has come up on HN enough that people probably already know about these alternatives, but I really recommend using a Nitter front-end to browse Twitter if you don't actively maintain a Twitter account.<p>It doesn't help if like Eevee you <i>do</i> have an account and are actually tweeting, but if all you're doing is browsing then it runs completely Javascript-free.<p>----<p>In regards to the actual content of the article, it's an eye-opening experience to dig into how a lot of these pages are constructed and to realize that sites like Google search, Facebook, Twitter are not really designed around having the simplest most performant implementations.<p>There is some dark eldritch magic that happens behind the scenes on a lot of these sites that keeps them working with accessibility readers and nothing else: trying to make it harder to find hrefs, trying to get rid of right-click open in new tab commands, trying to make it impossible for browser extensions to identify parts of the HTML. And I think it's really easy at first to say, "this is a complicated problem we don't understand, of course this must be a super-performant hyper-optimized way of doing everything." But it just becomes harder and harder to justify that over time. The link wrapping that Google search does really doesn't have anything to do with performance, it's designed to close holes around how people open links without sending pingbacks to Google servers.<p>There is a real incentive battle between tracking/control and simplicity/performance/flexibility, and the performance side doesn't always win, it seems that big companies are actually willing to introduce a huge amount of engineering complexity for an outcome that's <i>almost as good</i> as a normal href but that allows them to accomplish other goals as well.<p>The level of complexity in these sites sometimes gets used as an excuse to avoid criticism, but I think that sometimes the complexity is there purely because sites are actually fighting with browser technology; Google's setup for link wrapping is very complicated, Twitter's text entry is very complicated, because they're trying to take control of a process that they don't normally have control over. So they build very complicated houses of cards that fall over in weird situations, and the complexity of the house of cards becomes the defense against criticism that the house of cards keeps falling over.<p>I look at projects like Nitter; Nitter is not a full Twitter replacement, but in regards to the parts of Twitter that it does replace, it's better engineered. It's less complicated, the engineering is less <i>impressive</i>, but impressive engineering is not the same thing as good engineering. For the features it's replicating, Nitter works better than the real thing, and I think the reason is that it's less complicated and that it's fighting less with the browser.
> Someone is trying to download a copy of your site to read while away from an Internet connection.<p>This is why I "print" web pages to PDF these days instead of saving as HTML.
I am not sure what Javascript buys you, but from a point of view of doing a server-side app and having to do the frontend... uh, it adds a lot of complexity.<p>I am taking a look into htmx. It looks way closer to what html is and it is more than enough for my purpose at least.
Similarly, I wrote to urge people who make websites to simulate slower connections: <a href="https://alanhogan.com/slow-it-down-gain-empathy" rel="nofollow">https://alanhogan.com/slow-it-down-gain-empathy</a>
> I can almost hear the Hacker News comments now, about what a luddite I am for not thinking five paragraphs of static text need to be infested with a thousand lines of script.<p>HN usually hates on misuse of JS pretty hard.
I believe it’s because programmers write websites, and when you have a hammer everything looks like a nail.<p>With webassembly we might start seeing compiled websites and we’ll miss the good old days of simple JavaScript.
Surprised to see the top comments here so doom-and-gloom: "ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore "<p>The tools we have available today to optimize JS and build for progressive enhancement are light years ahead of 2016 because the smartest minds in the industry have optimized for it. The rise of batteries-included server-side-rendered React apps like Remix and Next massively cut down on time-to-first-paint and React 18 makes it easier than ever to defer rendering of async or interactive portions of the page (e.g. the Like count, the reply form) in favor of getting static content on the screen as fast as possible.