Hacker News Reader

Comment by yathern | Hacker News Reader

Very interesting. If I understand correctly - this essentially solves the problem of each Electron application having to package the entirety of chromium with it.

However it comes at the cost of assuming the user already has chrome installed - as well as a more separate model between browser (UX) code and application logic.

I see this as being extremely useful for community tools that currently run on Electron (like iNav https://github.com/iNavFlight/inav/wiki). I'm hesitant to think it will be very viable for commercial products - but my instincts are wrong most of the time.

Ideally carlo would also be able to create a build target that bundles chromium with it, so that there is support for users without Chrome - and carlo will act more like Electron in that case.

View on HN

I think the problem with bundling chromium is that it wouldn't be evergreen, which means it doesn't have the latest security fixes, etc .

On the other hand you have more control over your app. The app will work and look as the author intended.

Many[citation needed] electron-ish apps are also available over the internet (vis: slack, atom, vscode, discord being examples I've personally used).

In the case where your software development practices require static bindings to exact versions, you're correct, but your app is participating in the "IoT anti-pattern" of deploying baked code which may or may not be updated based on the long-term viability of your company / product.

I think this offers a great leap forward in transparently keeping local software up-to-date. Your argument boils down to it being better to ship an entire Windows95 VM with your app so you "have control".

In most cases, better to ship your own app and integrate properly with the external operating system / runtime provider (or hide: "Use bundled chrome.exe" as an advanced checkbox).

Ideally it'd be possible to select puppeteer/firefox as the target runtime environment as well.

>I think this offers a great leap forward in transparently keeping local software up-to-date.

Not really. You're forgetting that there is also nodejs runtime bundled with your app. And it needs to be updated too.

You could install that and node_modules system-wide ...

... are we re-inventing shared libraries?

Yes, was thinking about that. But is that really viable for regular joe?

Sure it can be. Shared libraries are also viable for a "regular joe".

There would just need to be a central manager for dependencies. And yes, I realize that we are on many layers of abstraction.

VSCode and Atom are available over the internet? I've seen online cloud-IDEs based on some of the work in them (Cloud9) but wasn't aware the vanilla versions could run in the browser.

It's not standalone and I don't know the details, but codesandbox.io can run what is recognizably VSCode.

Yes. At least, VSCode is using monaco-editor: https://microsoft.github.io/monaco-editor/

That's not the same thing

Stackblitz and CodeSandbox both run VSCode in the browser afaik

While I am not a fan of Electron, the problem with using the system-wide install of Chrome is that while Chrome and your online web-app are both updated, the installed app might not be. So then the installed app could break in the future when Chrome is updated.

>On the other hand you have more control over your app. The app will work and look as the author intended.

Sure, but it's just the age old argument of static vs dynamic linking. General opinion has settled firmly on the side of dynamic evergreen dependency management for software on the web because exploits are so common and fast moving.

You'd still potentially have the out-of-date problem with Node though, which is arguably an easier attack vector since Chromium is sandboxed and Node has user-level privileges by default.

Also IE, Firefox and Opera can run "chromeless" - so this, or a similar API (using websockets), can work in other browsers too.

Reply on news.ycombinator.com