Why browse the Web in Emacs? (2008)
sachachua.com
sachachua.com
Browsing the web in Emacs is a bit too hardcore for me though :P
Now it's cool to break the back button (and links and everything) and make me watch spinners. It's as if the text and thumbnails they're serving today somehow take two orders of magnitude more bandwidth to load...
I'm a web dev, I know that ajax loading sucks, that without enough budget to do it right (and we never have enough budget) UX ends up broken, messing with scrolling sucks, page-based is best, don't make an app if it should actually be a site, etc.
Do I get any say? Not really. What do I end up building? Magic-scrolling ajax-loading apps, and if I have any budget left at the end of the job it goes on tweaking typography (i.e. designer-visible stuff) rather than fixing back buttons.
Which is to say, devs still know that this stuff sucks, but we're no longer in charge of the relevant decisions.
I wouldn't be disabling JS if it weren't such a pain in the ass. Or maybe I still would, just for security.
Even if some sites deploy instrumentation, it doesn't mean they're necessarily lifting a finger to make it faster for me.
If it's a "page" I am going to "read", I don't feel the need to enable arbitrary execution of whatever gets stuffed down the pipe, beyond rendering the more restrictively defined HTML and some hopefully well-debugged -- although even with them problems continue to crop up -- image formats.
It's like a biological viral infection. Hygiene can keep it out, but once it's inside, you may have a very persistent and possibly quite debilitating problem.
I don't want to be disconnected from the world. Neither, however, do I want to engage in, um... "unprotected casual browsing".
It makes me angry because it is a gross abuse of the web platform. The web is not for applications, it's for documents. I would be just as angry if I received a Word document that contained scripts that it needed to run to display the document (actually I would be angry if I received any Word document).
I don't want 7 tracking scripts, 4 advertisement scripts, jQuery, Angular.js, and whatever other junk modern webdevelopers include on their "websites". I just want the content, and that's what HTML is for. You don't need to include any JavaScript programs to show me formatted text, which is what I visited the page for. I didn't visit to see fancy scrolling effects, to have my every interaction with the document tracked, or to see nothing at all if I don't run foreign programs. I just want the content. Just give me a [motherfucking website](http://motherfuckingwebsite.com/).
It makes me angry because it is a gross abuse of the
web platform. The web is not for applications, it's for
documents. I would be just as angry if I received a Word
document that contained scripts that it needed to run to
display the document (actually I would be angry if I
received any Word document).
The latter has gained world-wide adoption because developers and industries couldn't agree to build a standard software repository that was distributed and allowed independent re-implementations of the running engine. Java tried to be that standard, but didn't have a convenient way to deliver software to end users. App stores later are becoming a close second, but being walled gardens they'll never replace that role in full.
It's still useful to think of "the two webs" as different purposes for the HTML5 technology; it's a good question in particular to ask yourself before you start a new website and decide what of the two models you want to support. Requesting that all webs are coded assuming the "web of documents" view is not realistic anymore, though.
Some uses of client-side scripting on the web are useful and necessary. When that is the case, make a real application instead of abusing a platform for publishing documents. Web app developers are just making things worse for everyone.
When client-side scripting is not necessary, web developers use it anyway for some reason. Blogger is a great example of this: a blog post is definitely a document, it doesn't need any client-side scripting, yet Blogger blogs just show an empty page if you visit them with JS disabled. Why would they do that?! It's almost as if they want Blogger to be as inaccessible as possible.
>My webmail client isn't a document, it's a browser for documents.
That's exactly why it shouldn't be on the web! Abusing the web to make it into an application platform is like forcing a square into a circle-shaped hole. The web doesn't have to be everything to everyone, just let it be a platform for documents.
The stream part is easy enough, with pagination. I have no objection to hiding the pages with JavaScript, making any page 'bottomless.' Real-time notification, obviously, can't work without some sort of execution, but one could simply show notifications on the next page viewed (or calculate them when sending that page, or whatever).
> My webmail client isn't a document, it's a browser for documents.
Good thing that you're using a browser…
I'm not opposed to using JavaScript to speed things up or enhance them, but using it to deliberately break the Web is just wrong.
I cringe every time I load up a browser on the iPad and wonder what information sites are gathering.
P.S. Next version might be a local proxy (well, usually local) which will improve browser performance, cross-compatibility with other browsers and across OSes, and all around fit better, imho (which is that a browser's only job is to render web content).
I also browse the web with Javascript disabled (using Noscript), but have formed the opposite impression: more and more sites won't display their content (or display their content incorrectly) if Javascript is disabled. Most of the sites I'm looking at are not "web apps" or SPAs (single page apps), they are sites with text articles or links so they have no real reason to break without Javascript. (It's always annoying when you attempt to click a link only to find it won't work unless Javascript is enabled.)
The rise of Javascript frameworks is only fuelling this trend of Javascript-dependent web sites. I've said this before, but Web developers pick the tools that make their lives easier (as you'd expect), but that doesn't always mean that users get the best experience.
Ah, the number of times I've asked colleagues to stop doing this! If you want a JS-powered link/button/whatever on a page, insert it using JS; then you're guaranteed that it will only show up for those who can use it.
Likewise, all togglable content should begin visible, and selectively-hidden by JS during page load; that way, it only gets hidden for those users capable of showing it again.
Also, although this is rarer, all work should be done in small, isolated event handlers. That way, when some unexpected situation arises (eg. the user is blocking your chosen spyware platform), that particular handler dies, but all of the rest keep working (eg. the button handlers, the slideshows, etc.).
When I for some reason was forced to use lynx, which I don't normally do, I was simply amazed by how smooth browsing is, it doesn't feel like the usual "internet" anymore, more like navigating your project via text editor on the local filesystem. But unfortunately as you go further than browsing ArchWiki it becomes almost unusable due to lack of static (in the sense "no js") sites support.
W3m-js is/was a thing. Also, w3m can apparently draw images inline via xterm, though I wasn't able to get this working in the ~10 minutes I tried on OSX Yosemite with X11 and xterm using the w3m from homebrew. UZBL is ok too, if you just want a minimalistic WebKit browser with vim key binds.
If you're considering whether to go back and change it, don't bother; you've failed. The point is to do it that way the first time, instinctively.
The time&money spent writing element-inserting JS corresponds to time&money saved by not adding a bunch of links/buttons/etc. to HTML templates.
If you're tied into a framework which makes the right way more difficult, then file a bug with the framework devs ;)
Web developers pick the tools that make their lives easier (as you'd expect), but that doesn't always mean that users get the best experience.
...which I think is both selfish and somewhat ironic since web developers are almost certainly users too.
My experience was that content was a first-class-citizen of the gopher-net, because we didn't have "hyper media".
Anyone else running Lynx? I don't use it for normal browsing (FF+NoScript like many others here) but I do fire it up for some of the purposes listed in the original article - works well with my workflow, no distractions, and of course it's really safe. Incidentally, it still fully supports Gopher.
On Mac OS, I highly recommend Lynxlet http://habilis.net/lynxlet/
I've often wished someone would by the .text TLD and have strict bans on images and restrictions on scripts.
It'd probably just quickly and abysmally fail, but hey, 140 character limits caught on, who knows.
I'm skeptical of that. Of course no one is actually targetting whatever vulnerabilities there are, and getting rid of JS helps a lot. But is all the code sandboxed or anything?
Obviously there's no such thing as perfect security, but I would guess it's way more difficult to exploit than your conventional browsers.
It is very convenient for copying snippets of code and pasting them in whatever file you are editing (or a REPL), too.
The same, to a lesser degree, goes for Dillo. It is amazing how Dillo can have dozens of tabs open and never use more thant 50-100 MB of RAM... :)
(defadvice shr-color-check (before unfuck compile activate)
"Don't let stupid shr change background colors."
(setq bg (face-background 'default)))One step up from Dillo is Netsurf, which seems to handle more CSS than Dillo but is still pretty snappy.
"Resource hogging" always seems like such a crazy reasoning. It's more aesthetic than practicalities. Is your memory really so scarce?
My computer is noticeably slower when Firefox is running. Quite often, Firefox will grab the audio device and not give it back, silencing all other programs. Sometimes the fan will just spin up and the computer will sound like a hoover until I quit it. Over time it just uses up more and more memory, rarely giving it back. It's not unusual to look at the task list and see Firefox taking up 400+MBytes, even though you're doing very little. (Right now, it's taking up 420MBytes. All I have open is the HN page with this text box I'm typing in.) I also think it does something rude with the GPU, too - when I'm not running Firefox, the auto-hide dock pops up perfectly smoothly. When Firefox is running, though, it stutters as it pops up.
The X11 version is terrible to use over a network too.
(I had a whole different set of complaints about Safari.)
If it only infects files locally, it's a virus.
(Of course, propagating to other elisp files is both easy and completely orthogonal to Emacs, since you could do it in basically any language.)
The difference was the Word viruses got a lot more fame because more people used Word.
M-x eww http://www.lispworks.com/documentation/HyperSpec/Front/index_tx.htmIs it really so prevalent to browse without JS (I doubt the casual user would do that, since they're probably not even aware that JS exists)?
The only reason I'd care about displaying content without JS, is specifically for crawlers.
I really don't like the fact that this is getting more and more difficult to do. The Web is not about allowing random people to execute code on my computer; it's about reading documents and sharing information.
The reaction here strikes me quite a bit - talk about supporting an old web browser which has a small market share, and the reaction will often be that it's a waste of time. No-js users are a miniscule fraction of a typical site's audience, so why would those sites bother to support them any more than they would bother to support an old browser?
Also, angry users are always the most vocal. The huge majority that doesn't bother (or doesn't even know how to) turning off javascript will not complain on HN.
This is what it comes down to for me. I started browsing with Javascript off after both my cores were pegged at 100% for forty-five seconds to load a page with a 500 word movie review. The pages wasn't nearly as interactive without the Javascript, but I didn't care. I didn't want to interact. I just wanted to read the text.
If your site is an actual app that I'm going to interact with, I'll turn on Javascript. That makes sense. However, if it's something that I'm just going to read, then Javascript stays off.
My solution is to use different browsers. My default browser has JS turned off. If I encounter a possibly interesting site which requires JS then I use another browser for that. This solution keeps my default browser clean without need to configure any JS blocker.
[1]: http://firessh.net/
One of the points of the blog post is that web browsing in Emacs allows you to integrate browser work and Emacs work, which for me is the most compelling one. But you can possibly achieve something similar by integrating Emacs into Firefox via SSH and using for example .js [1] for automatization work. That way you wouldn’t have the disadvantage that you basically lose most formatting and layout which are actually quite helpful if you stay away from the loud and annoying websites. That’s why I thought it was worth mentioning. I also use Tree Style Tabs and it could be helpful to keep work related websites and Emacs buffers organized in that way.
Also crosh on my chromebook, which uses the same url just replaces nassh with crosh.