131–140 of 200 posts
This is the correct way of doing it when a PWA doesn't cut it. No need to push a full browser engine when the OS already has enough of them available.
It definitely is the 'correct' way of doing it, but it will mean you use IE when in windows, which is often/normally not the correct way
If you want anything from the web to work on Windows as native why not just use PWA utilizing Microsoft's (1) own PWA Builder (2) including the availability of proper debugging tools and acceptance in the store? It doesn't matter what tech it uses. The more important thing is it will be supported and updated. There won't be any surprises. (1) https://developer.microsoft.com/en-us/windows/pwa/ (2) https://www.pwabuild…
Earlier quoted context omitted.
> I’m wondering whether it’d be possible to factor most of it out into a separate layer We've done this. The layer is called a web browser. You deliver runnable code to it using something called HTTP.
Did you even read the comment? GP literally addresses deficiencies in this layer when running multiple instances of the browser.
> 1. this would lose you the ability to develop for a particular version of the renderer
html and css are standards, if you are developing for a version, you are wrong. full stop.
> 2. this wouldn’t give you the benefit of Electron sharing service-memory with Chrome itself
there would be no electron so point is irrelevant
I see projects like this pop up every once in a while and get abandoned. A simpler approach may be to just publish a basic web server as your app (express on top of node would do) that runs on the local machine on some random port and have users just go to that URL with their regular installed browser. Bonus points for no leakage of security / CORS / etc. issues from the UI side of things, every unsafe thing needs to…
Earlier quoted context omitted.
It's a shame Sciter hasn't seen more adoption: https://sciter.com/ But a) it's a commercial product and b) uses it's own scripting language instead of JavaScript. But from some initial noodling around with it the browser engine is very capable and the footprint small.
The weird language is the big turn-off for me, not the license. This is also a turn-off for Flutter and Lazarus. WHY do these projects insist on doing this? What is it about UI that leads people to think this is a good idea? Do not make me learn yet another language just to use your UI library. It's not that FreePascal or Dart are bad languages. It's that they're another language to consume yet more precious attentio…
Earlier quoted context omitted.
Everything you've written here presents a nightmarish vision of the computing future. Ethical and privacy considerations play a large role in my decision making process on which software I use. I don't want to use Chromium at all, if possible. I use one Electron app, Slack, on account of requiring it for work. > Native desktop apps are never coming back I really hope you're wrong. This would be a terrible outcome for…
Gnome already is based on html/js. There is no need for 10 different UI toolkits if one standard can be optimized. The problem is html/js are far from well designed but due to their popularity a lot of time and money has been spent optimizing them.
I feel like nobody cares too much if they’re running one Electron app; people do have the headroom for an extra 1-2GB of RAM usage. The problem comes when they run several Electron apps at once, and each comes with its own “base” overhead (i.e. the runtime memory consumption of the browser-runtime as a whole, independent of how many render contexts are open.) Chromium is built to share a lot of things between tabs ef…
> I’m wondering whether it’d be possible to factor most of it out into a separate layer We've done this. The layer is called a web browser. You deliver runnable code to it using something called HTTP.
There are, however, very stable in-browser ways of dealing with the question of client-side storage. IndexedDB is one. But there is another that I am quite partial to, called the File System API. I use it to locally store the files and code in the browser-based OS called Linux on the Web (https://dev.lotw.xyz/desk.os).
Earlier quoted context omitted.
Did you even read the comment? GP literally addresses deficiencies in this layer when running multiple instances of the browser.
i did, and found them unconvincing > 1. this would lose you the ability to develop for a particular version of the renderer html and css are standards, if you are developing for a version, you are wrong. full stop. > 2. this wouldn’t give you the benefit of Electron sharing service-memory with Chrome itself there would be no electron so point is irrelevant
Who said anything about HTML and CSS?
Apps like VS Code create and manipulate a DOM directly in JS, or more often these days, WASM. To these apps, Electron is just a virtual machine with a lot of browser-like multimedia APIs attached. You pin the exact version of the renderer just like you pin the exact version of your dependencies in a server-side app, or the exact version of the OS in a virtual-appliance VM image.
Electron has nothing to do with "the web" or "web standards" other than borrowing technologies originally developed for those. Electron competes with things like Unity and https://love2d.org/, not with browsers. It's in a category of frameworks with the goal of giving the developer pixel-perfect control over what the user sees, where apps are separately developed, tested, and tweaked, for each target (e.g. each OS, each kind of display/interaction methodology, etc.)
With this category of framework, you don't build your app as generic code targeting a standard; rather, you build, and test, your product against a specific "engine." (Imagine for a moment that people could take Unity apps and run them against any old version of the Unity engine, or even against Amazon's Lumberyard fork of the same. Would anything work?)
Earlier quoted context omitted.
i did, and found them unconvincing > 1. this would lose you the ability to develop for a particular version of the renderer html and css are standards, if you are developing for a version, you are wrong. full stop. > 2. this wouldn’t give you the benefit of Electron sharing service-memory with Chrome itself there would be no electron so point is irrelevant
> html and css are standards, if you are developing for a version, you are wrong. full stop. Who said anything about HTML and CSS? Apps like VS Code create and manipulate a DOM directly in JS, or more often these days, WASM. To these apps, Electron is just a virtual machine with a lot of browser-like multimedia APIs attached. You pin the exact version of the renderer just like you pin the exact version of your depend…
in much the same that sharpened sticks compete with power tools, yes