Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe we could tone down the JavaScript (2016)

eev.ee

Post reply on HN
Print view View original

101–110 of 237 posts

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

#101

Post by purerandomness »

root_axis wrote: post #79

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

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

#102

Post by tibbar »

Nextgrid wrote: post #56
Spivak wrote: post #47

Earlier quoted context omitted.

We’re saying the same thing. The web’s current tools requires devs to reimplement all that functionality from scratch, which isn’t gonna happen, when the ideal solution would be to start with the battle tested native control and then tweak from there to fit the design.

My point is that by tweaking the looks of the existing thing you are breaking standards users are used to or might be causing issues you're not even aware of (bad color choices for colorblind people for example) even if the behavior/functionality of the control is unchanged.

I think this is an important concern, but not a disqualifying one. There is already a lot of variety in the space of controls, for example compare browser controls to the Office Suite to native OS, it's a big spectrum. When controls are customized correctly they become more usable within the context of the app because they are sized consistently, line up with the content grid, follow visual cues from the rest of the app, etc.

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

#103

Post by root_axis »

purerandomness wrote: post #101
root_axis wrote: post #79

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

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

#104

Post by deltarholamda »

duxup wrote: post #87
root_axis wrote: post #79

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

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.

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

#105

Post by ranger207 »

glacials wrote: post #50

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…

They've also got a blogpost (from 2020) about that, which provides an interesting counterpoint to the posted article

https://eev.ee/blog/2020/02/01/old-css-new-css/

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

#106

Post by jenscow »

durnygbur wrote: post #55
jenscow wrote: post #39

Earlier quoted context omitted.

And this is why we need technical tests during interviews. There are people who call themselves "web developers", apparently been writing websites for 5+ years, but don't know about addEventListener.

But they how how to connect the Angular injector into the service directive.

An "Angular developer" would know that.

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

#107

Post by idrios »

root_axis wrote: post #79

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…

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

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

#108

Post by chubot »

duxup wrote: post #87
root_axis wrote: post #79

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 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 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 :-(

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

#109

Post by philistine »

ljm wrote: post #99
root_axis wrote: post #79

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…

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

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

#110

Post by rauhl »

root_axis wrote: post #103
purerandomness wrote: post #101

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.

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

Post reply on HN