Comment by ho_schi | Hacker News Reader

Comment by ho_schi | Hacker News Reader

I dare it - turn off JavaScript!?

Websites doesn't require JavaScript, what really needs JavaScript are Singe-Page-Web-Apps-Somethings with anti-patterns like infinite scrolling. You get two things in return, a "super duper" fast web and a more secure web-browser. For example Amazon supports usage without JavaScript very well. Another experience is Stackoverflow, things like the preview and highlighting doesn't work. The highlighting can be added with server-side code but this will cost some CPU-Time - and it is not your CPU-Time. It is their CPU-Time? There is tiny feature I would appreciate in HTML-Engines "copy link to location" instead of using JavaScript - but there is this usable hierarchical address-bar a the top (which Google tries to hide) which already serves this purpose.

I'm not against JavaScript. JavaScript is just a tool but I ask the question if good websites require it? Hackernews uses 134 lines of JavaScript, this is alredy nearly nothing. Can you imagine using Hackernews without JavaScript?

My webbrowser (WebKitGtk) provides a permission panel for every website:

* advertisements

* notifications

* password

* location

* microphone

* webcam

* media

A first step would be adding there JavaScript, too? Maybe some nasty Cookie-Dialogs will disappear as consequence. But that is not a loss?

I'm using uBlock Origin more or less in nightmare mode (https://github.com/gorhill/uBlock/wiki/Blocking-mode:-nightm...): all 3rd party stuff blocked, inline and 1st party scripts blocked. Some websites work out of the box and I love them, but too many still want me to enable 1st party scripts and 3rd party resources to at least display correctly even though most of the content I'm consuming is text.

This is also one of the reason I'm hoping more people write in Gemini, because it's just text

> Can you imagine using Hackernews without JavaScript?

It definitely works, it's just a very few small features that need javascript. The most important for me is the ability to collapse sub-threads, which is mandatory when reading threads with lots of comments.

HackerNews would not really work in gemeni though as there are too strict limitation on how long urls can be and the only way to send data is by appending it to the url.

I agree, but HN isn't really a "website", it's closer to an application: you don't really have documents. The ideal interface to have HN functionality is Usenet, or maybe mailing lists: you have many people exchanging messages about a specific subjects, quoting and replying to each other, all in very hierarchichal threads. It's only because HTTP is so widespread that HN uses that, but if it weren't I would bet we wouldn't even be talking about javascript.

How is infinite scroll an antipattern?

It‘s simply like having an automatic transmission in an ICE car.

The motor type is an implementation detail the user does not want to care about.

I want to press the pedal and the car accelerates. What happens in the background does not concern me.

Same for websites.

If I see a list that is larger than the height of my screen, I want to be able to keep scrolling until I decide to stop.

I do not care that the creators of the website have structured their database so that the current DB would return 573738 entries.

I also do not care that the way the developers decided to present the application to me (via a browser) means that every row entry is a HTML element and showing 573738 HTML nodes at once would slow down the browser.

I just want to keep scrolling (and will stop after a few hundred rows anyways).

Having these kind of ivory tower fringe opinions like „infinite scroll bad“ is gate-keeping by middle-aged backend devs that panic at the speed and impact of the frontend world, plain and simple.

I wouldn't call it an antipattern either - it literally does exactly what the programmer wants, but it's definitely a dark pattern.

Most of us humans have an urge to finish things, but infinite scroll by definition never finishes. This increases engagement of users by utilizing their psychology, which is basically the definition of a dark pattern.

There is an argument to be made that it also increases usability, so it's inception probably wasn't malicious. But it's definitely another product of today's addiction driven design philosophy if you just look at the psychological effect it has on users

Infinite scroll is a tool.

Your problem is with pointless dark-pattern ridden attention-grabbing social media using that tool (and rightfully so!).

Now imagine a useful application, like an email program.

Infinite scroll is useful there.

Imagine having a paginated inbox!

I prefer a paginated inbox, its that way in gmail for me (maybe I turned on some setting years ago?).

The pagination is a nice break and lets me know I am done, everything on back pages has been previously processed.

Dark pattern would probably a better naming. Infinite scroll works, you're right. For example every file-browser or mail-program, which show you the visible portion on screen and at same time scrolling through all items. On the web infinite-scroll is often used to load and reload stuff and you often cannot link to an item directly.

Wait, is there a way to make Gmail scroll? Always had an issue with pagination in Gmail.

Imagine an email program that, knowing how many total items there are in the inbox, gives you finite scroll! Even if it only streams metadata for nearby items, so if you suddenly drag the bar it has to wait for a network round-trip to show content, one of the problems with infinite scroll is that the scrollbar no longer shows a reliable absolute position.

A better case for infinite scrolling would be chat history, where you'd want an entirely separate UI widget for "jump to date", with bidirectional infinite scroll that unloads distant content, and a way to grab permalinks. Missing any one of those features, or the fact that messages will never be re-ordered for marketing purposes, infinite scrolling becomes a hinderance.

A paginated inbox can be extremely useful. Pagination gives you a "You are here" context: you are on page 3 of 20. That context is great in use cases such as "I need to review everything in this Inbox". If you just finished 3 of 20 in that case you know you are roughly 15% done. If for some reason you are interrupted and need to close the app and come back you know that you can probably start right where you left at on page 4 of 20.

Finite scroll is a compromise that you get some amount "you are here" context from scrollbar thumb size and position. If you are interrupted you can generally visually guess about where you left off, maybe.

Infinite scroll is terrible tool for an inbox because you no longer have such context. Scroll too far and the scrollbar thumb changes size because new items came into view. Most infinite scrolls entirely hide the scrollbar thumb because it is precisely so useless. Try to resume where you were in your inbox after an interruption and you have no idea how far to scroll down, and you can't just use the scrollbar thumb and hit an approximate spot. You have no context for where you are, you are lost in an infinitely scrolling maze of items all alike.

Even if infinite scroll wasn't a dark pattern (and it is, there's enough behavioral psychology studies now that have gathered enough evidence that infinite scroll feeds addictive behaviors), it is a terrible tool to work with if you are trying to get stuff done. It has none of the context of "you are here" and "here's how you can come back to where you were if you need to leave". Both of those things contribute to why it is such a dark pattern. Both of those reasons are strong reasons why it is an anti-pattern anywhere you expect people to work/to get stuff done. Pagination is great for getting work done and infinite scroll is awful. Finite scroll is alright compromise between the two for some apps.

Imagine an email program that isn't built with web technology. It could actually display all the items in your mailbox, with a normal and usable scroll bar, without "infinite scroll". I distinctly remember applications being able to display lists in the before-times.

It does break searching for content within a web page.

Ok, but the content wouldn't be there (and thus searchable) either if the website used pagination, no?

In that scenario, I search the page, and if it's not found, I go to the next page and search there. Repeat to the end.

That algorithm breaks on infinite scroll.

What form of book do you prefer to read? One with pages or a scroll which leave confused at all time on what part of the thing you are on or have read?

In fact I do prefer to read books as a large seamless HTML file rather than a paginated PDF file that has cuts (new pages) at arbitrary positions.

Now, of course the ideal way to read a book is probably a navigation/outline sidebar on the left, and then the content of the current chapter in the main pane.

Kind of like the Rust book: https://doc.rust-lang.org/book/

so you have no problem with a scrollbar that jump to the next chaper when you shift it by a couple of pixels then?

Of course why would you have a problem with that, the only navigation one should perform while reading is change chaper, who wants to go to abitrary paragraphs.

what?

?

I'm 100% on board with this line of thinking, but the edge case that the business keeps complaining about is being able to push async events to the client.

How would we accomplish this sort of UX without javascript?

I think the argument is that while a good amount of my daily web browser usage might like that feature (as I do in fact use it as an application sandbox), a vanishingly small number of the separate web sites I visit on any given day (which are all one-off pieces of content I am accessing) need that to functionality, and I can whitelist them by turning JS on for them, as they are also pretty much the same few websites every day.

That ... is an interesting question that is not really a problem for someone who wants to browse the web without JavaScript. Which is almost the only person whos choice really matters when it comes to user security.

Some sites I've accidentally browsed without NoScript makes me question how people access sites with JS enabled at all. There are some shockers out there.

I believe you can utilize partial http response streaming that never stops and there is even a way to replace html fragments. I‘m sure i‘ve seen this, but I am having no luck finding anything about it.

Edit: here it is https://news.ycombinator.com/item?id=16319248

For this edge case I suggest handling JavaScript like Webcam-Access, if a website wants to use it they can and need to convince the users. So we have an agreement between both sides :)

I foster myself some weird JavaSript to allow hardware-access. But I think business itself should not be the driving force for the technical development and society.

I need a WYSIWYG editor, a very simple one for Forum uses. And some sort of Ajax, Pjax function.

I think that covers 90% of my needs. If we could get that without enabling JS. Some function could move back to Server at the expense of more CPU cycle.

Although pushing more features to HTML isn't exactly a great idea either.

What I find most interesting as a JavaScript developer is that almost no open source projects will touch the stupidity of giant SPA frameworks. Seriously, if you are writing software on your own time why burn that time away digging in the trash?

On the contrary JavaScript developers that don’t contribute to open source cannot write two lines of code without some disgustingly bloated framework and a million dependencies to do half their job for them. You can’t even get hired without completely caving into the stupidity. It feels like cult membership lighting money on fire.

Yeah dude this overgeneralisation is not cool. I'm a JS dev, and you're insinuating that since I don't write FOSS, I am a brainless monkey who glues frameworks together. Classic elitism, and it shows your hand as a gatekeeper. Not cool.

Not exactly. I am insinuating you are a brainless monkey if you need a ginormous SPA framework to build a simple web page with a couple click events.

> Classic elitism, and it shows your hand as a gatekeeper. Not cool.

Cry me a river. I am not being elitist by suggesting you should learn to do your job. I really don't care how uncool it sounds or how many tears you shed.

I am not sure what you or the downvote brigade want here. Do you want me to feel sorry for you?

Reply on news.ycombinator.com