Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NeutralinoJS: Lightweight Electron alternative using native browser controls

neutralino.js.org

Post reply on HN
Print view View original

111–120 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#111

Post by felubra »

csnover wrote: post #91
kitsunesoba wrote: post #86

Earlier quoted context omitted.

The Spotify desktop client is architected such that each pane in the main window is essentially its own separate webapp, complete with duplicate (and triplicate, quadruplicate, etc) dependencies. They did this so their various teams don’t have to talk to each other. Desktop Spotify has been a resource hungry mess for years now. It used to be known for prematurely wearing out SSDs by constantly writing stuff (cache I…

> It used to be known for prematurely wearing out SSDs by constantly writing stuff (cache I think?) to disk. They were constantly vacuuming some SQLite database.[0] [0] https://arstechnica.com/information-technology/2016/11/for-f...

Does anybody know if this was fixed?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#112

Post by kaishin »

zelly wrote: post #101
derefr wrote: post #48

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…

Given that everyone brings this up every time Electron is mentioned, and Electron apps keep proliferating, I expect a future version of Windows and macOS to have Chromium bundled with the OS. There will be some platform independent open standard that Electron will use under the covers. Native desktop apps are never coming back. It will either be Electron or mobile apps emulated on desktops.

I don’t see Apple going the route of bundling Chromium. Catalyst does allow porting iOS apps to macOS but it’s been not great so far.

I think there will always be a category of people who prefer using native apps for performance, security, or access to OS features. Anecdotally I looked at the apps I have installed and I found out that I don’t have many electron apps on my Mac beside chat apps and VS Code. I suspect non tech-savvy people might have even less, since they do a lot more inside their browsers compared to before.

I’m not sure what you refer to when you say “native desktop apps aren’t coming back”, given that they never left t begin with.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#113

Post by gigel82 »

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 be node-side where it can be better controlled. Also enforces asynchronous and efficient communication between the UI and the "local backend".

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#114

Post by bavell »

filleduchaos wrote: post #110
judge2020 wrote: post #79

Earlier quoted context omitted.

https://github.com/electron/electron-quick-start ~60mb memory usage at startup.

So an "application" that literally just displays Hello World and no indication of uptime. Right, I'm convinced.

It shows that the framework itself only uses 60MB and implies any higher usage is due to the application built on top of electron. I'm not sure why uptime matters unless you're assuming there are memory leaks?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#115

Post by jay_kyburz »

zelly wrote: post #101
derefr wrote: post #48

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…

Given that everyone brings this up every time Electron is mentioned, and Electron apps keep proliferating, I expect a future version of Windows and macOS to have Chromium bundled with the OS. There will be some platform independent open standard that Electron will use under the covers. Native desktop apps are never coming back. It will either be Electron or mobile apps emulated on desktops.

It's called a browser.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#116

Post by WorldMaker »

valdiorn wrote: post #30
hamaluik wrote: post #18

Looks kind of like WebView [1] which I earnestly tried but eventually abandoned. Using the system-provided web engine is great for space savings, but terrible for cross-compatibility and feature availability owing to having to use IE on Windows. [1] https://github.com/zserge/webview

Isn't the "system provided web engine" now Edge on Windows 10, and has been fore a while?

In UWP yes, but not in Win32. Win32 has always been stuck on IE's MSHTML.dll controls, up until either XAML Islands for the WinRT-based EdgeHTML (coming soon, in preview today) or "Webview2" [1] for the Chromium Edge (coming soon, in preview today).

[1] https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#117

Post by dmitrygr »

derefr wrote: post #48

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.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#118

Post by divbzero »

kaishin wrote: post #112
zelly wrote: post #101

Earlier quoted context omitted.

Given that everyone brings this up every time Electron is mentioned, and Electron apps keep proliferating, I expect a future version of Windows and macOS to have Chromium bundled with the OS. There will be some platform independent open standard that Electron will use under the covers. Native desktop apps are never coming back. It will either be Electron or mobile apps emulated on desktops.

I don’t see Apple going the route of bundling Chromium. Catalyst does allow porting iOS apps to macOS but it’s been not great so far. I think there will always be a category of people who prefer using native apps for performance, security, or access to OS features. Anecdotally I looked at the apps I have installed and I found out that I don’t have many electron apps on my Mac beside chat apps and VS Code. I suspect n…

It doesn’t have to be Chromium. It just needs to be a browser that can be linked and launched as an app.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#119

Post by chipotle_coyote »

zelly wrote: post #101
derefr wrote: post #48

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…

Given that everyone brings this up every time Electron is mentioned, and Electron apps keep proliferating, I expect a future version of Windows and macOS to have Chromium bundled with the OS. There will be some platform independent open standard that Electron will use under the covers. Native desktop apps are never coming back. It will either be Electron or mobile apps emulated on desktops.

Behind my two Safari windows is the text editor I use for my technical writing job: BBEdit, a native desktop app. (For coding, though, I prefer to use MacVim, a native desktop app, although I've lately been trying out a beta of the forthcoming Panic Nova, a native desktop app.) I also use Marked, a native desktop app, for Markdown previewing occasionally. Of course, I spend a lot of time in the Terminal, a native desktop app, running command line programs and shell scripts, which are not native desktop apps but are certainly native apps. When I need to run a diff or merge tool, I tend to use Kaleidoscope, a native desktop app. Because I'm in an open office, I sometimes have to resort to headphones, which I primarily use with iTunes, a native desktop app.

Now, as I finish up this response to you in Safari, a native desktop app, remind me what were you saying about native desktop apps again?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#120

Post by c-smile »

untog wrote: post #40
vorpalhex wrote: post #22

Earlier quoted context omitted.

I wish we had a step inbetween. Something more than "just a webview" but something less than, well, all of electron. Give me like a really cut down browser that's consistent across platforms and embed it.

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.

Sciter's author here.

a) Is anyone brave here to finance transition of Sciter to OpenSource? Please contact me if yes.

b) Sciter's script is a JavaScript++:

It uses JS syntax and runtime like `arr.concat(a,b)`.

Grammar and syntax was extended to better support UI cases. Like `const width = 12px;` is valid construct as Sciter has Length data type.

React and JSX are implemented natively.

    function render() {
      return 
{this.greeting}
;
    }
is a valid construct as JSX (SSX in Sciter) is a part of script grammar : https://sciter.com/developers/sciter-docs/reactor-and-ssx/
Post reply on HN