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

61–70 of 80 posts

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

#61

Post by The_rationalist »

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…

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.

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

#62

Post by The_rationalist »

mika9090 wrote: post #46

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

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)

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

#63

Post by realusername »

The_rationalist wrote: post #60
realusername wrote: post #51

Earlier quoted context omitted.

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.

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

#64

Post by jasonvorhe »

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…

I don't get the argument here. Hasn't Google Docs proven that this works so much that even Microsoft is now copying it?

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

#66

Post by dmitriid »

acqq wrote: post #54
dmitriid wrote: post #43

Earlier quoted context omitted.

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 .

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

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

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

#67

Post by rubbingalcohol »

nindalf wrote: post #55
userbinator wrote: post #34

Earlier quoted context omitted.

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.

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…

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.

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

#68

Post by xg15 »

The_rationalist wrote: post #62
mika9090 wrote: post #46

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

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…

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 see how this is good.

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

#69

Post by xg15 »

nindalf wrote: post #55
userbinator wrote: post #34

Earlier quoted context omitted.

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.

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…

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

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

#70

Post by armitron »

The_rationalist wrote: post #62
mika9090 wrote: post #46

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

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

Post reply on HN