.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.
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.
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 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
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?
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.
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?
> 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.
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.
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).
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.
> 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).
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.
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.
78 comments
[ 3.4 ms ] story [ 136 ms ] threadThe 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.
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.
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.
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.
It doesn't currently:
https://github.com/GoogleChromeLabs/carlo#q-what-happens-if-...
Perhaps it could though.
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
no thanks
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.
I wonder if this can be further reduced.
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.
"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...