
Chrome 78 Beta: a new Houdini API, native file system access and more - joeyespo
https://blog.chromium.org/2019/09/chrome-78-beta-new-houdini-api-native.html
======
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).

~~~
gravypod
> _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>`](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...](https://amp.dev/documentation/guides-and-
tutorials/start/create/basic_markup/?format=websites)

~~~
dmitriid
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_.

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

~~~
dmitriid
> 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...](https://mobile.twitter.com/johnath/status/1116871231792455686)

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

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

~~~
bdcravens
How many die-hard Firefoxers run at least one Electron app?

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

~~~
The_rationalist
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

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

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

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

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

~~~
laughinghan
_The user only uses the application in the platforms that one uses_

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.

~~~
pcr910303
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?

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

------
rhacker
For those that are interested in the security around file system access please
go here:

[https://developers.google.com/web/updates/2019/08/native-
fil...](https://developers.google.com/web/updates/2019/08/native-file-
system#security-considerations)

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.

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

------
nitwit005
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/](https://web.dev/css-props-and-vals/)

Was this intended to be tied to some other feature or framework not mentioned?

------
rubbingalcohol
Is the filesystem API based on any web standards process? I'm curious if this
is a Google-only feature.

~~~
iso-8859-1
Yes: [https://github.com/WICG/native-file-
system](https://github.com/WICG/native-file-system)

~~~
userbinator
[https://wicg.github.io/native-file-system/](https://wicg.github.io/native-
file-system/)

    
    
        Editor: 
            Marijn Kruisselbrink (Google)
    

As you may be painfully aware of by now, "web standards process" means next to
nothing if Google gets to decide the standards anyway.

~~~
nindalf
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?

[1] -
[https://wicg.github.io/historical-a11yapi/taxonomy.html](https://wicg.github.io/historical-a11yapi/taxonomy.html)

~~~
rubbingalcohol
Google should not be releasing an implementation before the "very early" spec
is finalized. They aren't acting in good faith with behavior like that.

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

------
mika9090
Serious question: is there a salvation for native desktop development??

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

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

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

~~~
armitron
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?

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

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

~~~
iso-8859-1
I downvoted you because it is a superficial knee-jerk judgement.

~~~
apatheticonion
I upvoted you because you explained your downvote

~~~
codewiz
How does one downvote in HN? I've had an account since 2013 and I can still
only upvote.

~~~
nindalf
You need 500 karma, last I checked.

------
ylum
Rest in peace XSS Auditor

