Hacker News Reader

Comment by root_axis | Hacker News Reader

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.

View on HN

I think you misunderstood the entire point of the author, especially since you have called it an 'anti-js essay'.

From the article:

> Accept that sometimes, or for some people, your JavaScript will not work. Put some thought into what that means. Err on the side of basing your work on existing HTML mechanisms whenever you can

As you have observed, disabling JavaScript does not make the site stop working entirely for no reason. It degrades meaningfully, and the author put thought into what that means

Moreover, enabling JS does not break browser functionality you're used to.

That's the entire point.

> As you have observed, disabling JavaScript does not make the site stop working entirely for no reason.

Such is the case for most JS sites, the site typically doesn't break "entirely", but I consider being unable to post or even read comments to be a major functional breakdown. Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.

> I consider being unable to post or even read comments to be a major functional breakdown.

For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties.

> Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.

I kinda agree. The issue is that it is very rare to find a static site generator which can interface with a dynamic comment storage. To be honest, I don’t know that one exists, although of course it is completely possible. I can understand as a pragmatic matter why someone might have a static blog, want to add comments and not be willing to run his own dynamic comment system, esp. if that would entail writing said system.

All that being written, it would be awesome to have a static site generator which were called by a hook in a dynamic comment server. I actually would like to write one someday!

> For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties.

The author has posted several comments in the comment section, so even by your definition the blog fails to meet functional standards. However, IMO, the distinction between the author's comments and user comments is arbitrary, both are text meant to be read by readers, and those readers without JS are missing a ton of discussion that's happening in the comments, including discussion with the author. There's actually more to read in the comment section than in the blog post itself.

> All that being written, it would be awesome to have a static site generator which were called by a hook in a dynamic comment server. I actually would like to write one someday!

I have actually seen a system like this implemented at company I used to work for. A posted comment would be stored in a sqlite database before a request to rebuild the comment section is fired (as a partial, to avoid re-rendering the whole page/site), subsequently dumping the new build into the CDN (with some debounce logic to throttle high comment traffic). The rebuild was typically sub-second and performed very well.

Minor improvement; a rebuild queue. Workers scaled to platform capability (or just one). When a worker fires, scan the queue for other requests for the same content and use the freshest version / mark the future requests completed when the refresh finishes.

This seems to be exactly how Gatsby et al work, by pulling in "dynamic" content over an API at build time. I've never seen this being used to re-render a site based on third-party changes like comments, but it's popular to pull data from a first-party system like a CMS containing e.g. the blog posts.

Though I wonder if the prevalence of programmable edge networks will leapfrog that before it becomes really mainstream, and allow site owners to add a small bit of edge dynamism to pull dynamic content in without client-side JS.

It does seem like it'd be neat of these embedded comment services to have a server side rendered page that just shows all the comments for a specific post, which could be linked to when JS is disabled. Yes, the link sends you off-site, but you'd still be able to read and probably even participate without JS. I'm sure there's at least one service that can do this.

They do have such an off site page[0] but hilariously it just embeds the widget.

[0] - https://disqus.com/home/discussion/veekun/maybe_we_could_ton...

It isnt. They always show "This app needs Javascript enabled" even if its a simple blog.

In fact the site you're using right here doesn't need JS to post nor read comments.

I think that it's a bit of a cop-out to call your site static in instances like this. You've outsourced computation to a 3rd party as well as the user's browser, as opposed to doing it on your own server. It would be dynamic if you cobbled a comment system together with some CGI scripts and an SQLite database and some server-side includes, and it's still dynamic if you abstract that into a runtime dependency on the client, because the content of the page is going to be different whenever you refresh and new comments are made.

The difference between the server-side option and the outsourced one is that the outsourced one is probably also going to soak up and resell a lot of data that you probably wouldn't have captured yourself.

Yup. I say down with comments on websites! Let the big boys of websites like this one take care of comments.

Removing comments on my website was a great idea. Instead, people email me and I don't have to moderate anything.

Indeed. I get a few emails a month from my site and I'm happy to read every one. Whereas I'm sure if I had an open comment section eventually adbots would discover it.

A "static site" typically means to have the site being generated through a build step such that you can serve it straight from a CDN or simple file server. It doesn't say anything about the content included and it's "dynamism".

The comments on the blog are managed by Disqus. If he wanted to do them without JS, he'd need to build a commenting system all by himself - and that's almost impossible nowadays because of the spam issues.

Everything else on the site seems to uphold to his principles.

She

Thanks, I missed that.

Just hold the comments for moderation?

You’d spend more time moderating comments than writing posts. Seriously.

Any time I tried doing that, 99.9% of comments were spam. Seriously.

99% of my email is spam too and the filter there isn't even all that sensible.

[ ] i am not a robot

Impossible? Hardly. Comment screening, rate limits, captchas, and email verification are all great spam mitigation options. Besides, you can still get spammed using something like disqus, I see it all the time on high traffic news and entertainment sites that use disqus.

I feel like I sympathize with a lot of the various JavaScript rants in a way … but I’m not convinced that many of the blogs about it (that now feel like years old spam) are actually practicing what they preach or have ever waved the magic wand they want to exist.

I’ve yet to see a real guide from someone building an even moderately complex site and moving away from these terrible frameworks and “unnecessary JS”.

In the end most of these boil down to “I wish other people would build their sites the way I want them to” without much consideration of how / why a site is the way it is in the first place.

Way back, Conventional Wisdom was "build the site so that people with JS turned off could still use it." This was great advice in 2001, but it's pretty hard to do now. You have to choose what is, and what is not, convenient and/or appropriate for the end user. And that's pretty hard to determine, as there are more varieties of "end users" than atoms in the universe.

Plus, even if you're really careful and make something that is judicious with JS, phone users come in and blow everything up. For example, leaving a review could be done JS free buy opening a dedicated review view, and if the end user needs to refer back to the product, they can open a new tab. It's not so easy with a phone, unless they have really strong phone browser kung fu.

I would have thought that by now we would have settled on broad conventions for most things so nobody would be inventing all new ways of doing the basics. Instead is seems like things are proliferating. If there are any standards, they're top-down things from Big Corporations like Twitter or Google, because they have the muscle to force everybody to use their conventions and like it.

Yeah I'd like to see that too. One site I think that does a fantastic job is sourcehut. It actually has a little bit of JS, e.g. for the builds page to stream results, but it's fast and light, and measured to be fast.

And it's a pretty big and functional site.

https://sourcehut.org/

https://forgeperf.org/

I've looked at the source code and it's very straightforward Flask apps and Jinja templates, and hand-written JavaScript.

https://sr.ht/~sircmpwn/sourcehut/sources

For people who don't remember, the result is very similar to how Google looked ~15 years ago -- Google News, Froogle, search results, etc. The underlying tech was different, but the result is the same. Google just used C++ and the "google-ctemplate" language.

----

I wish that every food ordering app was written like this.

I mean all they are doing is displaying a list of pictures and then providing a checkout experience -- it's literally eBay from 1998, but 1000x slower.

It would also be like 10x faster than a native app on phone if it were written like that.

In fact Google has a lightning food ordering app right on the search results page that proves the point! However I tend not to use it because I don't think it's good to let the search provider "hijack" the traffic intended for restaurants. i.e. presumably the restaurant will put their preferred vendors on their sites, which is almost never Google, and is instead some really slow and janky app :-(

+1 for sourcehut. The people there have been making great, lightweight software for a lot of stuff. Despite looking simple they are often really powerful.

2mb of scripts actually seems impressively small. I'd say kudos to the author for practicing what she preaches.

This site here seems to have roughly 8kB of scripts, about 250kB for everything.

I'd say that's more impressive than loading the counterpart of multiple novels for mostly the same functionality.

Both websites could easily be done without JavaScript. I have built a blog and a site similar (without voting) to this using PHP/HTML/CSS when I was young.

HN works nicely without JS. With JS enabled it doesn't need to reload the page when you vote, so it's not necessary but still useful.

The problem are most other sites that often don't even load or show any content without JS support, or break in many creative ways. Although for weirdness you only need to disable custom fonts in the browser, and suddenly Reddit's notification button shows the Paypal logo and many websites have random chinese symbols scattered around the UI. And Google Translate looks like you need a translator to use it.

Reply on news.ycombinator.com