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

161–170 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#161

Post by untog »

c-smile wrote: post #120
untog wrote: post #40

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.

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 {thi…

Don’t get me wrong, I agree with you that it’s an amazing scripting language. But I think one of the reasons Electron has been so popular is that web devs can take all the skills they already have, including JS, and make a native app. Learning a new language is a barrier to adoption, to hiring developers in the future, blah blah.

But I want to give you credit for an absolutely phenomenal project! If I had the cash lying around to finance it as an open source concern I would, but alas.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#162

Post by smt88 »

woodrowbarlow wrote: post #74
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 believe (but may be mistaken) that this was a goal of mozilla's positron project -- an electron-compatible runtime that uses firefox instead of chromium, but shares most resources across all of the positron apps running on your system so that it's more like having multiple tabs open rather than having multiple distinct instances open.

This paradigm is already supported by Container Tabs. It seems like Firefox is really close to the ideal of sharing memory without sharing user data.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#163

Post by c-smile »

api wrote: post #156
c-smile wrote: post #153

Earlier quoted context omitted.

> You can't write your GUI in those languages. What do you mean by "write GUI"? If to declare DOM structure then HTML is for that. If to initialize DOM structure from code at runtime then this (C++ here): use namespace sciter; element root = window.get_root(); element div = element::create("div", L"Hello world"); root.append(div); div.attach_event_handler(my_controller); Or do you mean something else?

Whoa... I didn't know it let you do that! In that case that's quite interesting. It opens the potential for using the web renderer but not having to code everything in JS.

"It opens the potential..."

Applications that use Sciter for their UI are native applications. Like Norton AntiVirus for example. Or any other app of these vendors: https://sciter.com/#customers

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#164

Post by ljm »

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…

It has side effects, too. For example, I wanted to record a new screencast with OBS Studio (fantastic free software), but couldn’t capture any chromium-based application without disabling GPU-acceleration.

Only happens with electron apps.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#165

Post by throwlaplace »

gigel82 wrote: post #113

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…

Does the browser really have access to all the same apis as electron? Doesn't electron have broader access to the file system (e.g. all the stuff that vscode does).

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#167

Post by city41 »

kitsunesoba wrote: post #86
fmakunbound wrote: post #76

Earlier quoted context omitted.

Wow. I've got Apple Music/iTunes running for a week or so on this Catalina macOS and the process viewer reports 300MB (including sub-processes). I assume it's a native application. How does Spotify manage to use so much RAM??

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…

I have found it to be rather buggy. I sometimes can't get songs to play, and other times can't get them to pause :) I switched to using their web interface in Firefox which has been totally rock solid.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#168

Post by tlavoie »

throwlaplace wrote: post #165
gigel82 wrote: post #113

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…

Does the browser really have access to all the same apis as electron? Doesn't electron have broader access to the file system (e.g. all the stuff that vscode does).

What the parent posted is stating is that the local web server has that system-level access, which the browser doesn't need in order to access the app.

The "back end" web server can be running on whatever language stack you like, be it Go, Rust, Haskell, Common Lisp or whatever. Syncthing is one example, where it's nominally headless, but there is a local web server that can be pulled up to set preferences, monitor status and so on. Works great.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#169

Post by iamleppert »

A hello world Electron app uses about 50 MB of memory.

The problem with Electron apps is not so much Electron or Chromium but how they are designed & developed. Most developers view memory optimization as an after-thought. This is especially true for multiple document interface applications. The tooling is all there to monitor and optimize memory, but few make real memory budgets part of their build & integration testing process.

Developers have 16-32 GB of memory (or more) workstations and typically work on individual features that don’t exercise the edge cases of large datasets. They don’t bother to implement proper LRU mechanisms, paging, and often do performance optimizations that sacrifice memory for speed.

It gets worse if they aren’t forced to dog food their own creations or aren’t users of their app themselves.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#170

Post by throwlaplace »

tlavoie wrote: post #168
throwlaplace wrote: post #165

Earlier quoted context omitted.

Does the browser really have access to all the same apis as electron? Doesn't electron have broader access to the file system (e.g. all the stuff that vscode does).

What the parent posted is stating is that the local web server has that system-level access, which the browser doesn't need in order to access the app. The "back end" web server can be running on whatever language stack you like, be it Go, Rust, Haskell, Common Lisp or whatever. Syncthing is one example, where it's nominally headless, but there is a local web server that can be pulled up to set preferences, monitor s…

oh yes you're right. i got confused for a moment. thanks!
Post reply on HN