"That's also the old behaviour of browsers and the current one of text browsers."
As a daily text-only browser user for over three decades, using it as a "daily driver", I'm no doubt biased. I was a lynx user before links was released. I would never go back to using lynx. When I see HN comments suggesting lynx as an example of text-only browsing I question whether the commenter is actually using it as "daily driver", or looked at the source code and compared it with alternatives
links doesnotexist2
does not trigger a DNS lookup
Unlike elinks, w3m, etc.
One of the many reasons I prefer links (no graphics)
I use links as an offline HTML reader; I am opening local HTML files every day
That said, it's relatively easy to modify these programs to behave according to personal preference; they are relatively quick and easy to compile
One could remove the unwanted DNS lookups, for example
Contrast this with the so-called "modern" browser that almost zero users have the time and resources to modify and compile themselves
Instead, we see dissatisfied browser users beg browser vendors to make changes
To no avail
There are other ways to prevent unwanted DNS lookups besides modifying the source code
For example, I run own authoritative DNS on the loopback, with custom root.zone
All lookups by default return the same address: the address of the local forward proxy
The proxy's memory contains DNS data precollected periodically in bulk from a variety of sources. At startup/restart, the proxy loads the data into memory from a plain text file (a "map")
The map would not contain any DNS data for "doesnotexist2"
There is no way for DNS lookups to leave the loopback nor any way for HTTP requests to be sent to destinations other than the ones I approve
No Javascript engine in text-only browser
For use with "modern" (read: uncontrollable) browsers the proxy can deny requests for URLs ending in .js, add a Content-Security Policy response header that disables Javascript and, if the CSP were to be ignored, can rewrite pages to comment out or delete inline JS
What I mean is if "modern" browser vendors change their popular browsers to make it more difficult for users to control others' Javascript, we can use URL blocking, URL rewriting and/or page rewriting to modify or delete inline or sourced Javascript and/or substitute the user's own Javascripts
Comments
"That's also the old behaviour of browsers and the current one of text browsers."
As a daily text-only browser user for over three decades, using it as a "daily driver", I'm no doubt biased. I was a lynx user before links was released. I would never go back to using lynx. When I see HN comments suggesting lynx as an example of text-only browsing I question whether the commenter is actually using it as "daily driver", or looked at the source code and compared it with alternatives
does not trigger a DNS lookupUnlike elinks, w3m, etc.
One of the many reasons I prefer links (no graphics)
I use links as an offline HTML reader; I am opening local HTML files every day
That said, it's relatively easy to modify these programs to behave according to personal preference; they are relatively quick and easy to compile
One could remove the unwanted DNS lookups, for example
Contrast this with the so-called "modern" browser that almost zero users have the time and resources to modify and compile themselves
Instead, we see dissatisfied browser users beg browser vendors to make changes
To no avail
There are other ways to prevent unwanted DNS lookups besides modifying the source code
For example, I run own authoritative DNS on the loopback, with custom root.zone
All lookups by default return the same address: the address of the local forward proxy
The proxy's memory contains DNS data precollected periodically in bulk from a variety of sources. At startup/restart, the proxy loads the data into memory from a plain text file (a "map")
The map would not contain any DNS data for "doesnotexist2"
There is no way for DNS lookups to leave the loopback nor any way for HTTP requests to be sent to destinations other than the ones I approve
No Javascript engine in text-only browser
For use with "modern" (read: uncontrollable) browsers the proxy can deny requests for URLs ending in .js, add a Content-Security Policy response header that disables Javascript and, if the CSP were to be ignored, can rewrite pages to comment out or delete inline JS
Last sentence is sort of convoluted
What I mean is if "modern" browser vendors change their popular browsers to make it more difficult for users to control others' Javascript, we can use URL blocking, URL rewriting and/or page rewriting to modify or delete inline or sourced Javascript and/or substitute the user's own Javascripts