
Do we need browsers? - barnacs
http://blog.justletit.be/posts/do_we_need_browsers/
======
mbrock
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.

~~~
teknologist
Or, in short, you want everything to run in an emacs interface. The world has
moved on. We have mice now. Sorry. Google implemented keyboard navigation in
their search results and apparently the uptake has not been great.

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.

~~~
mbrock
We had mice for a brief instant of computer history, then came the phones and
tablets and e-readers and watches and TVs and voice interfaces and who knows
what's next?

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?

------
asdfaoeu
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
I would have appreciated a sensible max-width on my fullscreen desktop
browser.

~~~
the8472
I dislike max-widths. It wastes screen real-estate.

~~~
lojack
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
I just realized that the comment section of hackernews uses ~80% of the window
width, with hardly any padding for top level comments.

------
onion2k
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
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
yes, sounds like hell

------
aikah
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).

~~~
MadcapJake
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.

------
black_knight
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
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
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
Upcoming Android has deep links/defaults.

------
DanielBMarkham
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
> 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!)

------
AshleysBrain
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
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
More recent example is Whatsapp, it is app only and is wildly successful

------
mixmastamyk
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
WebAssembly is the latest hope.

~~~
idonthaveaname
WebAssembly is only going to make the situation worse.

------
pjmlp
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
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.

------
amelius
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).

------
lmm
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
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.

~~~
gunn
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.

------
annnnd
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.

------
TuringTest
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
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
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
> 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:W...](https://en.wikipedia.org/wiki/Swiss_Army_knife#/media/File:Wester_%26_Co_2.JPG)

------
geon
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.

------
Boldewyn
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
Surfing on a smart phone is a real pain. Pages take longer to load than in the
90s and contrary to the 90s you can't start reading before it all has loaded.

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.

~~~
JadeNB
> If the language can only express safe actions, the program will not be
> malicious.

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](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.

~~~
black_knight
Rice theorem is not really applicative here. It is a beautiful theorem, but it
has to do with what we can compute, while "safe" has to do with what one can
access.

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.

------
edwinjm
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
> _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-
programm...](http://blog.codinghorror.com/all-programming-is-web-programming/)

------
pdkl95
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

------
zlnimda
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
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.

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

~~~
fkooman
Proving (part of) the point of the article ;)

------
mobiuscog
This is why URLs exist. They have a protocol.

You use the protocol to match the application.

~~~
JadeNB
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
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.

------
mobinni
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

------
systemz
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
Web app still downloads the same 20MB of crap and leaves it somewhere in the
cache.

------
ilaksh
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
> 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.

------
vilmosi
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
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
>>> 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
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.

~~~
vilmosi
>>> Is it so hard to imagine someone could have a different opinion than you?

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.

------
ytdht
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.

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

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

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

------
lurkinggrue
Yes.

