Live data from Hacker News

Chrome 78 Beta: a new Houdini API, native file system access and more

blog.chromium.org

21–30 of 80 posts

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#21
post #4

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. It's a hugely important new fe…

A lot of them just need to be on the taskbar/notification area and not in a browser tab, honestly.

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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#22
post #21
post #4

Earlier quoted context omitted.

A lot of them just need to be on the taskbar/notification area and not in a browser tab, honestly.

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…

Chrome has/had this. It's called Chrome Apps[1]. But they deprecated them[2]

[1] https://developer.chrome.com/apps/about_apps

[2] https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#23
post #16

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…

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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#24

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 ha…

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 o…

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

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#25
post #16

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…

> 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: ``" rel="nofollow">https://cdn.ampproject.org/v0.js">`

2. It contains amp within: ``

3. It must contain: ``, has a ``, a `` and specify ``.

4. Contains a reactive viewport meta: ``

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

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

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#26
post #21
post #4

Earlier quoted context omitted.

A lot of them just need to be on the taskbar/notification area and not in a browser tab, honestly.

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…

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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#27
post #16

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…

> 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: ` `" rel="nofollow">https://cdn.ampproject.org/v0.js"> ` 2. It contains amp within: ` ` 3. It must contain: ` `, has a ` `, a ` ` and specify ` `. 4…

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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#28

Earlier quoted context omitted.

> 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: ` `" rel="nofollow">https://cdn.ampproject.org/v0.js"> ` 2. It contains amp within: ` ` 3. It must contain: ` `, has a ` `, a ` ` and specify ` `. 4…

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.

Re: Chrome 78 Beta: a new Houdini API, native file system access and more

#29

Earlier quoted context omitted.

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?
Post reply on HN