Do we need browsers?
blog.justletit.be
blog.justletit.be
99% of my internet life consists of a few homogenous styles of interaction: browsing pseudo-hierarchical directories; communicating via text; purchasing; looking at pictures and movies; etc. In a hypothetical cyber-utopia or something, this could all just be a simple protocol (say, um, combining aspects of Direct Connect, BitTorrent, NNTP, Gopher, Bitcoin, GPG) that I could use with my own client, which would probably be an Emacs interface. Instead we live in a world where the web standards seem to encourage teams to spend their energy on reimplementing drop-down widgets.
It's wasteful and doesn't even lead to particularly good user interfaces. How many sites or web apps work well (actually well, not just semi-tolerably) with keyboard navigation? How much bandwidth and CPU goes to waste? How many sites work passably offline? How easy is it to automate tasks as a user? How easy is it to learn how to make your own sites?
I think "browsers" should be something very different from what they are today, and maybe something new will come along in the near future.
For example, consider the five technologies for interactive, animated things in the browser: Java applets, ActiveX, Flash, Silverlight, and Javascript. Apart from Silverlight, which never really took off, they're all 20 years old. Only Javascript has survived the security wars; Java applets are dead, Flash gets a CVE bullet with its name on every few weeks, and ActiveX was killed long ago.
The near-death of NNTP is a story of spam cancels and cost allocation.
The browser covers all use cases and is available everywhere. That means it's necessarily horribly compromised compared to native solutions, but is an absolutely killer advantage for adoption. Incrementalism nearly always wins.
Furthermore, the unwillingness of people to pay directly for software leaves us with a continual problem of exploitative software. Everything from flashlight apps that steal your contact list to ads that steal your battery to connection-sharing apps that open you to liability for the actions of others. For the moment, we keep other people's software securely nailed shut in the browser.
It is not as popular or generic as the five you mentioned but I do see it pop up a lot if you want to do some casual web gaming, which I don't like, because it is just another plugin you need to use the "open" web.
Cracked me up, very well said. In general I agree that the document-centric browser has been abused horribly. Then we get obscene beasts like node.js, because, well, the browser does it, so must we.
Despite my indifference to Node.js, I can see the unification of client-side and server-side scripting into a single language being incredibly valuable to the millions of PHP and JavaScript developers (both front and back-end) out there: most of whom beyond the realm of HackerNews and want to get it done.
Not only that, it would significantly reduce the barrier to entry for web scripting and disincentivize beginners from picking up all those nasty habits such as md5 password hashing and manually constructing SQL queries from raw input which are so worryingly accessible.
The only thing I can see preventing this are:
1. Lack of a mod_node for Apache. Perhaps this exists? 2. The upload and refresh workflow so many PHP developers are familiar with 3. A scheduler to prevent any one website from blocking the Node.js event loop on shared hosting
Is this completely bonkers, or is it quite sane?
CPUs are there to be "wasted". You pay for that clock frequency to use it and make your life better. Most people don't want to do everything in a terminal. It's depressing.
I worked on a web-based replacement for medical record software, and a primary complaint from users was that they wanted to be able to use the keyboard. These weren't Unix nerds or whatever, they were normal people who wanted to get stuff done effectively and ergonomically.
Nobody knows you can do keyboard navigation on Google, and anyhow that's just one website with a special custom JavaScript. Why keyboard navigation on the web is so horrible and embarrassing is an interesting question with lots of strands to investigate.
Why would CPUs be there to be wasted? Power efficiency is even an ethical imperative these days. If there are more efficient ways to do the basic tasks of computing and networking, that also allows CPUs to do more interesting and valuable things.
It's not about Emacs, that's just my personal idiosyncratic preference. Other people have other preferences, which is exactly the point. Note that Emacs works very well with many network standards, like email, Usenet, IRC, RSS, even BitTorrent. These are protocols that have enough semantic structure, openness, and simplicity to allow access with different clients that present the information in whatever way is optimal for the user.
As for most people not wanting to use terminals, how do you know? Maybe they just don't like the existing terminal interfaces. Unix commands are notoriously cryptic and shells don't help much. But if you showed a normal person a nice-looking shell where you could type "netflix breaking bad s3" and get a nice presentation back, would they really be depressed?
In fact, in at least one way, Emacs has better mouse support than either Firefox or Chrome do, at least on OS X: in Firefox or Chrome, even when the browser's window is right up against the right edge of the screen, the rightmost column of pixels does not belong to the browser's scroll bar, which makes it hard to interact with the scroll bar, particularly since OS X 10.7 or 10.8 when scroll bars got thinner. In contrast, in a properly-designed OS X app, like TextEdit or TextMate, whenever the right edge of the app's window is up against the right edge of the screen, the user can just jam the mouse cursor to the right and start interacting with the scroll bar without the need to get the cursor into a thin target region. Now most Macs these days come with trackpads, and the problem I just described doesn't apply to users who scroll by using (two fingers on) the trackpad, but if the Mac is a desktop Mac (i.e., not a MacBook) and the user prefers a mouse to an external trackpad, this is an important issue.
Emacs, particularly the Mitsuharu version of Emacs (which everyone who uses Emacs with a pointing device on OS X should be using because the FSF version often has bugs that affect Emacs's integration with OS X's graphical subsystems) gets this "rightmost column of pixels" issue right. (Sublime Text and Atom are 2 more apps that do not get it right.)
So in summary, although Emacs looks like an ncurses- or terminal-interface app and not a native GUI-based app and although many Emacs users are vocal pointing-device skeptics, not all Emacs users are mouse-haters, and Emacs actually has very good support for pointing devices.
The browser interface is terrible. We use bug tracking software. JIRA. It's horrible. Click here, click there, this screen closes, that one opens, this thing is over here. Ugh. It is just a click fest. For this sort of thing I want an MDI interface. I read a report - it sounds like one a duplicate. I want to search for it. I want to go to a search window, do the search, and compare them side by side. Or I want to look at the backlog and the current sprint.
Sure, to an extent I can open multiple browser windows or tabs, etc. This is another example. - one windows for everything you are trying to do is often cumbersome and terrible. You are forcing UI design on me, the user, every. frigging. time. I. use. your. app. I don't want to open 5 tabs to the same site, maneuver them around, deal with "going back requires page resubmission" warnings, let alone deal with sites that don't understand my 5 tabs are all one session in my mind. Don't make the user solve that problem every day they use your product.
The article does mention p2p and decentralization, but the browser isn't whats holding that back. The client-server development paradigm is.
Currently, every dev making a p2p app has to roll their own platform because there's no standard (i.e. no LAMP, rails, or Heroku for deploying p2p apps). Some projects are working to change this, namely BitTorrent Maelstrom (which is a fork of Chromium with native support for magnet URLs, so it auto-renders an html/js package distributed via torrent); and http://ipfs.io (a sort of content-addressable p2p filesystem, or bittorrent on steroids).
edit: I could have used curl, an html processor and a pager like less or more
I have a pair of 27" monitors and almost never maximise windows - the exception is when working with very large images that need the full resolution.
I disagree that a sensible max-width is wasted screen real-estate. Even after resizing my browser I'd prefer my content to have a little bit of space to breathe.
This is mostly the websites fault, of course. It's the same forced-layout mentality that has always caused problems on the web.
It's frustrating when someone decides "damn the system" in the name of a proto pre-design-standards aesthetic instead of just making sure standard zooms leave their content at 12-14 words per line.
Which would essentially be the modern web as it is now.
Restful nature of the Web is giving good structure on which to build and time shows that evolution, instead of forcing one good solution, is much better way for technology adoption when it comes to the masses.
In contrast, "the modern web as it is now" gives you a single built-in layout engine and not even a chance to implement network libraries. And that's exactly my point: For a document viewer, that's fine. For an application distribution platform, not so much.
Interestingly, I'd say it's closest to how the latest Android does it. E.g., click on a wikipedia link and it opens the page in the wikipedia app.
I'm not really following your fragmentation/consolidation line of argument or how it relates to the modern web...
URLs / Security / Platform independence
Browsers based on standards offer all of these already. The problem is people trying to make products the web was not designed to run. That's why flash and co became so popular at one point and that's why browsers vendors are now trying to come up with something like web-assembly. I say sometimes it makes much more sense to write a native app. One isn't going to run a video-editing app like final cut on the web(especially since the file system api has been dropped, since Mozilla wasn't interested in it).
The author is saying, let's take the accessibility/entrepreneurial-nature of the web and bake it right into the user's desktop environment rather than placing it on top of a platform (the browser) that has to rewrite much of what's already there in the OS.
A better approach is having good defaults, and letting the user add associations as he needs. That way the control is returned to the user, and he will feel confident updating the list of associations. Bonus points for multicast and not being restricted to one string format.
I would love to be able to eschew the web tech altogether, since we can all agree that HTML/CSS/JS is a terrible solution for building rich applications. But how else do I deliver my software without making users jump through download + install + update hoops?
But yes, I agree. Many people use windows, and the download-install-update circus seems to be driving people to develop web applications.
Also, the reason package managers suck is because.. entropy. See Joe Armstrong, The Mess We're In http://www.youtube.com/watch?v=lKXe3HUG2l4
Browsers are just one of many tools to consume one of many types of data on the internet. The fact that we'd fallen into this browser-web-address-as-a-location-app-content-mining paradigm initially does not mean that it is the optimum one going forward.
To see how misaligned we've gotten, play a thought-game: if I were a blind, privacy-sensitive person, how would I consume content on the web? I wouldn't want or need ads, user-tracking, or any of the rest of it. All I'd want is somebody to read me some text for 5-10 minutes, maybe a few times a day. Each time I might have something to reply -- or not. This would provide me everything the current web does, and would be much more lightweight and flexible. 99% of the bytes we're pushing and the interactivity we experience from browsers has nothing at all to do with long-term value. It's much more focused on stickiness and engagement. One might use the word addiction. The core text data itself, while somewhat useful, is not very much at all compared to the rest of it.
Browsers are not built in users' best interest. Therefore I predict they'll be around for a very long time.
Does anyone, blind or not, want or need ads or user tracking? (I suppose you could argue that any login constitutes a (hopefully) benign form of user tracking; but then I could say that blind people will need such logins too!)
Someone will probably bring up the Facebook HTML5 mobile app thing, but consider on desktop it was always good enough, and in fact they still have a mobile web version of Facebook, which as far as I am aware is also pretty good. I think the main problem Facebook faced with their mobile app was the immaturity of web view controls on mobile, which have since come on by leaps and bounds (WKWebView on iOS 8+, Chromium web view on Android 4.4+).
Might be time for a rethink of the whole thing. An open, remote updatable, sandboxed, cross-platform, app platform, and leave the docs to the web browser.
open,
remote updatable,
sandboxed,
cross-platform,
app platform
And amongst the miniscule audience that did understand what lay in their hands, half chose to abuse the unwashed masses that didn't tend to the honor system that stood in place of proper techincal security practices at the time.
Were such things simply way too far ahead of their time, lost on a market too immature for such luxuries to be made generally available?
Will there ever be a time when people care enough about anything other than instant messaging, to invest hours learning the intricacies of how to make a VCR stop flashing 12:00 AM?
I like to have my email client, my native RSS reader, still jump to newsgroups occasionally, use my desktop chatting applications...
It's much harder to "monetize" a protocol. That's a feature, not a bug.
And ultimately it doesn't matter. Many of the layers of the computing stack are over- or under-engineered for the task they end up performing (have you seen the x86 ISA? The ELF spec?). But computers are very good at abstractions, so ultimately none of that matters. Running our applications on the web costs us a bit of complexity, a bit of performance, but we'll reach the point where all the mess is hidden the ordinary day-to-day programmer.
I'd love to see a project similar in spirit to Servo that instead of aiming to refactor the language browser engines are build with refactors the functionality they provide. Something that identifies the Majority Use Case™ and tries throwing out the rest.
I'm not saying that we should push for deprecation of certain functionality, but I think it'd be interesting if people would start using this browser for the promise of faster, snappier surfing.
My ideal browser would support only something like "use strong" from [1] and spawn Netscape 4.0 for all pages that abuse JS.
We can use the asm.js model for opting in. Browsers that support it run the pages super fast, other browsers run them just as fast as usual.
A browser engine supporting just this standard would be considerably smaller, more embeddable, and a nicer base for current webkit based apps (e.g. spotify, steam, or atom). It might also help apps that want to use something like webviews for embedding content but need to be careful with memory / performance.
So, what possible benefit could you get from having so many poor tools in a single place, that you can't improve by carrying around the equivalent set of separate high-quality tools? The Swiss knife ought to be such a terrible idea and nobody would ever use it, right?
The solution would be to wait until our understanding of the technologies for presentation and software distribution over networks become stable so that they don't change as much, and then to build the smallest, leanest browser we're capable of.
This doesn't mean that we don't have a need for browsers, as the article suggests; merely that we could use some better implementations.
Taken from wikipedia:
> During the late 1880s, the Swiss Army decided to purchase a new folding pocket knife for their soldiers. This knife was to be suitable for use by the army in opening canned food and disassembling the Swiss service rifle, the Schmidt–Rubin, which required a screwdriver for assembly. In January 1891, the knife received the official designation Modell 1890. The knife had a blade, reamer, can-opener, screwdriver, and grips made out of dark oak wood that was later partly replaced with ebony wood.
Photo: https://en.wikipedia.org/wiki/Swiss_Army_knife#/media/File:W...
The only thing the browser would supply would be the chrome, networking, sandboxing, and a canvas for the client to draw to.
The current web runtimes could be refactored into one of these clients. If you don't like the way CSS works, or if you think JS is weird, just write another client.
To start with, I don’t buy the premise “Okay, so web browsers are awful for applications.” The statements before are way to generic to prove anything.
“[...]resource hungry beasts with millions of lines of code” falsely connects those two properties.
“[...]use several gigabytes of RAM, even when just displaying document-like content” might also be rooted in advertisers packing megabytes of rubbish in an iframe or web devs loading tons of unneeded web fonts. So, that’s bad engineering on the server side, not the browser’s.
“[...]that reimplements much of the features of an operating system on top of a real operating system” Chromebook anyone? Yes, that’s actual, ready-to-be-bought devices out there right now, that do exactly this. And lo, the problems are somewhat contained.
The conclusion also does not show any solution to the non-problem discussed above. “Imagine something like xdg-open.” I don’t need to imagine that, I have it right before me available in the terminal. And packing another service discovery on top of the stack is, to come back to my opening words, not so different from the closed-world app stores. Even Ubuntu has such a thing. And guess what? For people without technical knowledge keeping everything in the browser is way more efficient (work-wise, not performance-wise) than explaining arbitrary switches in context from browser to some app to some other app and back to the browser.
Security: “I’m no expert [...but...] doesn’t seem to be completely unrealistic.” The devil’s in the detail, as virtually everyone who works on browsers’s JS engines can tell you. A runtime, that downloads arbitrary binaries from the web to be executed, sounds in every regard like a bad idea, even if you put it in a full virtual machine. The two-word argument against this is basically “Flash exploit”.
Platform independence: The author might be too young to remember Java’s “write once, run everywhere” claim, that turned out to be not so fully true. And turning the current state of almost full platform independence in the browser for some proposed, from-scratch infrastructure will become exactly that disaster, that Joel Spolsky warned about 15 years ago in the context of the Netscape rewrite (http://www.joelonsoftware.com/articles/fog0000000069.html).
“But one thing is certain: the web platform we have today is already bloated, does not suit our needs and severely limits innovation.” No. It is not certain. Browsers today run on low-profile smartphones. Bloated web platform? Most of these things are opt-in, and many clever people build fallback strategies in new specifications to enable _everyone_ to become part of the web. Limiting innovation? Quake runs smoothly in the browser. Who would have figured that 10 years ago?
All in all, to me it seems the post is written by someone, who hasn’t yet fully groked the web.
What about truly new stuff that nobody has seen before, neither inside browsers nor in native applications?
- canvas + 3D support
- asm.js / WebAssembly: a way to run performant byte code
- WebRTC: Video chat, file transfer P2P
- APIs closer to the hardware like vibration, ambience, speech, ...
- stuff, that’s being developed but I don’t know yet, because the field has become so huge now. Small glimpse: http://caniuse.com/
And for developers it’s a single platform, together with distribution channel.
Apart from that: Truly innovative stuff happens on the web regularly. For example, look no further than Facebook (or Reddit, Imgur, Twitter, whatever you like). A software (in the broader sense), that allows billions of people to connect with each other and share thoughts. Imagine that in the age of SMS, phone books or snail-mail! You will see, that it’s fundamental to make something like social networks, the browsers had first to evolve from the bunch of hacks, that they were in the 90’s.
Another example of the power of browsers: FirefoxOS. A complete smartphone OS powered by web technologies on a thin Linux layer.
So my point is: the “truly new stuff” is partly already out there, you just have to look. And partly it will hit your devices, when the browsers are evolved enough. It’s a continuous process, and not a single “wait, there’s more...” (which doesn’t surprise the least, when you think of the _huge_ numbers of devices out there).
Edit: Formatting.
Java tried to be C++, but run on every machine. That turned out to be difficult. But I don't think the author is thinking of Java. I guess he more has in mind domain specific languages, which are abstract enough in nature to be executed faithfully on any system with given capabilities.
Security also goes hand-in-hand with this form of abstraction. If the language can only express safe actions, the program will not be malicious. In pure languages, such as Haskell, one can use type-guarantees to enforce these restraints. One could imagine a virtual machine with this kind of typing.
Just look at the long history of people trying to bring Python in the browser, or the fight to get Java applets _out of the browser_ again.
Basically I read the article as “scrap that web thing, and just begin from scratch”. And this is not a worthwhile path to go for many reasons.
Because 'safe' is not well defined, I can't argue rigorously against this, but it seems like the sort of thing that falls afoul of Rice's theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem): for most reasonable definitions of 'safe', you can have a proveably safe language or you can have a Turing-complete language, but not both.
A function taking Integers to Integers in a pure language cannot do I/O, and thus is "safe" to run, in the sense that I can be guaranteed it does not contain a trojan making my computer into a peer on a botnet. This is true, even if I allow it to compute any computable function.
Computational expressiveness and "safeness" are in a sense orthogonal. And just as I don't think it is always appropriate for any function to do I/O, I am not convinced all functions should be able to perform any computation. But that's a different discussion.
Regarding definedness of the term "safe", I would say it is defined by your threat model. It not an absolute term, but dependent on context.
Not sarcasm, but an honest question: barring the argument "even full virtual machines have bugs", to which one might as well retort "even multiply heavily tested browsers have bugs", why isn't it safe to run such a program in a virtual machine? It seems that most of the pain of Flash exploits comes from the fact that Flash doesn't run in a (proper) sandbox.
(I'm not a web developer, so I could easily be talking nonsense.)
2) Nobody says browsers want to replace all applications. It's a false condition the whole article is based on.
And why is it anonymous? Does he/she know it's nonsense?
Many people have been saying exactly this. E.g. http://blog.codinghorror.com/all-programming-is-web-programm...
I know developing native client applications is not popular recently; there good reasons for that, such as wanting to develop your software for as wide an audience as possible. What you have to remember, when choosing your development environment, is that there are always limitations to every platform. On the web that means you are always going to be sandboxed not only in what the application can do, but also in how it can interact with the user. Given that we always have to care about phishing, CSRF/clickjacking, and numerous other types of malware, applications developed for the web will never[3] be able to do many of the things we expect from a native application.
This doesn't mean you can't do good things on the web (we could list numerous examples of Great Tools that are available on the web); it's just isn't going to ever have all of the features you get with a "real" native app. Even if you try really hard to get away from "document"-style nature of the web, the sandbox and realities of making things safe for the user will always be a problem. Yes, we can try to work around that by rebuilding another OS -inside- the browser. Some people are certainty trying. Instead of throwing your sanity away on that never-ending pile of problems endlessly-expanding complexity, I suggest simply realizing that while some things just aren't going to be practical inside the browser, for other problems it's still a decent platform to develop for, and it is slowly getting better.
Oh, and the Mac/OSX people will be angry you try to get them to force them to use too many non-native GUIs.
/* I'm skipping the discussion of the "software as a service" scam... I'll assume, for the moment, that the desire to make the web into an GUI shell is not simply part of a scam to try to convert one-time sales into a recurring service fee. */
[1] https://en.wikipedia.org/wiki/Shell_%28computing%29
[2] I once saw /usr/bin/gopher stuffed into /etc/passwd as the shell
[3] at least I hope it's "never" - making a platform where I can impersonate too much of your native GUI over the network just asking to be attacked
The major problem with web is : We use framework to abstract differences between browser which abstract web for different Operating system, which abstract hardwares.
Nowadays, when given a choice I always pick native projects over web ones.
But these type of statements usually earn downvotes in HN.
You use the protocol to match the application.
Instead of having separate programs for each document, we should only need, the "browser" to open them. And the documents should be able to link to each others. And served using an open standard.
It would also be great if you could open general purpose app's in the "browser" so you don't have to install them.
I do agree that browsers should be reviewed and revised and trimmed down to the essentials with added functionality through encapsulated plugins or so, the browser tries to solve too much imho
Most people want fast and easy to use applications, you just need to type address on any device with the internet and you're done! No installations, no updates, no dependencies, no worries.
Imagine some app which you don't know how it looks, you must install something like 20MB, then you find out it's crappy and now you must uninstall it. On the web browser you just close tab and voila.
Too bad he hates web browsers so much.
But I agree on a few ideas. It would be nice to have fast document-only thing separate from apps.
It would be nice if browsers had finer-grained security like Android.
It might be cool if we could take apart the browser monolith and have something more like components somehow.
The problem is economical, not technical. Content producers want stats (who is reading what for how long?). They want flexibility (images, fonts, math formulas, typography, videos, interactive 3D diagrams). They want income (Ads suck the least apparently). They want wide reach (desktop, mobile, ebook reader, billboards). They want interaction (comments, notes, sync). Todays browsers provide all that, but a document-only thing would restrict them. Find a way to improve upon the browser (most prominently on income) and investors will throw money at you to build it.
On the other hand, imagine the developer test-coverage nightmares that would produce!
Yeah, people who are too old to learn new things and/or hipsters. Use curl to browse the web as far as I'm concerned.
Meanwhile, Google search does instant results, Facebook comments don't trigger a page refresh and Youtube is an SPA. Seriously, the web has evolved, there's no point to these complaints. What exactly is the complaint again?
Is it so hard to imagine someone could have a different opinion than you?
All of your examples are factual claims which I don't dispute. (well, assuming "instant results" is branding for "submits the query every time you hit a key, modulo some debouncing" -- not actually instant in practice). I disagree with their value, though. I noticed both of those changes, because stuff stopped working for me. The only change I've seen from Instant Results(tm) is that now sometimes when I'm scrolling through the search results, they'll all disappear and I need to type some more letters in the search box then remove them. Luckily you can avoid that by using the browser's search box instead of the website. On YouTube I had an issue for a while where leaving fullscreen after changing video would cause the page to reload, interrupting playback for 2-3 seconds. I believe that's mostly fixed now, bringing the functionality back up to par with the original implementation.
Maybe I'm just a hipster, but I like my computer to do what I tell it, not what some random web designer overly enamoured of his own "blog application" tells it. Most of the time, I want a document, not a portal or an experience. In that sense, I don't think anyone wants to go back to the web we had, so much as sideways to a better future.
EDIT: Forgot Facebook. Don't use it. Can't say. But the users sure seem pleased with the constant evolution of the UI.
It's not hard at all. I'm not in denial, I've read the original article even top to bottom. I know people like this exist. I just don't think it has any relevance today.
>>> not actually instant in practice
Don't take it so literal. The feature is called Google Instant. That's the name.
>>> I believe that's mostly fixed now, bringing the functionality back up to par with the original implementation.
Your argument is... that there are bugs? Yeah, nice one.
>>> Most of the time, I want a document, not a portal or an experience.
In which case, a document should be given to you.
But Google, Facebook, Youtube and many others including "blogging applications" do not offer documents. They are dynamically generated for you, client or server side.
>>> But the users sure seem pleased with the constant evolution of the UI.
I'm pretty sure they would be less happy if Facebook delivered simple documents with no styles attached. And I don't think they hate it as much as they say they do, as Facebook is still actively used.
If the web would be served in a more structured way, we could have both. It's a pretty mess right now.