Hacker News Reader

Comment by robocat | Hacker News Reader

Browsers need a bright line between documents (HTML and CSS) and applications (electron-like, notifications, complex APIs, access to features that affect the user's security).

Plain HTML documents are SEO friendly, are a11y friendly almost by default, back/forward navigation works, and HTML doesn't chew battery and bandwidth on JavaScript.

For our web app the biggest pain points are: security (hard to integrate third party libraries), control over the viewport (an app header and footer that don't get lost when zoomed - like an App), control over data entry (the hacks we have to do for fast reliable time and date entry are rediculous, and other stuff is just too hard), and control over navigation (browser back/forward is broken for applications that POST data).

Unfortunately Google don't seem to want to encourage plain HTML documents (instead the insane AMP shit).

View on HN

Browsers need a bright line between documents (HTML and CSS) and applications (electron-like, notifications, complex APIs, access to features that affect the user's security).

Glad that somebody else sees this. This muddling together of a perfectly good hypertext browser and a poor man's operating system is really not a Good Thing.

Just think about the difficulty web "applications" have dealing with something like function keys. If I press F5 in my browser, and I asking the browser to reload the page, or telling the page to do something? And how would I know ahead of time if the page has hijacked a given key combo that I intuitively expect the browser to respond to (ctrl+w maybe).

Whether we separate out the application runtime from the browser altogether and have a handoff mechanism, or add some way for a page to request something like an "application mode" to the browser, it really feels like we need a way to make this "page" vs "application" distinction.

And yes, of course, the line appears a bit fuzzy. I'm not saying figuring out an answer to this is easy, but I hope there are people out there thinking about it.

> And how would I know ahead of time if the page has hijacked a given key combo that I intuitively expect the browser to respond to (ctrl+w maybe).

Or like GMail does with CTRL+. - it doesn't even use it for anything, but it still eats the key sequence, preventing me from interacting with Multi-Account Containers on Firefox. I think I might have even seen sites breaking CTRL+TAB or CTRL+SHIFT+TAB, but can't find an example now.

Web Apps have their place. Native apps are usually better, and this whole "X as a service" thing is trash, but I like Gmail, and I think web is the best IoT interface platform.

The problem is when someone makes an HTML document, but wraps it up as an app for no good reason, without taking care to preserve the nice properties of documents.

As far as I'm concerned, Markdown is the ideal tool for creating just basic documents.

The dev community might just hate it, but I'd love to see some of the stuff traditionally done with a CMS in the browser, so we can just plop markdown files on a server. If you give it a CSS file it uses that, otherwise it uses browser default styling.

It would make it ridiculously easy to "make a website", maybe even easy enough to save the idea of a personal site.

And it would load absolutely insanely fast, even on 2G.

> Unfortunately Google don't seem to want to encourage plain HTML documents (instead the insane AMP shit).

AMP is just plain HTML documents [0]. The only difference between an amp page and a standard HTML page are the following:

1. It includes the amp javascript library: `<script async src="https://cdn.ampproject.org/v0.js"></script>`

2. It contains amp within: `<html amp lang="en">`

3. It must contain: `<!doctype html>`, has a `<body>`, a `<head>` and specify `<meta charset="utf-8">`.

4. Contains a reactive viewport meta: `<meta name="viewport" content="width=device-width,minimum-scale=1">`

I don't think any of these make an amp page "not html".

[0] - https://amp.dev/documentation/guides-and-tutorials/start/cre...

5. It's MITM'd by Google's servers.

---

I don't know if you are being accidentally or purposefully misleading.

No one has a problem with simple HTML. That's never the dispute. People have a problem with Google servers seizing control of the client <-> server relationship.

The MITM happens at an application level. Not from your backend. A client chooses who to get the AMP content from: Google or You. Users who don't want Google's edge caching (MITM) can use software that doesn't talk to Google servers and still benefit from the plane HTML.

Which software would that be?

Any software that provides you a link to content can implement, and also choose not to implement, AMP's edge caching (MITM) support. One might be Google's Android launcher's news app, another might be Telegram's "Instant View" feature for links, or hypothetically even a terminal app could load an AMP page.

Instead of speaking in vague terms about "optional application-level MITM from the backend cache", it might help to illustrate the choice users have with concrete examples.

With real world examples, how can an ordinary choose to use AMP and how can an ordinary user choose not to.

> Instead of speaking in vague terms about "application-level MITM from Google's back end"

I don't consider actual, verifiable, facts vague.

> In real world terms, how can they choose to use AMP and how can they choose not to.

They can use software that doesn't load AMP pages from Google and instead loads them from the host site. You can do this by using DuckDuckGo as a search engine which won't return URLs to Google's cache of AMP content. You can use messaging apps that will open your web browser and navigate to links rather than using the AMP version.

Edit: Here is an example. Assuming you are on a desktop browser you should be able to navigate to this url and see a page: https://preview.amp.dev/documentation/examples/e-commerce/ch...

This is a Google made example of an AMP page. It's pretty bare bones but as you can see if you open up your browser's networking tab the browser is talking to `preview.amp.dev` not to the AMP caching URLs. Your browser is fetching content directly from the site. There is nothing stopping software from doing this with an AMP page.

I meant to say "abstract" not "vague".

1. AMP is not HTML5-compatible beginning with their amp declaration.

2. AMP is a set of web components that rely on JS to properly render.

3. If JS is disabled, page content is hidden by a CSS declaration

4. AMP pages are treated differently by the dominant search player

So yes. On the surface it’s “just plain HTML page”. Technically.

Also, on my iPhone I can never open articles on AMP in the "Reader view", destroying my accessibility needs. The articles that were completely readable in the original form become 100% unreadable as soon as they are AMP. It can still be verified on the publisher’s site that there it works, but how long will that remain?

Long ago, it was seen that Microsoft had the policy "our OS isn't finished if the competior's program is still functioning." Google's “OS” is effectively all the web resources they control and then they "accidentally" miss to support Apple's browsers. Especially when they manage to bring all the news content producers to use their “technology.”

AMP is evil. Behind seemingly “technical” solution is a huge additional monopolisation of the web by Google. Purely seen on that level it should be illegal. It’s in the interest of the society to allow the competition and disable the strengthening of the monopolies.

> and then they "accidentally" miss to support Apple's browsers.

And Firefox. See this thread by Jonathan Nightingale about Google breaking FF on purpose: https://mobile.twitter.com/johnath/status/111687123179245568...

It's an HTML document that is only usable when you execute Google hosted JavaScript to display the custom web components.

> a11y

i18n, l10n, g11n, l12y, a11y... is it r4y so h2d to j2t t2e o1t t1e w3s!? (is it really so hard to just type out the words!?)

I'm not against AMP because it simply has made some websites better but am definitely FOR straightforward (and enriched) plain HTML which would also render quickly and stay pretty light.

I feel like 5-10 HTML element additions would reduce the need for a tremendous amount of javascript overhead.

Reply on news.ycombinator.com