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
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.
Didn't catch the carlo/lorca naming thing. And, tbh, I'm all for it... I think electron is slightly better in some ways as I like the idea of one language everywhere, but that's less an issue.
And I certainly prefer an app launching my browser to show its UI over it bundling a whole fucking browser.
> You have to conform to ???
Web applications are able to work in browsers.
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.
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)
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!
How about W3C standards?
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
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
- 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.
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.
See: https://github.com/zserge/lorca/blob/master/chrome.go#L50
How would that be intercepted? Only the program that launches that chrome instance can read chrome's stdout.
It's no more or less secure than the same concern with a regular Chrome.
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.
Here's the source code: https://github.com/nehbit/aether
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.
But I could not explain this half as well as these articles about Flash. They also apply to HTML5.
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
A Qt equivalent in go would be worth considering.
It's non-free but you can "Use Sciter in binary form as it is published on the site" so cgo with bindings and the downloaded binary.
https://github.com/andlabs/libui
There are Go bindings here: