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.
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.
> 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.
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!
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."
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 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.
[+] [-] yathern|7 years ago|reply
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.
[+] [-] willchen|7 years ago|reply
[+] [-] z3t4|7 years ago|reply
[+] [-] tokyodude|7 years ago|reply
[+] [-] btown|7 years ago|reply
[+] [-] franga2000|7 years ago|reply
[+] [-] mohsen1|7 years ago|reply
There is also Quark[1] and and Electrino[2] that do this with branding APIs.
[1] https://github.com/jscherer92/Quark
[2] https://github.com/pojala/electrino
[+] [-] flanbiscuit|7 years ago|reply
[+] [-] styfle|7 years ago|reply
[+] [-] FreeFull|7 years ago|reply
[+] [-] aylmao|7 years ago|reply
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.
[+] [-] WorldMaker|7 years ago|reply
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.
[+] [-] dangoor|7 years ago|reply
[+] [-] mikewhy|7 years ago|reply
[+] [-] xyclos|7 years ago|reply
[+] [-] tonyedgecombe|7 years ago|reply
[+] [-] evilduck|7 years ago|reply
[+] [-] flanbiscuit|7 years ago|reply
[+] [-] pier25|7 years ago|reply
[+] [-] Lerc|7 years ago|reply
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.
[+] [-] russellbeattie|7 years ago|reply
[+] [-] zserge|7 years ago|reply
[+] [-] nancyp|7 years ago|reply
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.
[+] [-] jamesgeck0|7 years ago|reply
Maybe not. If Firefox's and Chrome's headless communication protocols converge sufficiently, it may become possible for Carlo to support them interchangeably.
[+] [-] arusahni|7 years ago|reply
[+] [-] pier25|7 years ago|reply
pkg is recommended for bundling the Node app so I imagine the bundle includes V8 and Node.
https://github.com/zeit/pkg
[+] [-] _verandaguy|7 years ago|reply
- Smaller disk footprint per app; and
- Drastically smaller memory footprint per running process?
[+] [-] kyberias|7 years ago|reply
"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."
[+] [-] smaddock|7 years ago|reply
[1] https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
[+] [-] jamesgeck0|7 years ago|reply
[+] [-] asadlionpk|7 years ago|reply
I wonder if this can be further reduced.
[+] [-] nwienert|7 years ago|reply
[+] [-] aaorris|7 years ago|reply
[+] [-] willscott|7 years ago|reply
[+] [-] cdicelico|7 years ago|reply
[+] [-] browsercoin|7 years ago|reply
[+] [-] snacktaster|7 years ago|reply
no thanks
[+] [-] sctb|7 years ago|reply
[+] [-] oculusthrift|7 years ago|reply
[+] [-] yathern|7 years ago|reply
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.
[+] [-] jrockway|7 years ago|reply
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.