Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.chromium.org

Post reply on HN
Print view View original

11–20 of 80 posts

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

#11

Post by dddddaviddddd »

andrewstuart wrote: post #3

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…

Offline mode is important too, but of course you can do this on the web just fine nowadays.

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

#13

Post by pcr910303 »

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.

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

#14

Post by dswalter »

andrewstuart wrote: post #3

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…

Your version only works as long as there is only one browser.

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

#15

Post by apatheticonion »

iso-8859-1 wrote: post #8
p7IDD243 wrote: post #6

The Native File System API sounds like an exploit waiting to be discovered.

I downvoted you because it is a superficial knee-jerk judgement.

I upvoted you because you explained your downvote

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

#16

Post by robocat »

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

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

#17

Post by notatoad »

pcr910303 wrote: post #13

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

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

#19

Post by bluquark »

synt4x1k0 wrote: post #12
p7IDD243 wrote: post #6

The Native File System API sounds like an exploit waiting to be discovered.

https://github.com/WICG/native-file-system/blob/master/EXPLA...

Here is a more up-to-date doc on the security model: https://developers.google.com/web/updates/2019/08/native-fil...

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

#20

Post by mindcrime »

robocat wrote: 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…

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.

Post reply on HN