
Carlo – Web rendering surface for Node applications - styfle
https://github.com/GoogleChromeLabs/carlo
======
yathern
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
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
On the other hand you have more control over your app. The app will work and
look as the author intended.

~~~
ramses0
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.

~~~
yathern
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.

~~~
lilactown
Yes. At least, VSCode is using monaco-editor:
[https://microsoft.github.io/monaco-
editor/](https://microsoft.github.io/monaco-editor/)

~~~
orf
That's not the same thing

------
tokyodude
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
What kinds of Chrome APIs are you using? Anything related to web styling and
DOM should be stable.

~~~
qualsiasi
> 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?

~~~
betageek
Run tests against Canary, you will have plenty of time to update. How is this
different from normal native apps when OS updates break things?

~~~
qualsiasi
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.

------
mohsen1
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
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

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

------
aylmao
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
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!

~~~
WorldMaker
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.

~~~
dangoor
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.

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

~~~
evilduck
.Net Framework? JRE? Flash?

~~~
aylmao
All examples of bad user experience, yes.

~~~
jamesgeck0
.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.

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

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

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

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

------
arusahni
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
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
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
Disk footprint would be smaller. Memory wouldn't change, at least not too
much.

------
kyberias
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
Chrome Apps are deprecated [1] for all platforms except Chrome OS.

[1] [https://blog.chromium.org/2016/08/from-chrome-apps-to-
web.ht...](https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html)

~~~
pjmlp
Yes, they were replaced by PWAs, which is the proper way of doing apps for
devs that don't want to touch OS APIs.

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

~~~
asadlionpk
linux: 39MB macOS: 39MB Windows: 27MB

I wonder if this can be further reduced.

~~~
13years
NeutralinoJS says it can run in as little as 1MB
[https://neutralino.js.org/](https://neutralino.js.org/)

~~~
asadlionpk
Too bad it doesn't support macOS.

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

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

~~~
willscott
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
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
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.

------
cdicelico
Great name.

------
browsercoin
so basically an officially sanctioned nw.js

------
snacktaster
anything that requires chrome to function is essentially spyware. so..

no thanks

~~~
sctb
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
feel free to delete any comments you dont like

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

~~~
yathern
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
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
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
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).

------
snacktaster
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
Doing your part to conserve our planet’s disk space

