Hacker News new | past | comments | ask | show | jobs | submit login
Carlo – Web rendering surface for Node applications (github.com)
177 points by styfle 5 months ago | hide | past | web | favorite | 92 comments



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.


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 .


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.


On the other hand you have more control over your app. The app will work and look as the author intended.


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.


>I think this offers a great leap forward in transparently keeping local software up-to-date.

Not really. You're forgetting that there is also nodejs runtime bundled with your app. And it needs to be updated too.


You could install that and node_modules system-wide ...

... are we re-inventing shared libraries?


Yes, was thinking about that. But is that really viable for regular joe?


Sure it can be. Shared libraries are also viable for a "regular joe".

There would just need to be a central manager for dependencies. And yes, I realize that we are on many layers of abstraction.


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.


It's not standalone and I don't know the details, but codesandbox.io can run what is recognizably VSCode.


Yes. At least, VSCode is using monaco-editor: https://microsoft.github.io/monaco-editor/


That's not the same thing


Stackblitz and CodeSandbox both run VSCode in the browser afaik


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.


Also IE, Firefox and Opera can run "chromeless" - so this, or a similar API (using websockets), can work in other browsers too.


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


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


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?


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.


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.


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


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?


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

[2] https://github.com/pojala/electrino


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


I have a whole list of Desktop JS platforms here: https://github.com/styfle/awesome-desktop-js


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.


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.

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.


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


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!


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.


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.


Microsoft has UWP apps, which can indeed be written in JS/HTML/CSS.


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.


I've wanted this for some time. Combined with Go for the native layer so all that's distributed is a single binary and a webapp bundle.


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


Once you have decided to write your desktop app in JavaScript/HTML/CSS it's probably the least bad option.


.Net Framework? JRE? Flash?


All examples of bad user experience, yes.


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


Given that majority of Windows apps are written in a mix of .NET and C++, most users seem quite happy with the experience.


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 wonder if Carlo would install Chrome for you if it was missing

It doesn't currently:

https://github.com/GoogleChromeLabs/carlo#q-what-happens-if-...

Perhaps it could though.


Bad for general use, but it could work for internal projects.


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.


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


Is it fair to assume then that this would result in:

- Smaller disk footprint per app; and

- Drastically smaller memory footprint per running process?


Disk footprint would be smaller. Memory wouldn't change, at least not too much.


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


Chrome Apps are deprecated [1] for all platforms except Chrome OS.

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


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


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.


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


linux: 39MB macOS: 39MB Windows: 27MB

I wonder if this can be further reduced.


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


NeutralinoJS says it can run in as little as 1MB https://neutralino.js.org/


Too bad it doesn't support macOS.


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


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


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?


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.


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.


Great name.


so basically an officially sanctioned nw.js


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

no thanks


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?


feel free to delete any comments you dont like


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


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


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


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.


right but some of us don’t have and don’t want chrome already installed.


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.


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.


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.


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.


Doing your part to conserve our planet’s disk space




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: