Carlo – Web rendering surface for Node applications
github.com
github.com
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.
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.
Not really. You're forgetting that there is also nodejs runtime bundled with your app. And it needs to be updated too.
... are we re-inventing shared libraries?
There would just need to be a central manager for dependencies. And yes, I realize that we are on many layers of abstraction.
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.
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?
The scenario that Chrome is so broken you can't handle it with an update is even less likely, I'd imagine.
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.
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.
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.
There is also Quark[1] and and Electrino[2] that do this with branding APIs.
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.
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.
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.
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.
To test on your device, https://whatwebcando.today/
EDIT: Just noticed later on that you are quite aware of PWAs on UWP, leaving the comment here though.
It doesn't currently:
https://github.com/GoogleChromeLabs/carlo#q-what-happens-if-...
Perhaps it could though.
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.
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.
Maybe not. If Firefox's and Chrome's headless communication protocols converge sufficiently, it may become possible for Carlo to support them interchangeably.
pkg is recommended for bundling the Node app so I imagine the bundle includes V8 and Node.
- Smaller disk footprint per app; and
- Drastically smaller memory footprint per running process?
"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."
[1] https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
I wonder if this can be further reduced.
no thanks
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.
That said, I generally agree that requiring Chrome to run an app is not great.
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.
Maybe we were special, the lasts of a dying breed.
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.
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.