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).
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.
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.
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.
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.
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.
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.
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.
My theory is that many Electron apps don't really need Electron - they just need secure, constrained local file system access.
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.
If would be interesting if you could allow a site to "open as application" (instead of open in new tab) - or this could even be called "install". The site would then appear in your OS like any other app, and may or may not have some of the browser chrome (URL bar, tabs, navigation buttons) depending on the site.
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.
Sounds like you’re describing the Progressive Web App (PWA) install that Chrome recently added. Coming to Firefox (if not there already), and Edge. Not holding my breath for Safari though.
Mobile Safari supports PWAs and quite a bit of infra like service workers. Last time I looked it didn't work well in the background (reloads page on resume) but seems like they have most of the building blocks.
EDIT: This post [1] 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.
You can do something similar in chromium/chrome by using the `app` flag. I set jupyterlab to launch with
chromium --disable-extensions --app=%s
which hides the URL bar and tabs, as well as disables any extensions. I'm sure it's possible to create a shortcut on Windows that does the same thing and place it on the desktop or what have you.
Not sure what's your point but I would prefer my Electron apps to run with Firefox's engine if possible since it's the browser I mainly use, it would use much less memory.
It would be slower and that's all that matter.
Ram is dynamically allocated and chrome has arguably better caching.
Ram usage has only one user facing drawback, it's when it affect negatively performance.
Chrome then outweight Firefox on your own criterion, by one indirection.
Anyway Firefox lack many features useful for "electron apps" and this new file system acesss will add to the list
> It would be slower and that's all that matter. Ram is dynamically allocated and chrome has arguably better caching
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.
I’m not sure about how to think about the file system API. On one hand, is great to see that secure file system access is possible in-browser, which allows most electron apps be converted into PWAs. That’s great, I no longer need to run 5 different chromium instances.
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.
The "coherence and familiarity" argument for native apps is only half the story though. Cross-platform coherence and familiarity is also important. 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.
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 "coherence and familiarity" argument for native apps is only half the story though.
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.
I can confidently say that people doesn’t expect the same UI between mobile & desktop apps.
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?
No one has suggested that people "expect the same UI between mobile & desktop apps".
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.
I've gotten into similar arguments about button order and whether or not the primary action one should be first or last which is inconsistent between operating systems. Everyone's opinion matches their OS.
That’s great, I no longer need to run 5 different chromium instances
That's already possible with Carlo, and electron has a prototype for fixing this limitation.
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.
I read the link you referenced. Am not clear on how seeming it action will mitigate the vector. Saving msi inf sys com files tick, save in locations people have open in explorer/finder tick.
The mitigations appear around overriding Files in user and system directories and revoking access.
It’s not really possible to know which are executable files. The solution is to add the attribute that says the file was downloaded so it doesn’t run automatically.
The linked article about defining typed CSS properties using a mix of script and style tags seems perplexity complicated to me: https://web.dev/css-props-and-vals/
Was this intended to be tied to some other feature or framework not mentioned?
What are you complaining about exactly? That a standard was authored by someone who works on a browser? Would you prefer if standards were worked on by people with no browser development experience?
Here's the draft of the accessibility API [1]. 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?
> Would you prefer if standards were worked on by people with no browser development experience?
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.
I find it interesting how the solution to the OTP SMS problem is to provide the SMS Receiver API. I think the iOS keyboard OTP suggestion is the right way to do that. An SMS Receiver API, even if secure, just seems like a backwards way to solve this problem.
Well electron already allow you to use arbitrary language and acesss almost any native OS api.
So electron is the salvation for hybrid_native desktop development.
Your question would better be:
Is there a salvation for native and cross platform GUI frameworks other than chromium ?
The answer is probably no as chromium beat everything both feature wise, library wise and (yes) performance wise.
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)
We're uneasy enough with Google effectively turning the WWW into a platform under their control with them running Search, Chrome and Android - but this sounds as if the platform might actually extend to "any application with a GUI". (With Apple being the one competitor)
I can’t take this answer seriously. Assuming half of what you claim were true, it would still be terrible for us to cede control of the future to Google. Of course the grim reality is that none of your claims are even remotely true.
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.
Your only point seems to be:
Chromium == Google
Google == evil
Therefore chromium == evil
Firstly chromium implementations détails decisions are just good engeener decisions
Features they intent to implement are just features devs want and or that solve a real limitation.
I defy you to name a few chromium features that made the web worse.
But more than anything, chromium is open source that you like it or not and Google is no longer the only major player I. Chromium since microsoft joined it.
Nothing stop mozilla and Apple to join chromium too.
If there's something you don't like about chromium (and indeed I can sociologicaly infer that it would be something privacy related and not something engeenering related (which is what we should mostly talk but that's not something hackernews understand much).
For such thing nothing stop you from using one of the many privacy focused chromium forks.
I really don't understand this line of reasoning unless you're shilling for Google.
"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?
Native file system access, That is what I wanted and waited the most for. Now It is possible to create an App alike webapp which needs just one prerequisite of selecting a folder on the start.
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).