Live data from Hacker News

NeutralinoJS: Lightweight Electron alternative using native browser controls

neutralino.js.org

191–200 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#191

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…

Love the idea of shipping something smaller. In your proposed idea, would a user still need to make sure node and express were installed? Or can you have a user download a project folder and initiate the same way they would a typical executable?

When distributed to end-users it could be an executable with node DLL/SO bundled that has no UI (or maybe a simple tray/menu bar icon with an Exit to terminate and a Show to open a local browser to /localhost:1337).

When developing locally I presume it would be very similar to an Electron project, with npm dependencies for express / fastify on the "backend" side and React or whatever you need for the "frontend" side.

During build, you'd produce 2 bundles (frontend and backend) that tree-shake, etc. such that all js dependencies are optimized together. The frontend bundle should load in any browser (it'd be just a normal website with the only difference being that all REST calls go to /localhost). The backend bundle + any native modules will be loaded in the embedded node runtime so they can be distributed as loose files or packaged in something like Electron's asar.

There, I designed the whole thing, now someone go build it :)

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#192
post #184

Earlier quoted context omitted.

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 des…

Offtopic, but if you’d like an elegant hybrid† Markdown viewing/editing experience, I’d suggest https://typora.io/ , another nicely-polished low-memory-consumption native app. † I don’t know what to call this editing paradigm. It’s somewhere between source-editing and WYSIWYG. Document markup nodes are rendered as their source syntax when your cursor is “inside” them, allowing for plaintext modification of the syntax…

I use Typora myself, but it's definitely an Electron app (neither native, nor lightweight).

https://support.typora.io/What's-New-0.9.66/

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#193
post #64
post #51

Earlier quoted context omitted.

Where is this 1-2GB number coming from? I'm running a fairly large Electron app and the combined memory usage of its processes is about 250-300MB.

I’m currently running three Electron apps: Spotify, Skype, and VS Code. Spotify: 1083.7 MB. VS Code: 890.9 MB. Skype: 406 MB. In the past, I’ve had projects open in VS Code which have caused that number to shoot up into the multi-gigabyte range. Of course this is all anecdotal but I am pretty sure these numbers come from actual experiences that people are having with Electron apps.

I have VSCode running and it takes up only 166MB or RAM.

Proof: https://i.imgur.com/nKenjcw.png

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#194

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…

> They did this so their various teams don’t have to talk to each other.

This is just insane.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#195
post #158
post #152

Earlier quoted context omitted.

We had that in Windows 98, it was Active Desktop. It was bloatish and a lot of people disabled it in order to get far more cycles. Heck, IE and Explorer.exe were the same. http://toastytech.com/files/throboff.html KDE3 did the same with KParts, but it was several times better.

Microsoft was ahead of its time in this. In 2020 we are ready for it. Moore's law has caught up. It would be less efficient and more wasteful to continue things as normal where every program has its own Electron. People already use Electron type apps. New ones are being made every day. That's not going away. If Microsoft and Apple put this in the OS, it would decrease the user's resource utilization. It's a net win f…

If you think this is smooth, you must be new on IT. Xfce already was blazing fast in 2005, even against GNOME 2. Shell is a bloat disaster, and KDE > 3.5.10, a segfaulting fest, but 3.5.10 was rock solid.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#196
post #195
post #158

Earlier quoted context omitted.

Microsoft was ahead of its time in this. In 2020 we are ready for it. Moore's law has caught up. It would be less efficient and more wasteful to continue things as normal where every program has its own Electron. People already use Electron type apps. New ones are being made every day. That's not going away. If Microsoft and Apple put this in the OS, it would decrease the user's resource utilization. It's a net win f…

If you think this is smooth, you must be new on IT. Xfce already was blazing fast in 2005, even against GNOME 2. Shell is a bloat disaster, and KDE > 3.5.10, a segfaulting fest, but 3.5.10 was rock solid.

I've literally been using desktop Linux since I installed Ubuntu in 2006 in the spinning cubes era. It was never good. Windows (except Vista) always had a snappier interface. Xfce and GNOME2 are fast, I'll give it that, but don't have any animations or aesthetics whatsoever (and yes that does matter--it makes you happy to use your machine). If all I cared about was resource usage, I'd not use a DE at all and only use something like dwm. GNOME3 is polished and works, the best and only free contender to Apple and Windows desktops.

Bloat is something only insiders care about. I care more about adoption of free software than I do about its quality in the academic sense. The way to get adoption is UX and looking nice. If you're trying to convince someone to switch from Windows, what would you show them, Xfce or GNOME3?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#197
post #189
post #158

Earlier quoted context omitted.

Microsoft was ahead of its time in this. In 2020 we are ready for it. Moore's law has caught up. It would be less efficient and more wasteful to continue things as normal where every program has its own Electron. People already use Electron type apps. New ones are being made every day. That's not going away. If Microsoft and Apple put this in the OS, it would decrease the user's resource utilization. It's a net win f…

Smooth?! I gave up on it and installed XFCE to get CPU cycles back.

I've only ever used it on expensive hardware so maybe I'm biased.

I have to kill gnome-shell maybe once a week. That's a huge improvement over KDE.

Xfce to me is just too ugly to use. And it messes up my system with all these trash Xfce-only applications and mime associations (seriously what's exo-open and why is it still causing problems 2 years after I uninstalled xfce?).

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#198
post #187
post #155

Earlier quoted context omitted.

PWAs can never fully substitute native applications. It's difficult to access hardware and impossible to call operating system functions from a PWA. Applications that do something interesting tend to have a native library behind the frontend that does performance-sensitive work.

Quite the contrary, one of the benefits of PWAs is exactly that when they are distributed via app stores they get access to native APIs without any kind of manual FFI. That is how they work across ChromeOS, Android and Windows, with Apple being the outlier for obvious reasons.

I didn't know this. If this is true then it's more powerful than Electron, which requires you exchange IPC messages from a separate process. The fact that you have to use the app store is a major disadvantage though.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#199
post #143
post #114

Earlier quoted context omitted.

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?

The context here is that "the framework" does things 'for' the application it is hosting that the application cannot control, caching various things in memory in a way that makes sense for a browser, but not very much sense for a custom application. Try this: open a new Chrome instance; look at its memory usage; then load a bunch of tabs (try an Open All on a bookmarks folder), close them all again, and then look at…

Great points, thank you!

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#200
post #196
post #195

Earlier quoted context omitted.

If you think this is smooth, you must be new on IT. Xfce already was blazing fast in 2005, even against GNOME 2. Shell is a bloat disaster, and KDE > 3.5.10, a segfaulting fest, but 3.5.10 was rock solid.

I've literally been using desktop Linux since I installed Ubuntu in 2006 in the spinning cubes era. It was never good. Windows (except Vista) always had a snappier interface. Xfce and GNOME2 are fast, I'll give it that, but don't have any animations or aesthetics whatsoever (and yes that does matter--it makes you happy to use your machine). If all I cared about was resource usage, I'd not use a DE at all and only use…

Myself, since Debian Woody, when 2.4 was an _optional_ kernel. On snappiness, it depends. On multitasking, KDE3 run circles over XP.

>GNOME3 is polished and works, Not even close. It uses huge loads of RAM while Budgie, while using the same technology, is far snappier. For a current user, I'd suggest Solus with Budgie.

Post reply on HN