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

71–80 of 80 posts

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

#71

Post by The_rationalist »

armitron wrote: post #70
The_rationalist wrote: post #62

Earlier quoted context omitted.

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

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…

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.

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

#72

Post by armitron »

The_rationalist wrote: post #71
armitron wrote: post #70

Earlier quoted context omitted.

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…

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

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?

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

#74

Post by laughinghan »

pcr910303 wrote: post #48
laughinghan wrote: post #37

Earlier quoted context omitted.

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.

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.

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

#75

Post by zamadatix »

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…

> a11y

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

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

#76

Post by toastal »

notatoad wrote: post #17
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 o…

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.

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

#77

Post by ebcode »

zamadatix wrote: post #75
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…

> a11y 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!?)

y

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

#78

Post by propogandist »

jasonvorhe wrote: post #65
p7IDD243 wrote: post #6

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

We've all heard the same fear mongering when WebGL and access to Bluetooth devices was introduced as a web standard.

what good had come from accessing bluetooth devices, as part of that web standard?

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

#79

Post by tinus_hn »

rhacker wrote: post #40

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... 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, hopin…

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.

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

#80

Post by eternityforest »

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…

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.

Post reply on HN