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.
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.
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.
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.
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.
>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.
This seems like exactly what I as an app developer do NOT want. Basically this is my app that may break every 2 to 6 weeks as the Chrome team changes stuff outside my control. With Electron I ship on a version of Chromium I know my code runs on. With Cario today it works, tomorrow they deprecate an API, push an update to Chrome and my app breaks. I'd prefer to get a new version of Electron behind the scenes so I can fix any things that come up and then later push a new version.
What if a bug in Chrome (layout rendering, dom, ..) breaks your application? It's a corner case, possibly it will never happen. But this solution makes impossible for you to roll out a patch by just changing Chrome version bundled.
User will notice a bug in your application and maybe none of his frequently visited web-apps/web-sites exhibits the same bug, so you won't have the user engaged to update (or downgrade!) his Chrome version.
All in all you're breaking one thumb rule which is to use fixed versions of dependencies for your products, so to be sure they always work as intended. As a side note, how is one going to test a GUI build this way? Should it be tested against all Chrome versions that may be possibly installed at least at one customers premises?
This isn't even as bad as the situation is and has been for web developers for the last 30 years. I can't even think of something that has ever had support dropped in chrome, and if that happened it would be with years and years of advance notice. Why the FUD?
Yep, this happens fairly often - We run on chrome directly so can't control updates, and a recent update made our dialogs invisible (funnily enough, if you clicked in the right spots you could still interact with it and open dropdowns etc). They'd show when you resized the browser window or otherwise forced chrome to re-render it (disabling the animation worked around this).
We also had a case not long ago where a chrome update introduced a bunch of bugs with stylus input on Chromebooks (a mission critical use case for us)- there we just had to tell people to downgrade to 66 or wait for the 68 update, there was no viable workaround.
> What if a bug in Chrome (layout rendering, dom, ..) breaks your application? It's a corner case, possibly it will never happen. But this solution makes impossible for you to roll out a patch by just changing Chrome version bundled.
Did already have this 5-6 versions ago. We had been unable to fix it without changing a lot of ui. 2 Chrome releases later it was fixed again.
It's not different at all, but you might not want to add this "breaking" scenario to any component in your app, or you might accept the risk - up to you.
If you accept the risk for any component to break you'll eventually end-up spending your time fixing something other people broke, offering a poor experience to your end customer.
Mind that in corporate environments getting authorized as a software supplier to deploy an update could take weeks if not months, in the meanwhile the customer perspective is that "your product broke" (and made them lose money) - this is why I like to ship as many dependencies as possible in the final bundle.
This is my opinion, maybe biased by the market sector I'm working in. Not saying it should work the same way for everyone, just my 2c.
Carlo seems to rely heavily on Puppeteer and the DevTools protocol. The DevTools protocol has a history of major breaking changes every couple of Chrome versions, so it is very likely that the app will stop working in a couple of months if it's not kept up to date.
> Basically this is my app that may break every 2 to 6 weeks as the Chrome team changes stuff outside my control.
Welcome to the glorious life of a web developer :). It's not actually that bad (APIs generally don't disappear over night), but the principle is still true.
I'm glad to see Quark picking up where Electrino left off, I'm very interested in those projects. However both of them are not production ready or even close to production. Plus now you're dealing with the same issues you get on web where you're coding for multiple browsers. However, if you're going to be using electron or similar then you're already used to that
As a side note, blurring sensitive information in a screenshot is a bad idea. It's possible to recover what the blurred text was using brute-force guess, blur and compare, or a smarter method.
Pretty cool and interesting idea, and I guess the usability is banking the fact that Chrome is the most popular browser and probably installed on most user's computers.
Idea for another project: a wrapper around the system's bulit-in web-view that automatically polyfills the different engines to somewhat the same capabilities.
> Idea for another project: a wrapper around the system's bulit-in web-view that automatically polyfills the different engines to somewhat the same capabilities.
I feel like PWA standards are so close now. The web platform needs some version of a few Node libraries better standardized (file access, process management, are a couple to mind), and maybe some better cross-platform ideas for FFI/native code-interop/shell calls. Overall, though, PWA capability is ahead of what a lot of people expect.
The biggest hurdle of course remains Apple's support for PWAs is quite lacking.
PWA's idea is that you can check the runtime and given JavaScript dynamism make use of native platform APIs if available.
Microsoft has moved their UWP Hosted Apps into the PWA model, so any signed PWA app can have full access to UWP APIs, with the same FFI capabilities that .NET and C++ enjoy on UWP.
Google does a similar thing with ChromeOS and Android.
Yep, good points. Like I said, I think the issues are more to do with cross-platform compatibility (which admittedly can be done in some cases with wrapper libs that feature detect for the Windows and Android libraries), and arbitrary native libraries, especially ones from the Node ecosystem (which admittedly in some cases can be handled with Web Assembly at least).
There are a few wrappers around system web views in various languages (I've seen Python and Go, at least). The problem is Windows... Apparently only crufty old IE is available as a system default embeddable webview on Windows. Had it been a modern Edge, this would be a viable approach!
With XAML Islands, Edge can now be embedded in Win32 and WinForms/WPF apps. There's an official wrapper control for it that binds a mostly compatible API to the old IE control and you can almost just "drop in" replace any existing uses.
Also, Windows has native HTML/JS application support as a part of the UWP platform, and among the best support for PWA applications on top of that. Apple has been the biggest holdup for PWA adoption.
Oh, cool! If someone can get a scaffolding around the Edge embedding in one of those libraries for Go, etc., that would be a nice cross-platform solution for building HTML-based apps that are much slimmer than Electron ones.
I wonder if Microsoft/Apple are missing an opportunity with this. There is clearly a demand to write apps with JS/HTML/CSS, at the moment they are leaving it to third parties to fill that hole.
Also, Microsoft supports PWAs as native apps, supporting almost all the standards, giving them access to the full UWP host environment as a feature-detection-supported bonus, and even ingesting PWAs directly into the Microsoft Store when found by the Bing crawler.
.NET Framework is preinstalled on Windows. If you don't target a preinstalled version and you don't bundle the runtime for your targeted version with your installer, of course that'd be bad UX. But the issue there lies with the developer, not .NET Framework.
Puppeteer actually installs chrome for you (seems to be a minimal version of chrome), puppeteer-core is the one that uses a chrome installation you provide. I wonder if Carlo would install Chrome for you if it was missing
I'm curious as to whether this could be generalised to any browser if there was a small server that accepted websocket connections and for each one, opened up a listening port on the server side.
If the socket was exposed as an environment variable
WEBSESSION=/tmp/websession_socket.16417
Then applications could connect to the socket at WEBSESSION and feed data to the browser (to display in an iframe).
Mostly I say this because I've made one of these but haven't been using it.
This seems useful for prototyping and quick GUIs. Usually for one-off apps I end up creating a local http server on some port then pop up the browser to view it. Before I know it, I end up serving a few different ports and losing tabs... Being able to pack each script up complete with GUI - without a lot of effort or huge dependencies - seems like it might be convenient.
It probably might be a good idea to make a similar Chrome-based backend for https://github.com/zserge/webview to provide consistent browser engine for all OSes.
Looks like this was an alternate to the chrome apps which they removed from other os-es than ChromeOS
The advantage is size reduction, which is pretty much less of an issue since our disks are only getting bigger. But this will lock in vendors to use Chrome which Electron could provide an alternate.
> But this will lock in vendors to use Chrome which Electron could provide an alternate.
Maybe not. If Firefox's and Chrome's headless communication protocols converge sufficiently, it may become possible for Carlo to support them interchangeably.
At first glance, this looks like it establishes a shared runtime for all Carlo apps. I'll be interested to see how well it supplants Electron once it matures.
If it requires Chrome, why not simply develop a Chrome app?
"A Google Chrome App is a web application that runs on the Google Chrome web browser. Chrome apps can be obtained from the Chrome Web Store where apps, extensions, and themes can be installed or bought."
You can use "add to desktop" which also work on Android and iPhone, it will make the browser (chrome/safari) run "chrome-less" eg. without url bar and menu.
Is the package compressed? The space saving seems minor if so. A "Hello World" with Electron is ~40MB on Windows and ~50MB on Mac when it's compressed into an installer (DMG/EXE installer).
The patent restrictions make Apache 2.0 less permissive (even if you think they're a good thing.) They cause practical problems, even for well-meaning free software developers, because they make the licence incompatible with GPLv2.0, which means, if you use an Apache 2.0 library in your program, you can never use any GPLv2.0 licensed libraries or vice versa.
That's the whole point of it. Not the caveat really, but the primary feature! Whereas Electron will package chrome in every binary, this uses what you already have installed.
Obviously not great for many product types. You wouldn't want to build a product off of this, knowing that a user might not have Chrome. But for internal enterprise stuff, or community-built tooling - I can imagine this is quite useful, and downloading a 3MB binary is a whole lot better than downloading a 300MB for the same program.
I would love to see this work alongside Electron, where you can provide two download buttons for your app. One if a user has chrome already (3MB) and another if they don't (300MB).
Of course the API and model differences between the two would be hard to solve, and require another level of abstraction.
I would like to see electron as system package. Would work similar to Webview in Android (which is updated as normal package and any app can use it). And the best part is, that it can be done (I mean, create such a component with nice installer and auto updater). Just nobody done it and rather keep bundling full electron with every app.
I started a webview project some time ago, and I see some people using it in their projects - https://github.com/zserge/webview Basically, it provides some high-level APi over a native system webview (WebKit or IE, depending on the OS).
I think it's designed to be a more matinable version of Electron, which bundles Chrome with every app that uses it. I have at least 3 or 4 copies of Chromium sitting around on my desktop at home because I use a few Electron apps.
One time, there was some BeagleBone tutorial that recommended using a Windows version of dd that is implemented as an Electron app. It was 200MB. For dd. Not great. At least this uses the Chrome you already have installed.
Yeah. "Real" native apps feel a lot better, and of course ship you a lot less code.
It is hard to justify the development effort for that, though, so this is the compromise. An app these days ideally supports Windows, Linux, MacOS, Android, iPhone, and the web... and that requires a lot of software engineers. Being able to write the bulk of the code once is appealing. But to the end user... they can tell that shortcuts were taken.
looks like it's basically electron but doesnt bundle chrome. and electron is a piece of crap.
edit: one time I downloaded this little mac menu bar applet that did something I wanted. I took a look at the little .js file that actually did stuff and it was about 200 lines or so. but the "application" was about 140 mega bytes. I never deleted something off my computer so fast.
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.