I'm doing something similar (Go-based desktop app) with Aether (https://getaether.net), without requiring any additional tools.
The short version is, I have an Electron app, but the extent of my JS is just skin — the UI. The JS talks to two Go daemons which do the 99% of the work. It's also much more memory efficient than doing it in JS, and allows for massive parallelism. So you get best of both worlds, speed / clarity of Go, and well-developed JS UI patterns (Vue). It works well, with the caveat being a tradeoff in complexity in incorporating gRPC to let daemons talk to each other.
Electron is too bloated and heavy, and doesn't meld with the desktop... hey, lets create a new system that uses the same bloated/heavy bits as electron and also the UI that doesn't blend well.
edit: okay, so it doesn't have to download as much since it uses the already installed chrome, meaning you have to conform to ??? from an app perspective to your JS... you may as well just use electron or carlo
The project they describe IS a Go port of carlo (it's even named lorca).
carlo/lorca is meaningfully different than electron.
Electron takes chrome code base, adds node.js code, a bunch of other stuff and makes it an SDK. As a result Electron-based app consists of a copy of chrome a copy of node and maybe 2% of the total size is unique to the app.
carlo/lorca re-use Chrome instance already installed so 100% of the size is unique to the app.
That removes the biggest complaint about electron i.e. bloat of shipping 100+ MB of SDK to deliver 100 kB of app.
I think the biggest complaint about electron is not bloat of shipping the app (a one time download, not a big deal in modern times), but running the app. Since each electron program uses its own instance of Chrome, there is no resource sharing and so memory consumption is high.
Absolutely. I don't really care about the size on disk, a little bit, but not really. What I really care about is some application using far too much RA - Chrome (and by extension Electron) is notourious.
It's a fair argument that browser based UIs are not the best in all areas (resource usage, reliability ...), but an area where they win is effort needed to make them good enough or even nice simply due to its popularity.
And I certainly prefer an app launching my browser to show its UI over it bundling a whole fucking browser.
Personally, I like electron and web apps... the approach from TFA mentions it being lighter weight than Electron... when the actual running engine for both is still Chrome, which is the biggest complaint from detractors.
I'm a fan of the model and have used embedded browsers for UI for years, even for embedded kiosks as localization tended to be easier to handle for the translaters, etc.
I'm just suggesting that you can make assumptions when packaging against a specific version of electron, where a chrome install from a couple years ago may not have the features you are wanting to use.
Well, on one hand it will certainly lighten the ressources needed.
On the other hand, you don’t know on what version of Chrome/Chromium you’ll land so you won’t be able to use specific API for sure.
But for having developed in the end of the 90’s a web kiosk software, based on Internet Explorer (I think it was IE5 back then), software that still have last versions running (no one, including myself, would thought it’ll survive that long), I will sure have a look closer on the project if you can intercept the before navigate event (or whatever the name is with Chrome)
> On the other hand, you don’t know on what version of Chrome/Chromium you’ll land so you won’t be able to use specific API for sure.
Is it just me, or the API changes and breaks way too often? I recently wanted to make an extension and I Google'd here and there, and all the code posted just a few months ago is now obsolete. It is crazy!
I was thinking of my webkiosk software where Interfaces on Internet Explorer changed with version (but thankfully Microsoft provided compatibility).
But as long as the Event / API / I don't really know how it works with Chrome / Whatever way to get the Before Navigate information (and be able to stop it) still works from a version to another, W3C standard would suffice for the majority of cases
Man, that slidedeck is frightening for someone who wants functional applications:
Well-designed and attractive typographymakes content meaningful.
Animation makes important parts standout and helps with micro-interactions.
Onboarding, common for web andmobile apps, helps more than traditional"F1" button.
Visual trends may change and it shouldnot be hard to update the UI withoutrewriting it all.
The result is what used to be described as "flash websites": everyone has their own UI, with custom animations that mean something entirely unique to that application which may or may not make sense to you.
But I could not explain this half as well as these articles about Flash. They also apply to HTML5.
Every time I see these things I just sit in relative disbelief trying to figure out how PWAs have somehow not taken off yet.
Perhaps this year when they finally come to Mac too (they already work on Windows and Linux) it will finally happen. then again with the Mac App store I'm not sure that fits the Apple "vision" (if you can call it that anymore) either.
Either way its sort of maddening to see this as I think PWAs are the right answer for these questions and yet people keep bringing new and unnecessary solutions to the table
PWAs still have lots of problems. There are multiple issues, but IMO one of the biggest is that storage on the web is bad. We've gotten a lot of iteration on this, there are tons of ways to store information on a website. But none of them have offered really substantial gains over each other.
- All of them can be cleared directly from the browser, which might happen as a part of regular cleanup. This can happen on the desktop, but is much less likely to happen. Usually if a text file or image gets deleted from the desktop, the user deleted it. If localstorage gets cleared, maybe an extension deleted it. Or maybe the user just has "clear all data on exit" checked for the browser.
- There's no way for me as a user to easily clear out part of that storage, unless the app builds in its own tools to do so. Managing the storage in general is cumbersome -- quick, without looking can you tell me how to clear local storage for a specific site in Firefox without visiting the web site?
- None of them are easily accessible across browsers. So if a user accesses your website in Chrome and then opens it up again in Firefox, it's kind of a pain to move something like local storage over. Certainly, it's not something the user can easily control.
- None of them are easily accessible from native apps. Think about something like Atom, which couldn't really work on the web even in a paired down form unless it prompted you to manually download every file you edited.
- None of them are easily backed up and transferred across computers. At best, you'll get some kind of browser sync that's tied to an online account. But it's not trivial for an average user to say, "hey, I'm going to put the storage for this site on a USB drive and plug it into a new computer." If you're bundling software as an electron app, you could run the entire thing from a USB drive.
The way most sites get around this is they have online accounts that sync things and back things up. This is (again IMO) sub-optimal. It makes web apps more complicated, it forces them to require an Internet connection (it's all well and good to hook up a service worker to your site, but without good file storage you can't really make an offline-only app). It requires users to give up control of their data, and to supply personal information to use your app. It makes everything more expensive -- what would Atom look like if all of your code was getting synced to a remote server somewhere?
I understand that local file access is ridiculously dangerous. It's a huge can of worms that could be a disaster on the web if done poorly, and I absolutely don't trust anyone except maybe Mozilla to get it even mildly right. But I do think even with all of that danger, if we want the web to transition towards PWAs and protocols that value user-control over hosting and data (IPFS for example), we need to consider adding some kind of user-accessible file-based storage to the web. Something where I can open a web app in any browser, point it at a directory, and have it write files to that directory that can be accessed by native software I control.
It doesn't have to literally be, "let web browsers just start writing stuff to my hard drive." That would be stupid. But we should try to think of something.
The alternative is that the only services that actually work on the web are server-backed apps that require you to give up your data and that don't integrate well with other programs. And any (web) app where that's not feasible or where the developer cares about user privacy will be bundled into gigantic, resource-hungry Electron frameworks.
Chrome seems to allow it after enabling it in chrome://flags. The only desktop-installable PWA I've been able to find thus far is pokedex. Pretty cool to see it show up like any other app on ubuntu, though.
I fail to see how this is any resource-lighter than Electron. It still uses a browser. It might or it might not be Chrome, but it's still a browser, so it will certainly use, give or take, the same amount of resources the average browser takes.
The only thing I do see as an advantage is the reduced size in the distributable. But, imho, size really doesn't matter these days.
Can anyone tell me what mechanism would prevent any other software on the same system from intercepting the connection to Chrome? This isn't really an issue when running with X11 on Linux as any app can grab text from another window but e.g. Wayland provides much better barriers between apps.
The way this works: that the program locates chrome executable, launches it in a special mode, chrome prints which port it allocated for that instance to stdout, the program parses stdout to find the port and opens websocket connection.
the weakest point in systems like this is usually the mechanism by which the local process communicates with the browser. it's very hard to secure such a mechanism properly as there's no official API for it
this claims to use the chrome devtools debug protocol, which I believe is usually entirely unauthenticated. i would not be surprised if someone can compromise this system via this protocol
edit: this happened already with node in the case of CVE-2018-7160