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).
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.
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.
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.
AMP is just plain HTML documents . The only difference between an amp page and a standard HTML page are the following:
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".
 - https://amp.dev/documentation/guides-and-tutorials/start/cre...
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.
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 Firefox. See this thread by Jonathan Nightingale about Google breaking FF on purpose: https://mobile.twitter.com/johnath/status/111687123179245568...
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.
With real world examples, how can an ordinary choose to use AMP and how can an ordinary user choose not to.
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.
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!?)
Electron has massive potential security issues. Chrome with native file system access could make it possible for many of those Electron apps to simply be browser apps, making them vastly more secure and bringing them back into the domain of the ordinary web app.
It's a hugely important new feature.
I currently have many pinned tabs - email, music - where I'd happily promote them to "apps". Even some of the real applications I use I only really use to get this behaviour (Slack comes to mind).
I'm a way, this is sort of similar to how Chrome OS works - just I want it on a real OS, I'm not at the point of being 100% web (or Electron-based) apps, and as a developer, probably never will be.
EDIT: This post  says background switching should be working in iOS 13.
Open the page you want to be an "app", and on the Chrome three-dot menu, select More Tools / Create Shortcut...
Edit the name as you wish and check the "Open as window" checkbox, then click OK.
Now you have a shortcut on your Start menu that works like any other app shortcut. You can pin it to the taskbar, save it to the desktop, any of the usual things. And when you open the app it will have its own window and its own icon on the taskbar.
This works on Windows and Linux at least - have not tried it on macOS.
chromium --disable-extensions --app=%s
I don't want to use chrome, so it's never going to be an option. The best option in a ideal world is the browser the user is using since there's not that much resource needed to open one more tab. Some APIs around that would be ideal.
On the other hand, I’m really not sure if I like the future of editing Microsoft office documents in the browser. I heavily believe that apps should have an integrated UX (with appropriate OS-specific widgets), because it allows coherency and familiarity.
Especially with Microsoft office, which was completely chock full of custom controls and didn't feel at all like part of the OS last time I used a natively installed version (on windows 7)
The user only uses the application in the platforms that one uses; so cross-platform coherence is mostly meaningless.
> And as an app developer, when you have to make a decision regarding whether you should be familiar and coherent to the rest of the operating system or the other installs of your app, that's pretty much always going to land on the "my app" side.
They might be beneficial to the developer; but it definitely isn’t to the user, which ultimately uses the app.
One might argue that the user will use the app for multiple platforms; However the user will ‘know’ the average user experience for both platforms, hence having no problems adapting two different interfaces if the interface is well designed to match each platform.
> Especially with Microsoft office, which was completely chock full of custom controls and didn't feel at all like part of the OS last time I used a natively installed version (on windows 7)
I’m pretty sure Microsoft has opened the ribbon controls for this exact argument. At the very least, the Windows 7 file explorer’s toolbar looks very similar to the Office 2007; so Microsoft is trying to make the operating system more coherent. The introduction of the Notification Center in Windows 10 has a similar purpose; to make lots of different notification system in Windows coherent.
If you want to look what an operating system looks like when the entire ecosystem considers coherence importantly: try using macOS. macOS users take this very seriously to the point that almost every app (that is not election) uses the default cocoa toolkit.
Microsoft office isn’t an exception; they implemented the custom ribbon menu, but other than that it’s mostly plain Cocoa and it doesn’t standout as much as in other platforms.
Most people only use one desktop and one mobile OS, but it's extremely common to use the same app on both desktop and mobile.
If your Mac and Windows apps both have to be consistent with your iOS app, they end up having to be consistent with each other.
If the Mac version and Windows version of the app can be consistent with the mobile version(which will have different interfaces), why can’t they be consistent with each other(between the two desktop apps) while having different interfaces?
The point under discussion is that it's desirable for apps to have "coherence and familiarity" across platforms.
It's important that there be coherence and familiarity between Slack and Spotify's mobile, desktop, and web apps, for example, because most of their customers will use at least 2 of the 3 in any given week, which likely contributed to their choice to use Electron for their desktop apps.
If you look at the various restrictions, you will see that the user is in control of most of the operations. It restricts access to system folders. I do think that many lay people may still fall prey to attack vector sites that may save an evil EXE or something, hoping they will later click it. However, I suspect once we see this feature in action, hopefully it will disallow creating executable files.
The mitigations appear around overriding Files in user and system directories and revoking access.
Was this intended to be tied to some other feature or framework not mentioned?
Marijn Kruisselbrink (Google)
Here's the draft of the accessibility API . The two editors are from Mozilla. Does this mean that the process of defining this API, gathering feedback, iterating and publishing it "means next to nothing" because folks from other organisations didn't chip in?
 - https://wicg.github.io/historical-a11yapi/taxonomy.html
How about someone not on the payroll of browser vendors?
Oh, and maybe manage them in an independent organisation with power to enforce decisions and not in something that looks more like a cartel than a standards body.
Really why native development isn't totally dead yet is because of inertia to learn new technologies and because of shared misconceptions about chromium performance and GUIs framework performance.
This growing gap could have been deduced so many years ago because of a simple fact:
The number of full time employees working at improving chromium vs the number of full time employees working at improving QT, or GTK, etc.
They are order of magnitudes more. And it has deeply increased since microsoft has joined chromium (they have moved a number of employee to chromium probably comparable as if all Gtk + QT devs moved to working on chromium.
Btw, as they both know they can't keep up, they progressively webify (QTwebengine, both use CSS for styling, etc)
I can't see how this is good.
This is a classic case of worse is better amplified by Google being in a position of unprecedented power and abusing it to full effect.
Those of us who were old before Google even existed, can see very clearly where this road is leading. On the other hand this is a battle that has to be fought mainly by the younger generation. Alas, it does not seem that we are winning.
"Nothing stop you from using..."
"Chromium is open source..."
"Nothing stop Mozilla and Apple.."
There is a behemoth in the room that makes all these arguments NULL and VOID. It's called Google and it's ruling its domain with an iron fist. We saw what these sort of arguments lead to in practice, the recent ad-blocking debacle being the icing on the cake. Open source means nothing if you have a colossal gate keeper that is not only in full control but has the power to _dictate future evolution_. All Open Source provides in this case, is an easy excuse, a shield to deflect criticism and this is exactly what you're doing here.
Did we really learn nothing from Microsoft's past that we are willing to overlook an entity that's orders of magnitude more powerful?