Neutralinojs – Build lightweight cross-platform desktop apps with JavaScript | Hacker News Reader

Neutralinojs – Build lightweight cross-platform desktop apps with JavaScript

neutralino.js.org

115 pointsthekode73 comments

> Neutralinojs doesn't bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux)

I respect the teams that will go through the effort to test and support this, but I can name on 3 fingers the engineers out of the 100+ I've worked with the past 10 years who wouldn't kick and scream about having to test in anything other than just chrome on their MacBooks.

Devs today are just not built for cross engine work, we're back in IE6 land again and if it comes down to them having to test in 3 engines to save the customer a gig of space and gigs of memory they'd rather just burn the cycles and space than have to do that.

Maybe other peoples experiences differ, if they do I'm jealous.

Exactly. Every update or non-update of the Browser can have consequences for your app.

This gets brought up every time this concept is floated. As if web developers don't already face this challenge today, and as if web browsers aren't developed with huge amounts of regression analysis. Not only that, but today browsers are considerably more consistent between them.

I think to some extent developers today are choosing not to face this challenge directly. A couple years ago I started using safari instead of chrome, and since then I've worked on a couple projects where my dev time has been the only testing on safari done.

In this time also out on the normal internet, I've seen a shocking number of sites with critical functionality broken on safari. I'm talking nav, login, payment, on the sites of major brands, wireless carriers, saas companies.

So, do we face this challenge today? It exists certainly, but it seems like increasingly we are pretending it doesn't.

There are a few inconsistencies between modern browsers left, but in my day-to-day so far the fixes have been quick and straightforward.

The only exception is 100vw and 100vh. On desktop, building an “app” that fills the screen with a header on top and a footer on bottom, this works great. On some mobile browsers, it places the footer below the browsers navbar because the navbar is not subtracted from the pages height.

I’ve had a heck of a time working around this in css, particularly because the fix for mobile seems to break desktop chrome.

But compared to even a decade ago, this is nirvana.

The new svh (smallest vertical height) units will help you with that problem on mobile, Firefox will require a fallback vh though.

The problem you're describing isn't a lack of interest in facing cross platform/browser challenges, but rather substantial barriers to entry preventing developers from doing their job.

To test on Safari, you need a mac. That is a substantial cost. We assume it doesn't exist because we work at places that offer us macbooks (of note, all my teammates test on Safari because we easily can now), but when we are talking about the web at large this is a tremendous cost and is why so many websites are broken on Safari-exclusively (as opposed to both Safari and Firefox). So many websites, even from large companies, are developed by a handful of people, and their habits carry over. This establishes an expectation of not caring about Safari and all of its quirks, it gets relegated to "the user will just use another browser if it's broken".

For this problem to cease existing, Safari needs to be released on other operating systems. Until then, Safari will always be disregarded and untested.

Often these web apps, just doesn't work on iOS. Seen that happen quite a few times. Also keep in mind Safari on iOS has 7-Day Cap on All Script-Writeable Storages such as:

Indexed DB LocalStorage Media keys SessionStorage Service Worker registrations and cache

Unless if the Web Applications was added to the Home Screen.

https://web.dev/storage-for-the-web/

Moreover, if you're working on a desktop app, you don't want to introduce an extra dimension where bugs can be present. I've seen people downplay this, but differences in browser behavior is absolutely a source of potential bugs / was a source of much frustration for me when I worked as a web developer.

You want everything to be as deterministic as possible. If you ship an app today, you don't want to have to deal with future updates potentially breaking your code. I pretty strongly feel that OS-vendered web browsers executing desktop applications is a fundamentally flawed approach compared to the alternatives, it maximizes useless churn.

> I can name on 3 fingers the engineers out of the 100+ I've worked with the past 10 years who wouldn't kick and scream about having to test in anything other than just chrome on their MacBooks.

We don't know each other but you can add me to the list. First, I don't use a Mac, second I use Firefox. That means that if it works for me it should work for everybody else. Proof is that customers don't complain with me.

I don't want software from someone "just not built for cross engine work"; their ignorance is normally much more extensive.

"I don't want"

That doesn't mean anything or change anything, sorry. Maybe you can refuse to use Teams provided by your employer and quit your job just because of that, but nobody else does.

Lacking not only the incentives but also the skills to care about portability is a symptom, not a need.

Generally, Safari is the only common web browser (on desktop and iOS) that I have quirks with these days. Whatever will work on Chrome will work on Edge. And Firefox seems to always "just work" as expected.

As a Firefox user, I’m finding increasingly many websites don’t work properly and have have to switch to edge or chrome.

I’m getting close to switching — life’s too short, even if I believe in Firefox.

I just open Chrome and then close. Why switch? Happens 1x a week.

Even if a legitimate compatibility issue only happens 1x a week, once it becomes that frequent for sites to not work in firefox you have to wonder if that's the reason every time a site doesn't work properly, which gets annoying and wastes more time.

I'm getting frustrated with all the websites now claiming Firefox is an "ad blocker" and paywall, captcha-jailing, and worse just for deigning to open the page in Firefox. (I have zero ad blockers installed. I do have built-in ETP on and use a bunch of containers, neither of which is actually "ad blocking", just cookie confusing.)

Plus every bugfix that eventually gets discovered now requires an update to be shipped to end users.

Atleast with websites, devs can ship a fix on the server immediately.

So the impact of different browsers behaving differently is much greater when distributing binaries with Neutralinojs. Having a bundled browser (eg Electron) atleast mitigates this vector for bugs

Are you saying that you build desktop apps that are just a webview container for the JS bundle which is hosted server-side? Is that typical with Electron dev work? I would have assumed that most people ship the bundle with the app, so that it can function without phoning home.

Does this even affect memory use? Disk space is definitely affected, but why memory use? Each tab is usually a separate process anyway so I don’t think resource sharing will make much difference

Edit: they have benchmarks for it, the difference doesn’t seem very significant

https://github.com/neutralinojs/evaluation

8MB vs 42MB for electron. That's pretty real savings IMO!

It's also using the existing shared libraries on your system, so there's a very real chance a lot of this 8MB might be ready resident & take zero additional space. It'd be great to see what the memory impact of launching a second & different app would be!

Personally I think the Electron hate is because people think every Electron app behaves as badly as Slack. Honestly 42MB is not that bad. But it hurts my soul that each app has it's own static copy of the browser, means there is zero chance for sharing. If you are running 2-3 apps it's fine but I want a world where we can potentially have dozens or even a hundred little gui apps running & it works fine, no problem. That would be on par with native apps & this is a clear demonstration of one way we could get there.

The missing next step is that this system launches a mini http/websocket server to run. It'd be interesting to explore using a lightweight Sandboxing multi vm to host apps on, might make the server side lighter weight too. Wasm, or cloudflare's workerd... The CRI folk have been busy building support for managing work let like things like this, & desktop could definitely pull some wins, now that folks like Neutralinojs and Tauri are starting to do better at desktop webapps.

Hmm, that is a big difference, but if your program uses, say, 200MB, then I imagine it would be more like 208MB vs 242MB? But having lower overhead is still important for smaller things. Also I wonder how the memory usage is lower, is it because things are shared somehow?

Webkit is just a web page viewer whereas chrome includes a million auxiliary capabilities. Tab management, dev tools, history, account synching, the browser chrome, the complex url bar, it goes on and on and on.

Most electron apps don't use most of this code but it's at least mmapped in.

As for size, most web pages I visit are under 40MB. Suddenly 8MB Vs 42MB is a huge difference in overhead.

There's definitely been a trend of page loading tons of data & holding onto it. There's so many better architectures. Using http caching & just re-requesting pages of data on demand would be a huge architectural win for most pages. We can get fancier & use indexeddb or now sqlite, to let us free memory. The actual footprint of most pages/apps ought to be tiny.

That raises an interesting question of Neutralinojs, of how much of the incredibly good web shit we've built is available. A huge part of the Chrome size is that it supports hundreds of web platform APIs. Webkit doesn't AFAIK, it's up to the implementer to rebuild most of the Javascript APIs. It's gonna suck not having the ability to load your wasm sqlite on origin private file systems with a service worker cache layer web architecture to neutralinojs. I guess that's the massive mack-truck sized weakness I hadn't spotted with this whole plan. It makes me rather want something that can use whatever Chrome I have on the system, so disk & memory costs are low.

But on Windows it will be using Edge which is a Chromium fork with even more extra things to bloat the binary size, yet it still uses less memory on Windows according to the benchmark

There’s been a couple cases for electron-exclusive apps (no web app) where the devs don’t even test anything but the exact build of Chromium their version of Electron is using which I thought was bonkers. There’s no good reason for an app to be so brittle that it breaks with different non-outdated builds of the same engine.

Maybe I misunderstand but why is it bonkers if they ship the app bundled with the specific version they decided to support anyways? Would you commonly test an app against different versions of a dependency than the one you’re using?

If nothing else it means that they’re using old versions of Electron for extended periods of time — long enough that the app becomes dependent on the quirks of that particular build, which is bad with how many vulnerabilities regularly appear in Chromium and Electron.

Electron should be updated much more often than that, and barring major new versions with breaking changes doing those updates should be effortless because the app is resilient enough to not need particular builds of Chromium.

I’ve looked at things like tauri and the problem is always Windows. In general if you have a broadly distributed Windows app you must bundle or statically link everything. Even chained dependency installers don’t work since you have to keep them up to date, and fetching them online doesn’t work because it will fail in weird environments with filtered Internet access. All Windows installers must contain a microcosm of the entire universe.

I suppose if you could restrict to only Windows 11 it might help but there is still a ton of Windows 10 (and even 7!) out there. Does Windows 11 finally bundle Microsoft’s own standard C libraries?

I think the right path forward might be something like Sciter or Ultralight or even just a very stripped down version of Chromium. A web renderer is not that huge when it's stripped down and all the extensions and stuff a desktop app is not going to need are removed. You end up with something about as big as Qt or another cross-platform full stack UI toolkit.

Huh? Windows 10 has been shipping the C standard library for quite a while now, you don’t need to ship any redistributables... yes you need to static link the C++ standard library but that is also a requirement if you ship on Linux since Debian/Ubuntu always have horrendously outdated copies, heck I have customers that still use Ubuntu 16 that I have to support.

At the end of the day none of this is any different from shipping containers or flatpaks, which bundle all the dependencies with them. In many ways Windows has escaped the DLL hell that plagued it in the past, whereas Linux still has some learning to do.

It's fine to bundle everything - MSIX will automatically deduplicate everything even at download time.

https://learn.microsoft.com/en-us/windows/msix/overview

Honestly if you want to go this lightweight I think desktop PWAs are better suited, they’ve been around for 4+ years but are horribly underutilized

underutilized? Like the office suite, spotify, discord, teams, vscode...

Vscode is electron. Discord is react-native.

Discord Desktop is an Electron app with ui based on react, the same ui that you will get on the website. Only the Mobile Apps for Discord are using react-native.

Most of those are Electron, not PWAs. PWAs are very rare

Agreed. As much as I dislike the bulk of Electron this feels like the worst of both worlds: you get incompatibilities between different browsers and more difficult installation than with a PWA.

All of this stuff is only lightweight if Electron is the benchmark.

Exactly. Graphical apps are in such a sad state at present. I know the UIs look fancier, they have ML (sorry "AI"™), etc etc etc but so many of them are gluggy, high latency, JS heavy web frames.

Just because you can wrap some web frontend framework around some libraries and take some fancy screenshots of your landing page doesn't make the software good.

PWAs will likely continue to remain underused on desktop until they gain some important missing bits of desktop integration.

For example on macOS, Electron plugs into the global menubar, making it easy for web app devs to give their Mac users native menus instead of falling back to a redundant in-app menubar. Nearly all electron apps on macOS take advantage of this feature, and if they migrated to PWAs they’d lose it.

PWAs also lack fine grained control over window chrome which puts them in an awkward twilight zone between browser window and desktop integrated web app.

You can do this with github.com/webview/webview bindings.

- Golang server

- Use go:embed to embed the public folder of the frontend

- Open a webview pointing to localhost:ephermal port

Easy as pie, and less than a couple of kilobytes overhead.

I like the simplicity of this solution. Could you expand on it? Any examples?

I think Neutralino uses a similar architecture (without Go, obviously).

Will it work on windows though? Without any special installer permissions?

Golang can compile to windows statically, and on Windows those bindings are using the MSWebView2 API (aka Microsoft Edge webview).

I know that you can also compile the webview.cc into a dll specifically, and link against that. But I'd never done with Visual C++ because I am cross-compiling from Linux to Windows.

The README of the webview/webview project refers to the WebView2 SDK on NuGet, however [1]

[1] https://github.com/webview/webview#windows-preparation

Or even easier: https://wails.io. Uses Go, webview, and handles a lot of the build and hot reloading for you.

I’m a little disturbed that the “your first app” tutorial mentions changing security settings for deployment. From: https://neutralino.js.org/docs/getting-started/your-first-ne...

> If you are on Windows, you might get a blank white screen. The reason for this is, accessing localhost from a UWP context is disabled by default. Run the following command with administrative privileges on the command prompt to fix this.

> CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.Win32WebViewHost_cw5n1h2txyewy"

> You may include this in your Windows setup files (with the user's consent) because users also may get an empty white screen on Windows.

Can this be avoided?

Is this for development or deployment? Bothers me as well.

The last sentence talks about “setup” and “users”, so it sounds like both. It later mentions WebView2, but it’s not clear if that avoids the situation entirely…

I looked into some alternatives a while back [1] and thought Neutralino looked promising except that it doesn't support node modules. I.e. you cannot use the existing ecosystem of node-stuff.

Still, glad there are many options for using web UI to create desktop apps these days.

[1]: Neutralino themselves link to this nice comparison table: https://github.com/Elanis/web-to-desktop-framework-compariso...

The lack of node support is not necessarily a problem though. We can write an "extension" in any language (including js/node) which can communicate with the app over websockets.

https://neutralino.js.org/docs/how-to/extensions-overview

Oh, thanks. I hadn't seen this. This looks like it would be super useful for the "backend" bits

Why is this better than just using Dart/Flutter?

The introduction docs also claim "In Electron and NWjs, you have to install Node.js and hundreds of dependency libraries. Embedded Chromium and Node make simple apps bloaty. Neutralinojs offers a lightweight and portable SDK which is an alternative for Electron and NW.js."

Yet the installation here starts with NPM and depends on Node.

Sorry, but I don't see a significant difference between this and Electron just from the comparison chart linked in the docs. https://github.com/Elanis/web-to-desktop-framework-compariso...

Save for the fact that Neutralinojs is not listed as having any support for automated testing where Electron does.

The data there shows smaller and faster builds on empty apps but that doesn't count for much since no one ships empty apps.

Needs a fair comparison against its claimed competitors using app examples that at least mimic real world apps. For example, if building the typical kind of application people would build in Electron still results in a smaller deliverable and much faster build, that would start to make a case for a better developer experience.

Though I would guess that most developers would not switch and learn a new framework just to get slightly faster builds before considering test time. Integration test run times tend to take up most of the time in any build process.

I got the impression that node is needed to build but isn’t a dependency for the app you ship.

I think Flutter’s potential is being and will continue to be dampened greatly by Dart. It doesn’t matter how good Dart is or how similar it becomes to other languages, it still has unique quirks and an ecosystem to be learned which makes it in the minds of most too much trouble for what’s realistically a single-use language.

The only reason anybody bothers with Apple’s similarly restricted-usage languages is because they open up access to a whole set of platforms as well as a set of frameworks so wide and deep (Cocoa/Cocoa Touch) that it’s practical to develop a highly quality polished app with them without bringing in any third party dependencies, which I don’t think Flutter will ever be able to do.

With Electron, you ship practically an entire build of Chromium, which isn’t shared between other Electron apps. Neutralino uses system/shared browser components, similar to Tauri.

How you ensure the shared components are available seems more difficult, but it’s clearly more efficient for end users.

The development experience indeed uses the world's most popular JS tools (otherwise no one would use it), npm and node. But it looks like the server implementation is all c++ leveraging the existing we view framework to do it's thing. So the user footprint is indeed node-free.

Your line of inquiry feels semi hostile to me & I'd like a lot to see a little more naunce & moderation & tentativeness rather than all guns blazing.

Most of your post seems to be about developer experience, of whether developers need node or what the build time is. Personally I think the choices here are incredibly smart & sensible, make perfect sense, and do a great job to do the most important thing, which is give the developers enormous leverage to build a maximally lightweight & fast desktop webapp.

So here is the big question on Windows — can the final executable run when double-clicked or does it need to be given permissions by an installer?

Take a look at redbean server. How does it accomplish this?

TIL that besides the neutrino there is also a hypothetical particle called the neutralino. And there is (of course) also a framework called Neutrinojs...

Cf. https://tauri.dev

That links redirects to https://github.com/durban

How come?

maybe try https://tauri.app/?

Yes, sorry, I meant tauri.app

They link a comparison: https://github.com/Elanis/web-to-desktop-framework-compariso...

By those numbers it compares remarkably will against Tauri.

I hope the OTT isnt a bearer token but like a private key used to sign requests

Also:

Creating a portable application package#

The following guides are not documented yet.

Creating a portable application package for Linux Creating a portable application package for macOS Creating a portable application package for Windows

1 more js framework

I think it's less an Electron and more a Tauri/Sciter competitor (webview wrapper rather than browser engine)

I think there should be one of these app makers that uses the system webview and uses bun for the main process that is mostly compatible with Electron.

The first thing to install for Electron apps is SQLite. Curious how to integrate that in to Neutralino.

not for nothing... but from their comparison chart, it looks like .Net Maui is the better option:

https://github.com/Elanis/web-to-desktop-framework-compariso...

I think the biggest disadvantage is the absence of Node.js itself. The development costs (time or money) automatically increase with the absence of third-party library support.

Yes. Exactly what we need. Another bloated JS focused way to make non-native desktop apps.

mot that bloated, empty app is 1mb, definitely better than electron in terms of bloat

Reply on news.ycombinator.com