4 ms·

> 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 wi

> 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.

croes 4y ago
Exactly. Every update or non-update of the Browser can have consequences for your app.
meandmycode 4y ago
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.
- giraffe_lady 4y ago
  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.
  - postdb 4y ago
    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/ https://web.dev/storage-for-the-web/
  - r3trohack3r 4y ago
    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.
    - hell_monkeyo 4y ago
      The new svh (smallest vertical height) units will help you with that problem on mobile, Firefox will require a fallback vh though.
  - waboremo 4y ago
    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.
suby 4y ago
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.
pmontra 4y ago
> 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.
HelloNurse 4y ago
I don't want software from someone "just not built for cross engine work"; their ignorance is normally much more extensive.
- rwalle 4y ago
  "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.
  - HelloNurse 4y ago
    Lacking not only the incentives but also the skills to care about portability is a symptom, not a need.
mhuffman 4y ago
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.
- CJefferson 4y ago
  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.
  - szundi 4y ago
    I just open Chrome and then close. Why switch? Happens 1x a week.
    - resoluteteeth 4y ago
      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.
  - WorldMaker 4y ago
    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.)
flak48 4y ago
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
- yowzadave 4y ago
  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.
circuit10 4y ago
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
- rektide 4y ago
  https://github.com/neutralinojs/evaluation 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.
  - circuit10 4y ago
    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?
    - rektide 4y ago
      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.
kitsunesoba 4y ago
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.
- canadianfella 4y ago
  [dead]
- __jonas 4y ago
  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?
  - kitsunesoba 4y ago
    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.

croes 4y ago

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

meandmycode 4y ago

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.

giraffe_lady 4y ago
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.
- postdb 4y ago
  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/ https://web.dev/storage-for-the-web/
- r3trohack3r 4y ago
  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.
  - hell_monkeyo 4y ago
    The new svh (smallest vertical height) units will help you with that problem on mobile, Firefox will require a fallback vh though.
- waboremo 4y ago
  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.

suby 4y ago

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.

pmontra 4y ago

> 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.

HelloNurse 4y ago

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

rwalle 4y ago
"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.
- HelloNurse 4y ago
  Lacking not only the incentives but also the skills to care about portability is a symptom, not a need.

mhuffman 4y ago

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.

CJefferson 4y ago
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.
- szundi 4y ago
  I just open Chrome and then close. Why switch? Happens 1x a week.
  - resoluteteeth 4y ago
    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.
- WorldMaker 4y ago
  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.)

flak48 4y ago

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

yowzadave 4y ago
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.

circuit10 4y ago

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

rektide 4y ago
https://github.com/neutralinojs/evaluation 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.
- circuit10 4y ago
  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?
  - rektide 4y ago
    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.

kitsunesoba 4y ago

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.

canadianfella 4y ago
[dead]
__jonas 4y ago
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?
- kitsunesoba 4y ago
  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.