8 ms·

Do we need browsers?

122 points by barnacs 11y ago

asdfaoeu 11y ago
Regardless of what he's said its nice to read a webpage that for once didn't take 5 seconds to load, didn't clobber my screen with unnessecary junk or have jerky scrolling.
- qznc 11y ago
  I would have appreciated a sensible max-width on my fullscreen desktop browser.
  - w__m 11y ago
    On the other side, You can have your own stylesheet, without even a single !important ;)
  - pantulis 11y ago
    Safari's Reader View for the rescue ;)
    - vilmosi 11y ago
      Which kind of defeats the purpose of the original article.
      - aliem 11y ago
        I think it does the opposite, The author wanted to send a structured document without presentation, with your tool of liking (I used Firefox's reader view) you can read comfortably without compromising the content of the article or it's features. edit: I could have used curl, an html processor and a pager like less or more
        vilmosi 11y ago
        I'm pretty sure the author is against using special tools to read static text. That's his whole point, that people don't need browsers/readers or any fancy app to read static text!
  - userbinator 11y ago
    Why not resize the window to your preferred width? max-width would just waste most of the screen with whitespace, while a smaller window will let you put it where you want and work with other things in the rest of the space. 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.
    - mc808 11y ago
      I almost always maximize windows unless I'm doing something where I need to mentally integrate multiple applications. I'm certainly not going to fuck around with popping tabs out into individual windows and resizing them when casually consuming content. Either it's legible or I move on.
  - the8472 11y ago
    I dislike max-widths. It wastes screen real-estate.
    - geon 11y ago
      100% of the window is wasted if the lines are too long to read.
    - lojack 11y ago
      So, books, magazines, and virtually every form of print should have margins, but the web should have the text go right up to the edge of the browser? 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.
      - rootlocus 11y ago
        I just realized that the comment section of hackernews uses ~80% of the window width, with hardly any padding for top level comments.
  - lmm 11y ago
    I wouldn't. I like the page wide. I like that by not setting a max-width, I can have my browser at whatever width works for me. This is how the web was supposed to work.
  - onion2k 11y ago
    You have one. It's called "the size of the browser window". If you don't want a site to be the size of your monitor, don't use a full screen window.
    - pdkl95 11y ago
      This is how I use the browser - 1920px is way too wide for reading, and I like my browser windows in portrait mode for more vertical space anyway. Unfortunately, yet another idiotic "feature" of javascript (and CSS media queries) allow the webpage access to the actual monitor resolution. Some particularly idiotic sites use this, causing utterly unreadable pages (i.e. all "sidebar" and margin) if you have your your window at something like 900px wide instead of the 1920px they are detecting. This is mostly the websites fault, of course. It's the same forced-layout mentality that has always caused problems on the web.
      - A_Beer_Clinked 11y ago
        as a remedy I have one of my monitors rotated 90° into portrait orientation. I can just drag the offending tab across and have a screen width of 1200px. There are a (very) few sites though that seem to cache the original screen width and need a hard refresh.
  - mattlutze 11y ago
    Agreed... well-circulated research demonstrates maximum comfortable line widths for various mediums. 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.
mixmastamyk 11y ago
I've been thinking the same thing for years. There were a few attempts at parts of the problem like java, XUL, or XForms, etc but they didn't break out. 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.
- CmonDev 11y ago
  WebAssembly is the latest hope.
  - idonthaveaname 11y ago
    WebAssembly is only going to make the situation worse.
- tritium 11y ago
  open, remote updatable, sandboxed, cross-platform, app platform The problem isn't that we haven't faithfully accomplished all of those ideals set forth. The problem is that there were much too few, sophisticated enough to appreciate what was placed before them. 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?
Boldewyn 11y ago
Well, we have a scenario rather close to the one described in the article on mobile: Browsers for text content and apps for specialized stuff, that can incorporate web views, if needed, and access the net. (Yes, I’ve read the second-to-last sentence.) In a nutshell, it sucks. 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 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.
black_knight 11y ago
Off on a tangent here. He mentions he wants a tool which takes uris and figures out the correct program to handle it. This sounds a lot like plumber [1] from Plan 9. Plumber has a powerful, configurable method of finding the right tool to handle a string, and other programs can make it aware of the context the string should be interpreted in. [1] http://doc.cat-v.org/plan_9/4th_edition/papers/plumb http://doc.cat-v.org/plan_9/4th_edition/papers/plumb
- ReaperOfCode 11y ago
  Sounds to me like things already work on mobile OS-es e.g. on android tapping a youtube linke can take you to the app to view instead of in the browser. Perhaps you could have the same kind of function on desktop OS-es shouldn't be too hard , all the apps just need to understand URLs. Could even go further than a lookup table for certain domains, and have different protocols etc.
  - black_knight 11y ago
    Taking Android as a example here. The way this works is by basically letting apps declare that they are interested in certain URLs, and then present the URL-clicking user a list of applications that are interested to choose from. This quickly becomes annoying and checking the "Remember" button is something you quickly regret when you change your preference. This simply will not be practical on a desktop where you might use a hundred different programs. There is also the inherent limitation that you only send the URL to one program. 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.
    - ilaksh 11y ago
      Upcoming Android has deep links/defaults.
  - 1wd 11y ago
    Doesn't Windows already have that? Go to ''Control Panel'', ''Default Programs'', ''Associate a file or protocol with a specific program''. For example FTP, HTTP, HTTPS get associated with Firefox, MAILTO with Thunderbird, URL:PowerPoint with PowerPoint etc.
CmonDev 11y ago
Yes, we do - for hypertext documents - as per original design. Retrofitted JavaScript - we don't.
lmm 11y ago
Sadly there's no way to get to there from here. Something like Java Web Start was and remains a much nicer application platform than a web browser. But every device has a web browser, and manufacturers fall over themselves to add support for the latest "web" functionality. 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.
z1mm32m4n 11y ago
The article mentions that "web browsers have become resource hungry beasts with millions of lines of code," suggesting that much of this cruft has been the result of having to support backwards-compatible standards for the web. 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.
- fridek 11y ago
  From what I've heard Microsoft Edge looks like such attempt. When a site requires some kind of compatibility mode, the not-so-good-but-indeed-old IE is spawned to serve it. Great approach and I hope they set the bar high to make the common use case faster. My ideal browser would support only something like "use strong" from [1] and spawn Netscape 4.0 for all pages that abuse JS. [1] https://developers.google.com/v8/experiments https://developers.google.com/v8/experiments
- gunn 11y ago
  I've been thinking about something like this for a while - a standard for an easily optimised subset of html technologies. To conform to this standard, pages would be restricted in the ways they can manipulate the DOM, have a simpler DOM, use only a small fraction of CSS properties, and not use some JS features e.g. eval, delete. 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.
test1235 11y ago
According to my company firewall, this site has been blocked for malware ... ?
- fkooman 11y ago
  Proving (part of) the point of the article ;)
ilaksh 11y ago
Web assembly. Android deep linking. 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.
- qznc 11y ago
  > nice to have fast document-only thing separate from apps 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.
- JadeNB 11y ago
  > It might be cool if we could take apart the browser monolith and have something more like components somehow. On the other hand, imagine the developer test-coverage nightmares that would produce!
aikah 11y ago
hyperlinks are successful. if "native apps" had a standard way to handle links between apps then we wouldn't need browsers. if "native apps" would run automatically in a secure and sandboxed environment without requiring any installation then we wouldn't need native apps. We can argue about webtechs but there is no alternative to browsers and the 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).
- mrsirduke 11y ago
  As for hyperlinks between apps, you mean something like http://applinks.org/ http://applinks.org/
- MadcapJake 11y ago
  The thing is, people create software to advance a purpose/goal or (perhaps more often) to make money. The web is the most accessible/available platform for either. That is why so many non-web-like technologies/paradigms end up on the web (flash, SPAs, huge client-side frameworks). 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.
mobiuscog 11y ago
This is why URLs exist. They have a protocol. You use the protocol to match the application.
- JadeNB 11y ago
  I have long had in the back of my head the admonitory slogan "URL's and URI's aren't the same thing", but had never bothered to learn why. Your last sentence finally clarified it for me; thanks!
z3t4 11y ago
What the "browser" is trying to solve: Reading word document, Reading PDF, Playing Flash, Reading news-feed, Database search. 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.
mbrock 11y ago
Personally, I don't enjoy using web browsers much, either for "documents" or apps. There's a lot of good stuff out there made with hard work by talented people, but when it comes to my own personal computing, I would much rather use other kinds of interaction. 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.
- pjc50 11y ago
  The browser is what it is because it's the camel designed by global committee. It's the place where competing interest groups fight one another to a standstill on a daily basis. Quite a lot of the stranger aspects aren't so much "features" as blast craters of past disasters. 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.
onion2k 11y ago
The user opens a URL that downloads an 'app' and all it's dependencies. So, to start with, you'd have dozens of UI frameworks, network libraries, parsers, etc on your system. Some of them would be great, others would be terrible. Slowly, as the best ones bubble up to the top and become 'standards', each of dependencies would disappear. Developers would settle on one of a few different engines and frameworks. Apps would be the content, a few scripts to drive the engine, and a manifest to tell the user's computer which standard engine to download. Which would essentially be the modern web as it is now.
- anon4 11y ago
  Sometimes I dream of an alternate future where SUN weren't asshats and Java won and we're all running applications that come with maven POMs. Then I remember how badly the average web developer can bungle simple static HTML and realise how happy I am I don't have to debug spaghetti XML.
  - anentropic 11y ago
    yes, sounds like hell
- ajankovic 11y ago
  As soon as the author started explaining problems about browsers I started thinking about solutions. And I realised that "we" already tried to solve this problem with plugins. Flash, Java applets, Silverlight, etc. were all envisioned as solutions to these problems. And it doesn't take too much brain to realise they all failed (at least in the popularity contest). 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.
- rimantas 11y ago
  modern web is nothing like that.
- barnacs 11y ago
  What you describe would be some kind of a natural selection among lower level abstractions. Maybe they would indeed converge into a "few standard engines", maybe not. Either way, they wouldn't force your hands: you could always use whatever UI framework or network library you want and still distribute your app as a simple URI. 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.
edwinjm 11y ago
1) Almost every application uses technology that's build on older technology that's build on older technology. That's not necessarily a bad thing. 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?
- bnegreve 11y ago
  > 2) Nobody says browsers want to replace all applications. It's a false condition the whole article is based on. Many people have been saying exactly this. E.g. http://blog.codinghorror.com/all-programming-is-web-programming/ http://blog.codinghorror.com/all-programming-is-web-programm...
pdkl95 11y ago
The web browser is not the shell[1] or window manager, and it never will be. It may render GUI widgets just fine, and you could use it as a shell, but only because you can technically use any program[2] as a shell. 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 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
amelius 11y ago
The problem in my opinion is that the browser is addressing too many layers of abstraction at once. This makes it very difficult to get the specs right, security becomes immensely difficult to get right, and it becomes almost impossible to implement a browser (bad for competition).
TuringTest 11y ago
Do we need Swiss Army knives? For every tool that's included in the knife, you can get a much better stand-alone version that performs the same task much more efficiently. 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?
- mbrock 11y ago
  The Swiss Army knives are of course known to be simple, beautiful, time- and battle-tested, coherent, reliable, etc. There may be better multi-purpose tools, but the ideal of the Swiss Army knife sets a high bar. Compare that to the browser... You can't bring a browser with you to the woods unless you have really good 3G. No single human can even understand everything a browser does. Browsers are huge, unwieldy, and change constantly. Army knives, like Zippo lighters, pride themselves on having near-Platonic designs that haven't changed in a hundred years. An intelligent extraterrestrial could grok them. A more appropriate metaphor for the browser is a tarpit, as in "Turing tarpit."
  - TuringTest 11y ago
    I'd like to know how the first Swiss knives looked like... 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.
    - lagadu 11y ago
      > I'd like to know how the first Swiss knives looked like... 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:Wester_%26_Co_2.JPG https://en.wikipedia.org/wiki/Swiss_Army_knife#/media/File:W...
vilmosi 11y ago
Ugh, not one of "these" articles again. Sorry to be blunt, but the web has evolved beyond "just deliver some static text". Get used to it already, it's been decades!
- qu4z-2 11y ago
  Ugh, not one of "these" comments again. Sorry to be blunt, but people are gonna keep thinking the modern web sucks. Get used to it already, it's been decades!
  - vilmosi 11y ago
    >>> people are gonna keep thinking the modern web sucks 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?
    - qu4z-2 11y ago
      Hm. 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.
geon 11y ago
I envision a switchable client, specified by a URI in the response headers. The client would be a platform independent bytecode of some sort, like the NaCl. 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.
zlnimda 11y ago
Thanks, someone who says why web is going too far from its original purpose. The major problem with web is : We use framework to abstract differences between browser which abstract web for different Operating system, which abstract hardwares.
- pjmlp 11y ago
  I keep repeating it, even though I do have lots of experience in web development, but I also do have even more experience developing native applications and came to realize the same thing. Nowadays, when given a choice I always pick native projects over web ones. But these type of statements usually earn downvotes in HN.
anentropic 11y ago
you only have to look at iTunes to see why this is a bad idea
AshleysBrain 11y ago
Facebook is arguably a sophisticated real-time communications and social networking app. Imagine if Facebook launched a desktop app to do that. Who would use it? Would they ever have become as successful as they are today? My reading is the author seems to think something like Facebook is entirely unsuitable for the web and contrary to what it was designed for, but I think it excels in a browser because of, not in sprite of, the strengths of the web: cross-platform, URLs, connectivity, low barrier of entry, and so on. 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+).
- mbrock 11y ago
  Lots of people used Napster, DC++, email, Usenet, Kazaa, IRC, ICQ, MSN, AIM, RSS, SMS, all kinds of stuff. There are lots of possibilities. Facebook's success is interesting but it's totally possible that something similar could have happened with another protocol than HTML over HTTP, no? Either way, Facebook is basically a commercial success involving network effects, vendor lock-in, good marketing, timing, etc; it's not a technical breakthrough at all.
  - dump100 11y ago
    More recent example is Whatsapp, it is app only and is wildly successful
- inDigiNeous 11y ago
  The mobile version of Facebook is crap. At least on android. Locks up and jams the machine running it, the one running inside a browser is much better. This on a performant NVidia Shield tablet, so hardware is not an issue.
DanielBMarkham 11y ago
We do not need browsers, but for different reasons than the author uses. 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.
- JadeNB 11y ago
  > I wouldn't want or need ads, user-tracking, or any of the rest of it. 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!)
systemz 11y ago
I can't agree with article. 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.
- rimantas 11y ago
  Web app still downloads the same 20MB of crap and leaves it somewhere in the cache.
annnnd 11y ago
I think OP is missing the point. Browsers of today are taking over the space which Java tried to capture (remember "write once run everywhere" slogan?) but failed. They provide (mostly) unified development platform. But the catch is that unification comes as a direct result of the fact that they are meant to be something else. Any other unified platform faces an uphill battle while browsers are... just there. Are they perfect as a development platform? Hell no. But in absence of every other option, well... we take what we can get.
mobinni 11y ago
My question is which shift do you follow then, the app bubble is there and it's about to burst. Web is trying to build once deploy everywhere. It may not be ideal, but xamarin and other technologies don't offer an easier solution. 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
pjmlp 11y ago
No we don't, network protocols are what matters. I like to have my email client, my native RSS reader, still jump to newsgroups occasionally, use my desktop chatting applications...
- EvanAnderson 11y ago
  I often have mental flights of fancy when I wonder what the world would have been like if end-to-end had been preserved and IPv4 NAT hadn't arisen to put a stranglehold on protocol development. Twitter, Facebook, eBay, et. al. should be protocols, not freestanding businesses. It's much harder to "monetize" a protocol. That's a feature, not a bug.
ytdht 11y ago
that's an easy question... yes and no. You need them because many things are not available without one and you don't need them because anything can be done without one if the proper native applications exist... but that doesn't mean that these apps should or should not be built... If the web would be served in a more structured way, we could have both. It's a pretty mess right now.
ytdht 11y ago
HTML6, the structured web that can be consumed any way you like.
lurkinggrue 11y ago
Yes.

122 points by barnacs 11y ago

Regardless of what he's said its nice to read a webpage that for once didn't take 5 seconds to load, didn't clobber my screen with unnessecary junk or have jerky scrolling.

qznc 11y ago
I would have appreciated a sensible max-width on my fullscreen desktop browser.
- w__m 11y ago
  On the other side, You can have your own stylesheet, without even a single !important ;)
- pantulis 11y ago
  Safari's Reader View for the rescue ;)
  - vilmosi 11y ago
    Which kind of defeats the purpose of the original article.
    - aliem 11y ago
      I think it does the opposite, The author wanted to send a structured document without presentation, with your tool of liking (I used Firefox's reader view) you can read comfortably without compromising the content of the article or it's features. edit: I could have used curl, an html processor and a pager like less or more
      - vilmosi 11y ago
        I'm pretty sure the author is against using special tools to read static text. That's his whole point, that people don't need browsers/readers or any fancy app to read static text!
- userbinator 11y ago
  Why not resize the window to your preferred width? max-width would just waste most of the screen with whitespace, while a smaller window will let you put it where you want and work with other things in the rest of the space. 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.
  - mc808 11y ago
    I almost always maximize windows unless I'm doing something where I need to mentally integrate multiple applications. I'm certainly not going to fuck around with popping tabs out into individual windows and resizing them when casually consuming content. Either it's legible or I move on.
- the8472 11y ago
  I dislike max-widths. It wastes screen real-estate.
  - geon 11y ago
    100% of the window is wasted if the lines are too long to read.
  - lojack 11y ago
    So, books, magazines, and virtually every form of print should have margins, but the web should have the text go right up to the edge of the browser? 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.
    - rootlocus 11y ago
      I just realized that the comment section of hackernews uses ~80% of the window width, with hardly any padding for top level comments.
- lmm 11y ago
  I wouldn't. I like the page wide. I like that by not setting a max-width, I can have my browser at whatever width works for me. This is how the web was supposed to work.
- onion2k 11y ago
  You have one. It's called "the size of the browser window". If you don't want a site to be the size of your monitor, don't use a full screen window.
  - pdkl95 11y ago
    This is how I use the browser - 1920px is way too wide for reading, and I like my browser windows in portrait mode for more vertical space anyway. Unfortunately, yet another idiotic "feature" of javascript (and CSS media queries) allow the webpage access to the actual monitor resolution. Some particularly idiotic sites use this, causing utterly unreadable pages (i.e. all "sidebar" and margin) if you have your your window at something like 900px wide instead of the 1920px they are detecting. This is mostly the websites fault, of course. It's the same forced-layout mentality that has always caused problems on the web.
    - A_Beer_Clinked 11y ago
      as a remedy I have one of my monitors rotated 90° into portrait orientation. I can just drag the offending tab across and have a screen width of 1200px. There are a (very) few sites though that seem to cache the original screen width and need a hard refresh.
- mattlutze 11y ago
  Agreed... well-circulated research demonstrates maximum comfortable line widths for various mediums. 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.

mixmastamyk 11y ago

I've been thinking the same thing for years. There were a few attempts at parts of the problem like java, XUL, or XForms, etc but they didn't break out. 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.

CmonDev 11y ago
WebAssembly is the latest hope.
- idonthaveaname 11y ago
  WebAssembly is only going to make the situation worse.
tritium 11y ago
open, remote updatable, sandboxed, cross-platform, app platform The problem isn't that we haven't faithfully accomplished all of those ideals set forth. The problem is that there were much too few, sophisticated enough to appreciate what was placed before them. 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?

Boldewyn 11y ago

Well, we have a scenario rather close to the one described in the article on mobile: Browsers for text content and apps for specialized stuff, that can incorporate web views, if needed, and access the net. (Yes, I’ve read the second-to-last sentence.) In a nutshell, it sucks. 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 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.

black_knight 11y ago

Off on a tangent here. He mentions he wants a tool which takes uris and figures out the correct program to handle it. This sounds a lot like plumber [1] from Plan 9. Plumber has a powerful, configurable method of finding the right tool to handle a string, and other programs can make it aware of the context the string should be interpreted in. [1] http://doc.cat-v.org/plan_9/4th_edition/papers/plumb http://doc.cat-v.org/plan_9/4th_edition/papers/plumb

ReaperOfCode 11y ago
Sounds to me like things already work on mobile OS-es e.g. on android tapping a youtube linke can take you to the app to view instead of in the browser. Perhaps you could have the same kind of function on desktop OS-es shouldn't be too hard , all the apps just need to understand URLs. Could even go further than a lookup table for certain domains, and have different protocols etc.
- black_knight 11y ago
  Taking Android as a example here. The way this works is by basically letting apps declare that they are interested in certain URLs, and then present the URL-clicking user a list of applications that are interested to choose from. This quickly becomes annoying and checking the "Remember" button is something you quickly regret when you change your preference. This simply will not be practical on a desktop where you might use a hundred different programs. There is also the inherent limitation that you only send the URL to one program. 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.
  - ilaksh 11y ago
    Upcoming Android has deep links/defaults.
- 1wd 11y ago
  Doesn't Windows already have that? Go to ''Control Panel'', ''Default Programs'', ''Associate a file or protocol with a specific program''. For example FTP, HTTP, HTTPS get associated with Firefox, MAILTO with Thunderbird, URL:PowerPoint with PowerPoint etc.

CmonDev 11y ago

Yes, we do - for hypertext documents - as per original design. Retrofitted JavaScript - we don't.

lmm 11y ago

Sadly there's no way to get to there from here. Something like Java Web Start was and remains a much nicer application platform than a web browser. But every device has a web browser, and manufacturers fall over themselves to add support for the latest "web" functionality. 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.

z1mm32m4n 11y ago

The article mentions that "web browsers have become resource hungry beasts with millions of lines of code," suggesting that much of this cruft has been the result of having to support backwards-compatible standards for the web. 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.

fridek 11y ago
From what I've heard Microsoft Edge looks like such attempt. When a site requires some kind of compatibility mode, the not-so-good-but-indeed-old IE is spawned to serve it. Great approach and I hope they set the bar high to make the common use case faster. My ideal browser would support only something like "use strong" from [1] and spawn Netscape 4.0 for all pages that abuse JS. [1] https://developers.google.com/v8/experiments https://developers.google.com/v8/experiments
gunn 11y ago
I've been thinking about something like this for a while - a standard for an easily optimised subset of html technologies. To conform to this standard, pages would be restricted in the ways they can manipulate the DOM, have a simpler DOM, use only a small fraction of CSS properties, and not use some JS features e.g. eval, delete. 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.

test1235 11y ago

According to my company firewall, this site has been blocked for malware ... ?

fkooman 11y ago
Proving (part of) the point of the article ;)

ilaksh 11y ago

Web assembly. Android deep linking. 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.

qznc 11y ago
> nice to have fast document-only thing separate from apps 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.
JadeNB 11y ago
> It might be cool if we could take apart the browser monolith and have something more like components somehow. On the other hand, imagine the developer test-coverage nightmares that would produce!

aikah 11y ago

hyperlinks are successful. if "native apps" had a standard way to handle links between apps then we wouldn't need browsers. if "native apps" would run automatically in a secure and sandboxed environment without requiring any installation then we wouldn't need native apps. We can argue about webtechs but there is no alternative to browsers and the 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).

mrsirduke 11y ago
As for hyperlinks between apps, you mean something like http://applinks.org/ http://applinks.org/
MadcapJake 11y ago
The thing is, people create software to advance a purpose/goal or (perhaps more often) to make money. The web is the most accessible/available platform for either. That is why so many non-web-like technologies/paradigms end up on the web (flash, SPAs, huge client-side frameworks). 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.

mobiuscog 11y ago

This is why URLs exist. They have a protocol. You use the protocol to match the application.

JadeNB 11y ago
I have long had in the back of my head the admonitory slogan "URL's and URI's aren't the same thing", but had never bothered to learn why. Your last sentence finally clarified it for me; thanks!

z3t4 11y ago

What the "browser" is trying to solve: Reading word document, Reading PDF, Playing Flash, Reading news-feed, Database search. 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.

mbrock 11y ago

Personally, I don't enjoy using web browsers much, either for "documents" or apps. There's a lot of good stuff out there made with hard work by talented people, but when it comes to my own personal computing, I would much rather use other kinds of interaction. 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.

pjc50 11y ago
The browser is what it is because it's the camel designed by global committee. It's the place where competing interest groups fight one another to a standstill on a daily basis. Quite a lot of the stranger aspects aren't so much "features" as blast craters of past disasters. 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.

onion2k 11y ago

The user opens a URL that downloads an 'app' and all it's dependencies. So, to start with, you'd have dozens of UI frameworks, network libraries, parsers, etc on your system. Some of them would be great, others would be terrible. Slowly, as the best ones bubble up to the top and become 'standards', each of dependencies would disappear. Developers would settle on one of a few different engines and frameworks. Apps would be the content, a few scripts to drive the engine, and a manifest to tell the user's computer which standard engine to download. Which would essentially be the modern web as it is now.

anon4 11y ago
Sometimes I dream of an alternate future where SUN weren't asshats and Java won and we're all running applications that come with maven POMs. Then I remember how badly the average web developer can bungle simple static HTML and realise how happy I am I don't have to debug spaghetti XML.
- anentropic 11y ago
  yes, sounds like hell
ajankovic 11y ago
As soon as the author started explaining problems about browsers I started thinking about solutions. And I realised that "we" already tried to solve this problem with plugins. Flash, Java applets, Silverlight, etc. were all envisioned as solutions to these problems. And it doesn't take too much brain to realise they all failed (at least in the popularity contest). 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.
rimantas 11y ago
modern web is nothing like that.
barnacs 11y ago
What you describe would be some kind of a natural selection among lower level abstractions. Maybe they would indeed converge into a "few standard engines", maybe not. Either way, they wouldn't force your hands: you could always use whatever UI framework or network library you want and still distribute your app as a simple URI. 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.

edwinjm 11y ago

1) Almost every application uses technology that's build on older technology that's build on older technology. That's not necessarily a bad thing. 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?

bnegreve 11y ago
> 2) Nobody says browsers want to replace all applications. It's a false condition the whole article is based on. Many people have been saying exactly this. E.g. http://blog.codinghorror.com/all-programming-is-web-programming/ http://blog.codinghorror.com/all-programming-is-web-programm...

pdkl95 11y ago

The web browser is not the shell[1] or window manager, and it never will be. It may render GUI widgets just fine, and you could use it as a shell, but only because you can technically use any program[2] as a shell. 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 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

amelius 11y ago

The problem in my opinion is that the browser is addressing too many layers of abstraction at once. This makes it very difficult to get the specs right, security becomes immensely difficult to get right, and it becomes almost impossible to implement a browser (bad for competition).

TuringTest 11y ago

Do we need Swiss Army knives? For every tool that's included in the knife, you can get a much better stand-alone version that performs the same task much more efficiently. 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?

mbrock 11y ago
The Swiss Army knives are of course known to be simple, beautiful, time- and battle-tested, coherent, reliable, etc. There may be better multi-purpose tools, but the ideal of the Swiss Army knife sets a high bar. Compare that to the browser... You can't bring a browser with you to the woods unless you have really good 3G. No single human can even understand everything a browser does. Browsers are huge, unwieldy, and change constantly. Army knives, like Zippo lighters, pride themselves on having near-Platonic designs that haven't changed in a hundred years. An intelligent extraterrestrial could grok them. A more appropriate metaphor for the browser is a tarpit, as in "Turing tarpit."
- TuringTest 11y ago
  I'd like to know how the first Swiss knives looked like... 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.
  - lagadu 11y ago
    > I'd like to know how the first Swiss knives looked like... 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:Wester_%26_Co_2.JPG https://en.wikipedia.org/wiki/Swiss_Army_knife#/media/File:W...

vilmosi 11y ago

Ugh, not one of "these" articles again. Sorry to be blunt, but the web has evolved beyond "just deliver some static text". Get used to it already, it's been decades!

qu4z-2 11y ago
Ugh, not one of "these" comments again. Sorry to be blunt, but people are gonna keep thinking the modern web sucks. Get used to it already, it's been decades!
- vilmosi 11y ago
  >>> people are gonna keep thinking the modern web sucks 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?
  - qu4z-2 11y ago
    Hm. 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.

geon 11y ago

I envision a switchable client, specified by a URI in the response headers. The client would be a platform independent bytecode of some sort, like the NaCl. 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.

zlnimda 11y ago

Thanks, someone who says why web is going too far from its original purpose. The major problem with web is : We use framework to abstract differences between browser which abstract web for different Operating system, which abstract hardwares.

pjmlp 11y ago
I keep repeating it, even though I do have lots of experience in web development, but I also do have even more experience developing native applications and came to realize the same thing. Nowadays, when given a choice I always pick native projects over web ones. But these type of statements usually earn downvotes in HN.

anentropic 11y ago

you only have to look at iTunes to see why this is a bad idea

AshleysBrain 11y ago

Facebook is arguably a sophisticated real-time communications and social networking app. Imagine if Facebook launched a desktop app to do that. Who would use it? Would they ever have become as successful as they are today? My reading is the author seems to think something like Facebook is entirely unsuitable for the web and contrary to what it was designed for, but I think it excels in a browser because of, not in sprite of, the strengths of the web: cross-platform, URLs, connectivity, low barrier of entry, and so on. 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+).

mbrock 11y ago
Lots of people used Napster, DC++, email, Usenet, Kazaa, IRC, ICQ, MSN, AIM, RSS, SMS, all kinds of stuff. There are lots of possibilities. Facebook's success is interesting but it's totally possible that something similar could have happened with another protocol than HTML over HTTP, no? Either way, Facebook is basically a commercial success involving network effects, vendor lock-in, good marketing, timing, etc; it's not a technical breakthrough at all.
- dump100 11y ago
  More recent example is Whatsapp, it is app only and is wildly successful
inDigiNeous 11y ago
The mobile version of Facebook is crap. At least on android. Locks up and jams the machine running it, the one running inside a browser is much better. This on a performant NVidia Shield tablet, so hardware is not an issue.

DanielBMarkham 11y ago

We do not need browsers, but for different reasons than the author uses. 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.

JadeNB 11y ago
> I wouldn't want or need ads, user-tracking, or any of the rest of it. 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!)

systemz 11y ago

I can't agree with article. 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.

rimantas 11y ago
Web app still downloads the same 20MB of crap and leaves it somewhere in the cache.

annnnd 11y ago

I think OP is missing the point. Browsers of today are taking over the space which Java tried to capture (remember "write once run everywhere" slogan?) but failed. They provide (mostly) unified development platform. But the catch is that unification comes as a direct result of the fact that they are meant to be something else. Any other unified platform faces an uphill battle while browsers are... just there. Are they perfect as a development platform? Hell no. But in absence of every other option, well... we take what we can get.

mobinni 11y ago

My question is which shift do you follow then, the app bubble is there and it's about to burst. Web is trying to build once deploy everywhere. It may not be ideal, but xamarin and other technologies don't offer an easier solution. 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

pjmlp 11y ago

No we don't, network protocols are what matters. I like to have my email client, my native RSS reader, still jump to newsgroups occasionally, use my desktop chatting applications...

EvanAnderson 11y ago
I often have mental flights of fancy when I wonder what the world would have been like if end-to-end had been preserved and IPv4 NAT hadn't arisen to put a stranglehold on protocol development. Twitter, Facebook, eBay, et. al. should be protocols, not freestanding businesses. It's much harder to "monetize" a protocol. That's a feature, not a bug.

ytdht 11y ago

that's an easy question... yes and no. You need them because many things are not available without one and you don't need them because anything can be done without one if the proper native applications exist... but that doesn't mean that these apps should or should not be built... If the web would be served in a more structured way, we could have both. It's a pretty mess right now.

ytdht 11y ago

HTML6, the structured web that can be consumed any way you like.

lurkinggrue 11y ago

Yes.