Live data from Hacker News

Maybe we could tone down the JavaScript (2016)

eev.ee

151–160 of 237 posts

Re: Maybe we could tone down the JavaScript (2016)

#151

I recently started to fork webkit to make it a Webview with a reduced attack surface. [2] 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. I mean, fixing a website in a browser source code...this shit got out of hand real quick yo. The problem with all t…

Microsoft took a somewhat similar approach with their “ Super Duper Secure Mode” in Edge. It disables the JIT in the V8 JavaScript engine to reduce the attack area of the browser:

https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Re: Maybe we could tone down the JavaScript (2016)

#152

Earlier quoted context omitted.

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…

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

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

Re: Maybe we could tone down the JavaScript (2016)

#153

I recently started to fork webkit to make it a Webview with a reduced attack surface. [2] 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. I mean, fixing a website in a browser source code...this shit got out of hand real quick yo. The problem with all t…

You would think that they would have at least have made it into a configuration file, instead of literally hard coding rules for specific website domains directly in the browser rendering engine C++ code?

Re: Maybe we could tone down the JavaScript (2016)

#154
post #110

Earlier quoted context omitted.

> 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 dyna…

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.

Re: Maybe we could tone down the JavaScript (2016)

#155

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: #dropdown { display: none; } #dropdown:target { display: block; } Show dropdown Dropped down! Close This works for dropdowns, tooltips, modals, even navigation if you're navigating to known places (or if you use JS to pre-insert the destinatio…

These sort of arrangements typically don't hold up when it comes to finer points of UX, like "clicking outside closes it" or "closes after x seconds", and so on. What if you wanted a keystroke shortcut to open the thing, or a keystroke shortcut to close it, the list goes on and on and on.

Product managers and designers don't care about reducing JavaScript, so that really has no weight against the things I've mentioned plus more. They want it to work the way they want it to work.

Re: Maybe we could tone down the JavaScript (2016)

#156
post #108
post #87

Earlier quoted context omitted.

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 t…

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 Jav…

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

Re: Maybe we could tone down the JavaScript (2016)

#157
post #99

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 devel…

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 c…

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

Re: Maybe we could tone down the JavaScript (2016)

#158
post #110

Earlier quoted context omitted.

> 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 dyna…

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

Re: Maybe we could tone down the JavaScript (2016)

#159

I recently started to fork webkit to make it a Webview with a reduced attack surface. [2] 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. I mean, fixing a website in a browser source code...this shit got out of hand real quick yo. The problem with all t…

I thought you were kidding about Quirks.cpp, but it is indeed true. I can imagine a few nightmarish scenarios where a quirk that was originally a fix becomes a bug when a company decides to alter its website. Worse still, the new code will probably work perfectly in a test environment, and then fail when you deploy to your actual domain. Some developer somewhere will be tearing their hair out trying to understand what the heck is going on...

Re: Maybe we could tone down the JavaScript (2016)

#160

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 devel…

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.

Just hold the comments for moderation?
Post reply on HN