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

141–150 of 237 posts

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

#141

Post by tommek4077 »

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.

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

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

#142

Post by mperham »

kolinko wrote: post #134
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…

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

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

#143

Post by johnisgood »

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.

Maybe you can introduce smaller changes over a longer period of time? I dunno. Would not Windows users be stuck with that very old look if there were no changes? I mean, is this actually what you are favoring? That said, I cannot stand the trend of UI/UX on desktop being so touch-friendly, along with more padding and/or increased font sizes and less content, too.

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

#144

Post by tommek4077 »

vbo wrote: post #115
kaba0 wrote: post #100

Earlier quoted context omitted.

But what’s the whole point of rewriting the URL and rerendering in JS the whole page? I’m fairly sure that browsers are really great at caching, so no additional HTML, JS should be downloaded and the change might very well be faster with better history and UX if we drop SPAs.

The overall experience feels (and is) faster as you only need to update the DOM, not recreate it from scratch, so you're not rerendering the whole page. There's also less processing required on the server as you're only requesting the piece of data you know will change and the response comes back faster. The history API makes going back and forth seamless, as if you were browsing the "classical" way. But this comes w…

Only if you use 8k$ Macs. Not for normal people.

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

#145

Post by [deleted] »

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…

[deleted]

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

#147

Post by [deleted] »

vbo wrote: post #17

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…

[deleted]

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

#148

Post by johnisgood »

danShumway wrote: post #26
vbo wrote: post #17

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…

Sure it can, but is that the way these companies are using it? Are they using Javascript to improve experience and development speed? If a Twitter textbox is lagging while someone types, then that's a degradation in user experience, and a pretty fundamental one. I like autocomplete too, but I also like my text box not to lag, and maybe there's a middle ground? I wouldn't say I'm a "purist" about this stuff, but I do…

YouTube is super slow for me because of all the JavaScript. Plus I have to refresh because whenever I click on a link, it just takes too long to load, so I click refresh, at which point YouTube says I lost my Internet connection, which I did not. Sometimes I ended up having with some video with comments from the previous one. That, and I hate the "more space, less content" trend.

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

#149

Post by johnisgood »

tommek4077 wrote: post #144
vbo wrote: post #115

Earlier quoted context omitted.

The overall experience feels (and is) faster as you only need to update the DOM, not recreate it from scratch, so you're not rerendering the whole page. There's also less processing required on the server as you're only requesting the piece of data you know will change and the response comes back faster. The history API makes going back and forth seamless, as if you were browsing the "classical" way. But this comes w…

Only if you use 8k$ Macs. Not for normal people.

Perhaps it is just poorly written, or maybe it is the animations that are making it look like it is slower than it should be. I created a simple website where I update parts of the DOM, and it is super fast. I have the opposite experience on known websites.

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

#150

Post by [deleted] »

vbo wrote: post #76
eitland wrote: post #54

Earlier quoted context omitted.

Good points. I'm still not convinced it is worth everything we lost: - Instant loading - Sane page sizes - Cross browser compatibility by default, including text based browsers - Every page is reasonably safe by default - CPU is idle after initial page load - Battery life is great by default and probably a few more. I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad p…

Agree on all counts except instant loading, you can still do server-side rendering (from the same codebase as the client) and have the client library bootstrap/hydrate its state from it.

[deleted]
Post reply on HN