10 ms·

Carlo – Web rendering surface for Node applications

177 points by styfle 8y ago

oculusthrift 8y ago
ew. I was with you until you said it requires chrome.
- jrockway 8y ago
  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.
  - oculusthrift 8y ago
    right but some of us don’t have and don’t want chrome already installed.
    - dangoor 8y ago
      If you've got any Electron apps, you kinda sorta do already have Chrome installed. That said, I generally agree that requiring Chrome to run an app is not great.
      - jrockway 8y ago
        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.
        pjmlp 8y ago
        Strangely enough I and many other engineers were able to write multiplaform applications in the early 2000 without Electron crap. Maybe we were special, the lasts of a dying breed.
- yathern 8y ago
  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.
  - aylmao 8y ago
    I'd like to see this as a single button, where you download the 3MB standalone, and if the user doesn't have chrome, it downloads an Electron runtime.
    - finchisko 8y ago
      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.
      - zserge 8y ago
        I started a webview project some time ago, and I see some people using it in their projects - https://github.com/zserge/webview https://github.com/zserge/webview Basically, it provides some high-level APi over a native system webview (WebKit or IE, depending on the OS).
xyclos 8y ago
You have to install a separate completely unrelated (from the users' perspective) application to run an application written with this? that seems bad.
- pier25 8y ago
  Bad for general use, but it could work for internal projects.
- evilduck 8y ago
  .Net Framework? JRE? Flash?
  - aylmao 8y ago
    All examples of bad user experience, yes.
    - jamesgeck0 8y ago
      .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.
    - pjmlp 8y ago
      Given that majority of Windows apps are written in a mix of .NET and C++, most users seem quite happy with the experience.
- flanbiscuit 8y ago
  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
  - milesokeefe 8y ago
arusahni 8y ago
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.
pier25 8y ago
TL;DR: this is like Electron, but instead of bundling Chrome it uses the local Chrome installation. pkg is recommended for bundling the Node app so I imagine the bundle includes V8 and Node. https://github.com/zeit/pkg https://github.com/zeit/pkg
- _verandaguy 8y ago
  Is it fair to assume then that this would result in: - Smaller disk footprint per app; and - Drastically smaller memory footprint per running process?
  - mikewhy 8y ago
    Disk footprint would be smaller. Memory wouldn't change, at least not too much.
aaorris 8y ago
Biggest detraction here for me is the Apache license, compared to an MIT license in Electron.
- willscott 8y ago
  Hunh? Apache is a more permissive license than MIT. why is Google waiving it's claim to patents on this project a problem for you?
  - rossy 8y ago
    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.
    - Fice 8y ago
      But Apache 2.0 is compatible with GPLv3, which means, that you can combine GPLv3 and "GPLv2 or later" libraries with code under Apache 2.0.
yathern 8y ago
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 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 8y ago
  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 .
  - thefounder 8y ago
    On the other hand you have more control over your app. The app will work and look as the author intended.
    - ramses0 8y ago
      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.
aylmao 8y ago
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.
- dangoor 8y ago
  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!
  - tonyedgecombe 8y ago
    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.
    - SargeZT 8y ago
      Microsoft has UWP apps, which can indeed be written in JS/HTML/CSS.
      - WorldMaker 8y ago
        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.
  - WorldMaker 8y ago
    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.
snacktaster 8y ago
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.
- woah 8y ago
  Doing your part to conserve our planet’s disk space
nancyp 8y ago
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.
- jamesgeck0 8y ago
  > 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.
mohsen1 8y ago
This is something Electron itself can probably do and I can see why some people might be interested in shipping their Electron apps without Chromium. There is also Quark[1] and and Electrino[2] that do this with branding APIs. [1] https://github.com/jscherer92/Quark https://github.com/jscherer92/Quark [2] https://github.com/pojala/electrino https://github.com/pojala/electrino
- flanbiscuit 8y ago
  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
- styfle 8y ago
  I have a whole list of Desktop JS platforms here: https://github.com/styfle/awesome-desktop-js https://github.com/styfle/awesome-desktop-js
snacktaster 8y ago
anything that requires chrome to function is essentially spyware. so.. no thanks
- sctb 8y ago
  We've already asked you to improve your comments, so we'll ask again. Can you please post civilly and substantively or not at all?
  - snacktaster 8y ago
    feel free to delete any comments you dont like
nwienert 8y ago
Would be nice to just see this as an opt-in add-on for Electron where it uses Puppeteer in the same way.
tokyodude 8y ago
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.
- btown 8y ago
  What kinds of Chrome APIs are you using? Anything related to web styling and DOM should be stable.
  - qualsiasi 8y ago
    > should 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?
    - xixixao 8y ago
      You will roll out a fix in your application. Just like every major website when Chrome breaks something. The scenario that Chrome is so broken you can't handle it with an update is even less likely, I'd imagine.
    - jordanthoms 8y ago
      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.
russellbeattie 8y ago
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.
jamesgeck0 8y ago
What is the size of the executable that pkg produces for a Carlo example app?
- asadlionpk 8y ago
  linux: 39MB macOS: 39MB Windows: 27MB I wonder if this can be further reduced.
  - davej 8y ago
    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).
  - 13years 8y ago
    NeutralinoJS says it can run in as little as 1MB https://neutralino.js.org/ https://neutralino.js.org/
    - asadlionpk 8y ago
      Too bad it doesn't support macOS.
browsercoin 8y ago
so basically an officially sanctioned nw.js
kyberias 8y ago
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."
- smaddock 8y ago
  Chrome Apps are deprecated [1] for all platforms except Chrome OS. [1] https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
  - z3t4 8y ago
    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.
  - pjmlp 8y ago
    Yes, they were replaced by PWAs, which is the proper way of doing apps for devs that don't want to touch OS APIs.
FreeFull 8y ago
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.
cdicelico 8y ago
Great name.
Lerc 8y ago
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.
zserge 8y ago
It probably might be a good idea to make a similar Chrome-based backend for https://github.com/zserge/webview https://github.com/zserge/webview to provide consistent browser engine for all OSes.

177 points by styfle 8y ago

oculusthrift 8y ago

ew. I was with you until you said it requires chrome.

jrockway 8y ago
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.
- oculusthrift 8y ago
  right but some of us don’t have and don’t want chrome already installed.
  - dangoor 8y ago
    If you've got any Electron apps, you kinda sorta do already have Chrome installed. That said, I generally agree that requiring Chrome to run an app is not great.
    - jrockway 8y ago
      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.
      - pjmlp 8y ago
        Strangely enough I and many other engineers were able to write multiplaform applications in the early 2000 without Electron crap. Maybe we were special, the lasts of a dying breed.
yathern 8y ago
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.
- aylmao 8y ago
  I'd like to see this as a single button, where you download the 3MB standalone, and if the user doesn't have chrome, it downloads an Electron runtime.
  - finchisko 8y ago
    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.
    - zserge 8y ago
      I started a webview project some time ago, and I see some people using it in their projects - https://github.com/zserge/webview https://github.com/zserge/webview Basically, it provides some high-level APi over a native system webview (WebKit or IE, depending on the OS).

xyclos 8y ago

You have to install a separate completely unrelated (from the users' perspective) application to run an application written with this? that seems bad.

pier25 8y ago
Bad for general use, but it could work for internal projects.
evilduck 8y ago
.Net Framework? JRE? Flash?
- aylmao 8y ago
  All examples of bad user experience, yes.
  - jamesgeck0 8y ago
    .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.
  - pjmlp 8y ago
    Given that majority of Windows apps are written in a mix of .NET and C++, most users seem quite happy with the experience.
flanbiscuit 8y ago
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
- milesokeefe 8y ago

arusahni 8y ago

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.

pier25 8y ago

TL;DR: this is like Electron, but instead of bundling Chrome it uses the local Chrome installation. pkg is recommended for bundling the Node app so I imagine the bundle includes V8 and Node. https://github.com/zeit/pkg https://github.com/zeit/pkg

_verandaguy 8y ago
Is it fair to assume then that this would result in: - Smaller disk footprint per app; and - Drastically smaller memory footprint per running process?
- mikewhy 8y ago
  Disk footprint would be smaller. Memory wouldn't change, at least not too much.

aaorris 8y ago

Biggest detraction here for me is the Apache license, compared to an MIT license in Electron.

willscott 8y ago
Hunh? Apache is a more permissive license than MIT. why is Google waiving it's claim to patents on this project a problem for you?
- rossy 8y ago
  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.
  - Fice 8y ago
    But Apache 2.0 is compatible with GPLv3, which means, that you can combine GPLv3 and "GPLv2 or later" libraries with code under Apache 2.0.

yathern 8y ago

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 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 8y ago
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 .
- thefounder 8y ago
  On the other hand you have more control over your app. The app will work and look as the author intended.
  - ramses0 8y ago
    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.

aylmao 8y ago

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.

dangoor 8y ago
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!
- tonyedgecombe 8y ago
  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.
  - SargeZT 8y ago
    Microsoft has UWP apps, which can indeed be written in JS/HTML/CSS.
    - WorldMaker 8y ago
      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.
- WorldMaker 8y ago
  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.

snacktaster 8y ago

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.

woah 8y ago
Doing your part to conserve our planet’s disk space

nancyp 8y ago

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.

jamesgeck0 8y ago
> 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.

mohsen1 8y ago

This is something Electron itself can probably do and I can see why some people might be interested in shipping their Electron apps without Chromium. There is also Quark[1] and and Electrino[2] that do this with branding APIs. [1] https://github.com/jscherer92/Quark https://github.com/jscherer92/Quark [2] https://github.com/pojala/electrino https://github.com/pojala/electrino

flanbiscuit 8y ago
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
styfle 8y ago
I have a whole list of Desktop JS platforms here: https://github.com/styfle/awesome-desktop-js https://github.com/styfle/awesome-desktop-js

snacktaster 8y ago

anything that requires chrome to function is essentially spyware. so.. no thanks

sctb 8y ago
We've already asked you to improve your comments, so we'll ask again. Can you please post civilly and substantively or not at all?
- snacktaster 8y ago
  feel free to delete any comments you dont like

nwienert 8y ago

Would be nice to just see this as an opt-in add-on for Electron where it uses Puppeteer in the same way.

tokyodude 8y ago

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.

btown 8y ago
What kinds of Chrome APIs are you using? Anything related to web styling and DOM should be stable.
- qualsiasi 8y ago
  > should 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?
  - xixixao 8y ago
    You will roll out a fix in your application. Just like every major website when Chrome breaks something. The scenario that Chrome is so broken you can't handle it with an update is even less likely, I'd imagine.
  - jordanthoms 8y ago
    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.

russellbeattie 8y ago

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.

jamesgeck0 8y ago

What is the size of the executable that pkg produces for a Carlo example app?

asadlionpk 8y ago
linux: 39MB macOS: 39MB Windows: 27MB I wonder if this can be further reduced.
- davej 8y ago
  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).
- 13years 8y ago
  NeutralinoJS says it can run in as little as 1MB https://neutralino.js.org/ https://neutralino.js.org/
  - asadlionpk 8y ago
    Too bad it doesn't support macOS.

browsercoin 8y ago

so basically an officially sanctioned nw.js

kyberias 8y ago

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."

smaddock 8y ago
Chrome Apps are deprecated [1] for all platforms except Chrome OS. [1] https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
- z3t4 8y ago
  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.
- pjmlp 8y ago
  Yes, they were replaced by PWAs, which is the proper way of doing apps for devs that don't want to touch OS APIs.

FreeFull 8y ago

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.

cdicelico 8y ago

Great name.

Lerc 8y ago

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.

zserge 8y ago

It probably might be a good idea to make a similar Chrome-based backend for https://github.com/zserge/webview https://github.com/zserge/webview to provide consistent browser engine for all OSes.