Hacker News new | past | comments | ask | show | jobs | submit login
WKWebView, an Electron alternative on macOS/iOS (holtwick.de)
197 points by ingve on Dec 26, 2018 | hide | past | favorite | 234 comments

This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.

* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.

* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."

* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host.

It also removes pretty much the only reason to use Electron despite its shortcomings - the ability to ship and run the same code on multiple platforms.

Secondly, you lose control of your application runtime environment version - need a new WKWebView version to ship a feature? Time to tell your customers to upgrade the app and their OS.

I’d maybe consider this to cheaply ship a feature inside a Mac app, but this really isn’t an option for like 99% of dev teams considering Electron.

It’s not the only reason. First of all: you can use JS and HTML with all frameworks. Some people consider it a superior solution for GUI. Second: you can easily upgrade your app on iOS without moderation.

We did this too, so many reasons. Lots of bugs, no printer support without using private APIs, etc etc.

It’s really not an option. That and you have to rebuild everything for Win/Linux builds. Just makes no sense.

Also you can’t ship your own updated WKWebView.

For what it’s worth, all of the arguments against your choices are inadequate and don’t really wrestle with the complexity of the domain. And I suspect the authors are not considering this as though they’d be the one responsible for making these decisions for a company like Slack themselves.

Fun fact: Slack has native iOS and Android apps, with all their platform-independent logic abstracted away in a C++ library. I see no “complexity” in making a native macOS app with this.

From a cost-benefit point of view there’s nothing in it for slack. They’d have to rewrite and maintain three separate versions of the same app they already have, and what would the payoff be? It would mildly please a handful of bellyachers, who would then immediately move on to the next grievance. For the majority of users it would be wasted money and effort.

My argument is that this is not actually all that much effort, and it would make far more people happy than you’d realize. While not everyone can verbalize their complaints about Slack, I’m sure many feel the performance issues; and they would certainly notice if Slack happened to load five seconds faster or their computer’s battery lasted a couple of hours longer.

I think you’re underestimating the work involved, plus switching from electron to native won’t make people’s battery last hours longer.

> I think you’re underestimating the work involved

This was the amount of work necessary for me to ditch running Slack in a Safari tab, and basically consists of being able to talk to people and send them attachments–the things I do 99% of the time. If I need something advanced like voice calling I’m more than happy to fire up actual Slack. Assuming libslack (or whatever it is called) handles the core protocol and communication layer, I don’t see why it would be difficult to write a bit of Cocoa code around it; I could even pull some of this straight from the iOS app.

> switching from electron to native won’t make people’s battery last hours longer

It does, though. Opening Slack on my computer reduces the battery life by around two hours; a well made native app will have a reduction that can be measured in minutes. Native apps are just better at idling and using fewer resources when they are in active use.

Which application as complicated as slack do you run 24x7 on your computer, with a persistent connection to a server updating the ui that only reduces your battery by a few minutes versus two hours with slack?

There sure is.

They've have an app that doesn't suck for one. Which you know, would help conversions.

Its not hard to write a Mac app, and its even easier to maintain it. ESPECIALLY if you already have an iOS app.

There is no reason not to just make a decent Mac app. NONE.

Using caps isn’t a substitute for having a point, nor is it a refutation of the effort involved to make three separate native apps instead of one. Also you’re not supposed to use caps here.

I don’t think it sucks, most users don’t think it sucks. You represent a tiny, vocal minority.

Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I recall reading years ago Dropbox trying this, but in 2018 is this really the best approach we have?

I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.

Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.

> Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps?

I think Microsoft Office does this too, and I’m pretty pleased with the results, performance and UI wise. In my opinion, this is probably the best way to actually do decent cross-platform development. One of the projects that I am tangentially involved in is doing this, but swapping out C++ with Rust.

> I recall reading years ago Dropbox trying this

Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO.

> I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android.

Generally, all the cross-platform, UI independent bits go into the framework, and then you write a thin UI layer on top of it using your platform’s native UI APIs. The benefit of using C++ is that you can call it easily from most languages.

> Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.

Ok, sure, but most of this work has already been done for their iOS app. I’m making a shot in the dark here, but I’d think that given access to their iOS project I could whip up something passable within a couple of months, if not less.

> Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO.

The opposite is the case. New components are typically written in Go on the backend, Rust in the sync engine and the respective native toolchains on mobile platforms.

I haven’t used Dropbox in a while, so I’ll have to take a look at it sometime. Is Dropbox back to using Cocoa again?

I was tech lead for a project that did this, about 7 years ago. C and C++ for all the business logic and core functionality. Objective-C, Java, and Qt for native bits. Worked great and was the obvious solution that allowed for shared code. I don’t see why you wouldn’t do the same thing today. The capability is still there.

I’ve lived through decades of promises of “write once run everywhere” development technologies but they have always come with significant drawbacks vs native applications. Performance, memory footprint, native look and feel, ability to take advantage of os specifics.

Facebook shares a huge chunk of core code between Android and iOS with C++. Even with Electron, VS Code also writes a lot of the core modules in C++. At the end of the day, it's just a clever way to write performant code that can be shared.

> WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium

It really doesn’t. A “Hello, World” WKWebView is a couple of megabytes. The same in an Electron app is hundreds of megabytes.

This is a useless comparison. Once you're hosting an actual app, the content matters way more.

Even if memory usage is the same, there's a world of a difference when it comes to executable size, and for most Electron apps, I doubt the content will outweigh the runtime.

I don't find disk space worth optimizing for in 2018. For $2 you can buy a USB Thumbdrive that will hold every Electron app you'll ever use.

Ridiculous. I have a 256 GB hard drive, which is pretty common even on new machines. I’m constantly having to delete stuff to make sure I don’t run out of room. It’s absolutely an issue.

Meh, I have an SSD of similar space, and the only stuff I ever have to delete is old Xcode-related data that refuses to go away. Periodically, some Rust build-related stuff I guess.

The litany of Electron apps don't even come close to being an issue (I arguably have more than the average person, too, thanks to every stupid crypto wallet from the past few years).

tl;dr you're making a mountain out of a molehill.

You assume that how you use a computer is how everyone uses one. Your molehill might be someone else’s mountain.

Mmmm no, this isn't really in line with my comment at all.

I'm hoping you have a 256 GB ssd. In any case lots of bad stuff is common and hoping the universe changes seems like a bad strategy seeing as a 500GB ssd is about $85 and a 500GB hd is like $30.

If you want more future proof a 1TB ssd can be found for around $150.

Unless you're on an Apple laptop. There's no upgrading of the components. And before the "you made the choice" guys start chiming in, some people didn't make that choice. If IT says "Dude, you're getting an Apple", then it is what it is. Just because "hard drives are cheap" is not an excuse to ship bloated software. At some point, the app has the features it is meant to have. At that point, it is a good time to refactor bloated code before proceeding to new features. The bloat will just continue, and eventually cause issues that come to a head.

Sure, but the issue there is the poor value offered by Macs (not hating on Mac, I also use one, but bang for your buck is absurdly low). If you have a non-Mac then you likely have a decent sized hard drive. While electron resource use is not ideal, on modern hardware it really shouldn’t be the issue that it’s being made out to be.

On the practical side, why not do as gp suggests and use an external drive? You’ll likely need additional storage with any of the lower spec’d Macs anyway, electron or not.

Of course I use external storage. USBC->SATA SSD has been amazing. Would love to be able to get a USBC->M.2 for the speed difference. Non-techy people that buy Apple might not though, and they're the ones installing stuff with little concern. It's easy to lose sight of the avg user.

single electron app is not an issue, especially high(ish) quality one (I'm positively surprised by low resource usage of messenger for desktop, I know it loads webapp from the web so local space usage isn't that big but RAM usage is also surprisingly low)

but if you have dozens of these it becomes a struggle even for high end desktops

the moment IT guy tells me that I respond with the letter of resignation

actually I'd do the same with any netbook, but being limited additionally by the OS is even worse

either I get the proper tools or refuse to struggle

That's a bold statement. Especially without knowing the full set of facts. In this case, with your stance, you'd be the only computer in the place not on an Apple device. It's a small video/photography shop. Everyone involved uses a Mac including the freelance guys that get hired.

What exactly are proper tools? I'm designing a set of web-based tools to help their day to day operations. Lots of shell scripting and what not to just allow people to drag-n-drop and automagically get things to happen, consistently. Are you saying that the proper tool to write php/css/js/shell scripts/etc can only be found not on a Mac? I have found the world becomes a much easier place to live in if/when you can just accept what is on hand and get the job done. Could it be better? Possibly. Is this my favorite laptop? Nope. Can I do what I've been tasked with to get it done? Absolutely. I'm actually quite thankful that I'm not a one trick pony and I can use pretty much any OS put in front of me.

I can use mac if I'm forced to do but my sanity is worth more than some extra money I can get doing so

and seriously, using slow and noisy machine with poor multitasking and overall terrible UX WILL slow me down considerably, it's not worth it also for employer

and you know what? I've done it before already and been the happy guy in the office laughing at all the trouble people forced to use macs had

EDIT: ofc if I'd know beforehand that mac is the only option I simply wouldn't apply to that place, there's no reason to make your own work lower quality

Since when can you not upgrade the ssd on an apple laptop?

As of the touchbar version, they’re now soldered on.

Excuse me while I laugh my ass off. Looking at the 15" pro with touchbar to name one model it starts at about $2400 with no upgrades. An upgrade to 512 can be had for $200.

In order to be in your position your company had to simultaneously overpay AND underpay. How can you be so cost conscious that you say nah give them the tiny ssd it costs less while shelling out 2400+ per unit

Why are you blaming us as users for a decision made beyond our control? Yes, we "get it" already, Apple is overpriced. I'm really happy for you that you get to decide what gear you use. Rubbing it other peoples faces really makes it better, so thanks for that.

I'm not blaming you just laughing at the absurdity of the matter not you personally.

Funny way of putting it, yet so true. My employer decided (without asking me) to get me one with 128GB storage. IN 2018!

You’re talking to the wrong guy buddy.

That got a downvote? For telling the other guy he was addressing the wrong user. Ha, it's actually funny.

It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs.

In the case of an Electron app disk space might not matter as much, but it's absolutely worth optimizing in 2018, at least because not everyone has high speed connections (e.g. in Germany, a lot of infrastructure is built around DSL, which obviously doesn't get great speeds).

You’re comparing apples to oranges.

3D models vs. app code.

You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Overall in 2018 that is not a big concern.

In gaming, high definition graphics are going to result in massively larger files. That’s not going to change anytime soon and no gaming company will prioritize a small download over better graphics.

> You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB.

Huh? Looking at my applications folder right now:

Atom 1.31: 822mb

Daedalus 0.8: 265mb

Mist 0.9.2: 186mb

Neon 0.0.7: 180mb

Patchwork: 185mb

Riot 0.11.4: 160mb

VS Code: 193mb

The electron framework alone is 117mb on MacOS. Honestly, how many copies of that do I need?

If you have 20 such apps, you use 1% of your 250gb SSD (which is on the way low end) on redundant framework copies, with the benefit that the developer gets to test on the version of Electron you are running.

I don't understand why apps don't download an Electron runtime on launch and store it in a shared location. That way, if apps share a required runtime version, only one copy of that version runtime exists.

carlo by Google Chrome team


Yes I know, and the size of an Electron app versus a AAA game is sometimes 3 orders of magnitude in difference, which is why I pointed out that even a "small" app that's 100MB is still a lot to download on a limited speed connection.

50MB isn't a big of a concern until you realize high quality native app would do it in less than 5 and probably in less than 5% of RAM usage

>It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs.

RDR2's size comes from media files (high-resolution textures, models, audio).

Pray-tell, what magic compression technique would you use to do better AND still support 4K textures?

A lot of space in some recent games, truly a bizarre amount has been in some cases dedicated to uncompressed audio.

Given that most people can't tell the difference between high grade mp3 and uncompressed it seems likely that this could be something like mp3.

I suspected you meant lossless, but no, Titanfall literally did include 35GB of uncompressed audio. Their reason was to lower the CPU overhead from decompression, which sounds like nonsense to me.

> Pray-tell, what magic compression technique would you use to do better AND still support 4K textures?

How about downloading textures and movies on demand in the background when you enter new areas? It's not like all that stuff is required for the game to start.

Given 55GB of data and the internet speed the average person has, the fact that most users will ultimately need to load most data, and the fact that a huge mass of users will need the data on day one this seems like a bad strategy.

tbh I'd use configurable installer: download only these assets you'll be using at worst case allow us to set up everything with full version installed and then cleanup

Sure. For the price of increased complexity, you can get something going (and in fact some games do do that, e.g. WoW), but to be clear, you're still downloading 55GB of assets. The game isn't actually any smaller, which is what OP was complaining about.

Also, this is why the big console makers are investing in cloud-consoles.

Hey, that's not fair to RDR2! I actually bought it the day it came out because it _didn't_ have a huge day one patch. I think it was only about 4 GB, which is barely a blip on my ISP's arbitrary data cap. Fallout 76, however, had a patch that was larger than the disc itself, so that was an easy "pass" for me.

Edit: I just checked, and even now that they've added multiplayer to the game (which didn't come on the physical disk), the patch for a new installation of RDR2 is 8 GB. Meanwhile, Fallout 76 is 50 GB and COD:BO4 is 65 GB.

Messages uses webviews and manages to do much of what Slack does with a tenth of the memory footprint. I still have not found any evidence for your claim that Electron and WKWebView use the same amount of memory.

You're literally comparing two completely different apps. If you want to compare Apples to Apples, host 5 teams in Slack, in both Chromium and WKWebView

Unfortunately, I’m in a place where I can test your argument, so the best evidence I can give you is the personal anecdote that I run Slack in Safari rather than using the Electron app for performance reasons. It’s not quite WKWebView, but I think it’s a relatively decent approximation. With that said, I still think you’re missing the point: it’s completely possible to make a messaging app that uses significantly less memory than Slack does and does basically the same things, even if you ditch native controls (which is not something I prefer people do, for reasons other than performance, but it’s something I am willing to tolerate). Loading an entire browser with its associated baggage rather than using the platform’s native web view will almost always use more resources, because you will have bloat that is not necessary for what you are doing and some features will end up being reimplemented in Electron. Just because Slack might perform poorly in both a web view and Electron (which I still believe is not equally poorly), does not mean that it could not perform well at all. There are multiple issues here.

There is of course value in comparing Messages-the-HTML-app to Slack-the-HTML-app. If they can do it in a fraction of the memory with comparable functionality, I wonder why Slack can't

Here's a simple comparison using nativefier (electron based single-site-browsers) vs something using WKWebView:


Both are playing low-quality HTML5 video.

For any sites I could think of, the memory usage, thread count, CPU time, and idle wake ups were considerably smaller using WKWebView.

The disk usage was also crazy smaller, as is expected. ~122MB for nativefier vs ~14MB for WKWebView (and a lot of that is due to being written in Swift).

What if I only have one team and a handful of channels, though? In that case I prefer starting with a lower constant memory overhead.

calm down friend

No personal swipes on HN, please.

There is a long history of sophisticated applications being written in less than a hundred megabytes, so where's the budget going? Hero images?

You made the original claim. Do you have any data to back it up?

Why doesn’t Slack write an actual Mac app in Swift? For small companies with limited resources, I understand the attraction of “cross platform,” but it would seem that performance and uasability would be vastly improved by writing actual native applications — especially for a billion dollar company that can afford to do it and especially since Slack is one of those apps that is constantly open and performance and efficiency have a real benefit.

They've cornered the market and don't have to care anymore.

A lot of Slack's audience is captive - employees, contributors to open source projects that chose Slack as their social outlet, etc.

The only way this will change is if Apple starts using more "stick" approaches. Marzipan and whatever other technologies they're working on are the "carrot".

Amen. “Cross-platform UI” has always meant “doesn’t work well.”

Yeah at this point they are basically jerks for not building something better. The reality is they dont have to care.

Telegram, an Open Sources IM, has Native Clients on Mac, iOS, Windows, and Android.

...ugly bridging code in Objective-C. I have had a similar issue getting the Unity team at work to use native plugins but they’re inability to be comfortable with C++ is not an issue with the platform but with the programmer. Moreover, the ugliness of the code is definitely a quality of the programmer!

Do you all have any plans to test out flutter with desktop embeddings? I see that the productivity is as fast as javascript based stack. Flutter desktop seems to be consuming way less RAM than an electron app. Is there any POC ongoing at slack?

Edit: Never mind, I misunderstood.

This quote was inside a list of negative experiences with WKWebView. It wasn’t intended to be positive.

Huh, I think I got confused when reading it, thanks.

If you throw out cross platform support it's hard to call it an alternative :)

Yeah, at that point the most obvious alternative is Cocoa!

It’s pretty cross-platform, if you swap out “WKWebView” with “your platform’s native web view”.

Just use gtk WebKit or qt WebKit and you’re good to go.

For the record, WebKit originated from KDE[1].

[1] https://en.m.wikipedia.org/wiki/WebKit

Should be QtWebEngine now, as QtWebKit is deprecated.

QtWebEngine embeds Chromium as its web engine, which means it is going to have the same performance and disk size costs as Electron. The circle is now complete and you might as well just use Electron.

Agreed except each app won't need a copy of QtWebEngine on disk.

Isn't qt webkit what the infamous pgAdmin 4 used to use? shivers

It would be nice to have an Electron 100% compatible framework (drop-in replacement) that instead of using Chrome, it would use Apple's webviews that are of course based on WebKit.

It would be faster and take much less RAM, specially when multiple Apps are open and they could use the shared library.

Also, now that Chromium is going to be part of Windows, the same would also be a good idea, I think.

So, every time Apple updates WebKit your app breaks. We've gone through this in the past. There are multiple reasons Electron is a win.

1. It's cross platform

   Don't have to deal with the fact that Safari is missing these 12 APIs or has different edge cases
2. It's stable after shipping

   Users get a new version only when you ship. If you use the native widget then users get a new (often broken) version on every update by a 3rd party (Apple/MS/Google). Example: chrome just deprecated autoplay. If that bubbled into apps your app just broke. Electron could do the same but if you're testing like a good dev that break wouldn't make it to users. You as a dev would find it locally, deal with it, and only after ship to users.
so, no personally I don't want a shared widget. that sounds like going back to DLL hell or worse, just broken stuff.

Doesn’t stable after shipping also mean that if a critical vulnerability is found in the version of electron/chromium that you’ve bundled, the user is vulnerable until you are able to issue a fix? What if the app itself is no longer updated?

How is that different than any native app? All native apps have that issue.

Native apps can benefit from using shared libraries, which can be updated in such case. Using WKWebView ensures that vulnerabilities are patched as part of OS updates.

On OSes with sane package managers (e.g. Linux distributions) native apps can share all dependencies, so there is no need to recompile/redistribute each application using affected library.

Sadly, there is no such thing on MacOS (excluding brew/port) and Windows (or even iOS/Android), and even native Linux applications are moving towards bundling all dependencies in a single package.

Typically a native application will depend on shared libraries (or runtime such as jvm, .net) which can be updated independently of the application itself. That said, if the vulnerability is in the application code, you are correct, there would be little difference.

If you use the "API's": standard HTML and standard JS, like a good citizen, I really doubt that would be a problem. And if it is, it's you job to update you app, also Apple provides pre-release versions with good antecedence.

Could you avoid using code blocks for text? They are very difficult to read on mobile.

blame HN, I didn't format them as code blocks. I put #.<space>text<cr><space><space><space>text which in any other context would be text not code

WebKit is free so you can bundle the library if you want. Or not.

What is the point in that now? It is going to be a similar size as Chromium. You might as well just use Electron.

As a matter of fact, Chromium's/Chrome's engine Blink was forked off from WebKit back in 2013. Current WebKit is Apple's not-quite-as-well-updated version of the engine in old Chrome.

Each Electron app comes with a very specific versions of Chromium and Node.js.

They can't run on native frameworks. If native frameworks are updated old apps would break. If native frameworks aren't updated newer apps would break.

What you're asking was already tried with Adobe AIR and failed. Instead we need lighter alternatives to Node.js and Chromium.

I'm really starting to think it would be a good PhD dissertation project to (semi?) automatically reduce Chromium to the bare minimum needed for a given Electron app. The techniques could probably be applied to reducing any library and would be of interest to researchers in SE and PL, along with industry.

That's not just tree shaking, that's more like rainforest shaking!

That's exactly what I thought. You just include what you use. Either developer does it on a confijguration screen, a tool does it with analysis on what code reaches what other code, or both. It would also help if Chrome is designed to make this easier.

eCos is prior work on OS side that made me always think of designing systems for easy stripping.


> good PhD dissertation project


would not existing static analysis/dependency pruning take care of it if someone had the time?

I don't see what would be 'novel' here from a theoretical point of view..

still a good project possibly though

That is the research of it, we don't know if existing techniques would work! And surely there are novel improvements that could be made, particularly for this specific application.

Also, I imagine there are many cases where static analysis would not be enough for the JS app.

Sounds more like an undergrad thesis.

An old man once said, "write the thesis you wish to see in the world."

Hm, would headless Chromium be a good starting point for this?

shameless self-promotion https://github.com/cztomsik/node-webrender

(not production-ready but it might be soon good enough for really quick GUI prototyping using subset of web technologies - javascript + react + flexbox + styles)

HMR & react-devtools are already supported.

This concern about breaking only seems true for the Node.js side. The HTML/JS/CSS running in the web view should be pretty resilient to version upgrades; web devs are used to defensive, backward-compatible design that handles multiple browser versions.

The bridge itself is API stable. evaluateJavaScript:completionHandler: isn't going anywhere.

So the question is whether it's okay to use a native web view while still bundling your own V8 + Node. That seems like an improvement to me!

The bridge itself is API stable. evaluateJavaScript:completionHandler: isn't going anywhere.

Historically, this hasn't been the case. Apple loves to deprecate stuff (although, thankfully, they are a bit slower to remove it). Before WKWebView there was a "stable" WebView.

And if my memory serves me well, you couldn't even use WK version with local files! Clearly indicating that was not the way to make UIs, but to browse the real web...

Or maintain backwards compatibility. You don’t need to remove deprecated API features, just mark them as deprecated. It would add some size but it’s better than the alternatives.

Flutter does this. https://github.com/google/flutter-desktop-embedding looks for your local version of chrome. Curious if anyone has thoughts on it.

Flutter doesn't use Chrome. I think you're thinking of Carlo[1].

[1] https://github.com/GoogleChromeLabs/carlo

I was, thank you for the correction

Half of electron is being able to leverage the Node.js ecosystem and Chrome APIs. Creating a "drop in" replacement would require a ton of work and constant keeping up-to-date.

> leverage the Node.js ecosystem and Chrome APIs

Aren't those fairly discrete areas with fairly different levels of work? Doesn't most of what's on NPM run in WebKit / Gecko these days, anyway, since people commonly deploy client-side?

Having a shared electron runtime on each platform is an answer to some of its performance-related criticisms. Hopefully this is what Microsoft are going for with chromium and the github acquisition. There would still need to be compatible equivalents on Mac and Linux however, or it would render the endeavour pointless.

> a shared electron runtime on each platform is an answer to some of its performance-related criticisms


Given that electron is not chrome, no, not chrome. A specially made, backwards compatible chromium/node/whatever bundle, that developers can build against without fear of having their apps broken by future API changes.

Yes, that's the only answer, and it's a good one! It will be great and benefit everyone if Microsoft can pull that off on all platforms.

Check https://terrainformatica.com/2018/12/23/sciternode-versus-el... and discussion: https://news.ycombinator.com/item?id=18746408

In principle that is doable. Not sure about 100% compatibility as only WebKit (particular version) is 100% compatible with WebKit (particular version here). Edge is gone in that fight. Mozilla is standing but is not 100% compatible.

Aren't those just called PWAs these days?

This reads like someone hired a consulting firm to send out surveys asking why people don't like Electron apps, without really understanding the problem.

None of the four bullet points actually address real issues. The security problem isn't that Google is bad at security (they're among the best really). The problem is that Javascript code is generally written with the expectation that it will run in a web browser's highly locked down security context. Performance is really the same issue: web apps are authored wastefully. For use cases where you visit a web page for a few minutes then leave that's fine, but when you then let that code run for hours with no sandbox you will inevitably hit perf issues.

Write native apps. If you can't afford that, just make a web page.

Electron also has a lot of hardening features from chromium disabled as is strongly discouraged by Google as unsafe to use for apps.

This seems to be changing as of recently this year. There have been many security-related changes including making options such as Node integration disabled by default [1]. Support for renderer process sandbox is also available [2].

[1] https://github.com/electron/electron/pull/14284

[2] https://electronjs.org/docs/api/sandbox-option

Almost nobody can afford that, not anymore. If your application can be written in Electron and provide 80% of your features, someone's going to do it and eat your business alive. Especially if they can figure out how to leverage network effects to use their users to drag your committed users away.

Unless you have a core feature that _can't_ be implemented in Electron for some reason (I guess you're writing a game or something similar?), or have some other mechanism for locking your users in, writing a native app in 2018 is just putting your employees livelihood at stake.

It's not cool or fair at all, sure, but hey, us Marxists were telling you this will always happen for over 150 years now, and y'all still acting surprised.

All else being equal, native apps will always be better. Higher performing and longer lifespans. It’s like Winamp; simple, extremely fast, 21 years old and still kicks the shit out of modern music apps. Of course, if you can’t write well in native you shouldn’t.

> All else being equal, native apps will always be better.

I didn't write this wasn't true; I wrote this didn't matter.

Edit: to expand on this a bit: sure, most of the throwaway Electron applications won't have much life in them. But they'll suck the oxygen out of the room and kill everything else first, then fail. So if there was any livelihood staked on those superior native apps you made — well, those people are looking for jobs now. Hope all of them have it as easy as a young software developer.

> most of the throwaway Electron applications won't have much life in them. But they'll suck the oxygen out of the room and kill everything else first, then fail.

I agree, and this is the other reason I dislike Electron apps. Not just because of the utter disregard for user's computing resources, but also because of the damage those apps do to their surrounding ecosystems. It's hard to compete against people who can secure money faster than you by cutting corners and dumping waste on everyone else.

It's yet another example of "worse is better" causing a setback in the industry.

Yea, Winapp totally won the music app wars! Oh, no, Spotify seems to have won and AFAIK it runs in an HTML based UI even in it's "Native" app. No idea if it's electron.

So the parent seems correct. Winamp stayed native an lost. Spotify embraced the rapid dev that using a browser host brings to app dev and won.

The thing about Electron - and the thing that Electron fanboys either don't realize or don't care - is that with Electron, the company/vendor wins at the expense of users, who have to put up with their "application". No one really likes Elecrton apart from the vendor/developer and the most fanatic fanboys. Everyone else at best doesn't mind Electron.

If an Electron "application" is decent, people typically like the features or the online service to which it's tied but its Electron base is something that people more or less tolerate, depending on the degree it irks them. It's just a huge tradeoff, that's all. It reminds me of some Java or Python desktop applications, it's a similar kind of tradeoff.

Hopefully it'll pass just like the previous fads.

The other bonus of Electron (from a user perspective) is it lets companies release software for Linux too. For maybe the first time in history, Linux now gets a release for all these major mainstream services/companies -- I can now have VSCode, Slack, etc. on Linux and they work well. I've been on Windows and Mac for years and in recent years using Linux finally feels modern and viable. I'm not sure if VSCode/Slack would even create a Linux client if Electron wasn't available.

Disclaimer: Not an Electron fanboy, I don't even develop Electron apps. I do enjoy using a Linux dev laptop, however, and am not a hardcore vim/emacs guy.

Yeah, typically users are mildly annoyed by electron applications because they either don't fit into the basic style of the OS or suck away RAM. They stay because of the service, something that is provided (the walled garden usually)

Which is why electron is so popular. I'm sure the whole "it's way easier to whip something together that kinda works" is correct in the short term. You whip something up and rely mostly on the hype and viral marketing to drive your app.

Yep, no one likes Spotify. No one likes Slack. People are just putting up with them. Except not really, a few loud mouths complain, most users are totally happy.

I never said people didn't like Spotify or Slack. In fact, I said the exact opposite. Please read the comment properly and try to understand, don't just skim checking for "the right" opinion.

Winamp won far before Spotify was even a contender. It won in another time. Spotify is winning mostly because people don't want to spend money for songs anymore and they don't give a damn if they own them. Which is not to say I don't like the practice, it doesn't matter to me.

They frequently didn't spend money for songs to start with they just stream them instead of pirate them which however much people complain about the revenue is certainly more than the zero they got from piracy.

The degree to which people didn't want to pay for music was kind of obvious when people needed mp3 players sufficient storage that filling them legally would have required as much money as a down payment on a house.

Desktop multimedia players are still a thing they don't even really compete with one another.

Spotify and Pandora are for letting you play a service's music. Winamp and 17 bazillion players are for letting you play a collection of digital music you control.

Spotify is Chromium Embedded, IIRC.

MacGap framework [1] builds on the same idea. In fact, it predates Electron and was being used by Slack. The size of the compiled binary would be just ~350KB.

[1]: https://github.com/MacGapProject/MacGap2

Wow, I used this in 2012. I think it was originally written by Alex MacCaw of Clearbit.

I still live in the world of heavy desktop native apps (WinForms & WPF) and one thing I've never been able to understand about all of these Electron discussions is what benefit does Electron bring in the first place? Why not simply run the application and connect to it using the local browser instance? For convenience a link can be placed on the users desktop.

It sells the dream of using web developer skills on the desktop, for those who want to develop native apps but don't want to learn new tools/languages.

Square peg, round hole. Electron just gives you a hammer to make it fit anyway :)

It also sells the dream of writing an app that works on multiple platforms. The web is good at this but depending on what your app does you might need more. For instance, in Electron you have access to Node. This lets you do things that you wouldn’t be able to do in the browser. It would let you do lots of things but for example: access local file system, use SQLite or some other storage without requiring a network connection, add an icon to the menu bar or taskbar on Mac/Windows, you could even control a users mouse for something like screen sharing.

I write native applications, cross platform (I generally make releases for Windows, Mac, and Linux), and cross-compiled using FPC + Lazarus.

No trickery, no hidden browser windows, just normal native executables.

Java also solves the cross-platform issue, though it's GUIs tend to not look native (As opposed to Lazarus above, which is native).

If you're impressed by a webserver being able to interact with the OS for things like accessing files or databases, your mind will be absolutely BLOWN when you learn real native development.

You’re making an assumption I haven’t already learned real native development but that’s besides the point.

Java does solve part of this but some people would rather use JavaScript than Java. Even if they know how to use both believe it or not.

However, if one of your platforms is the web browser, nothing is going to work better than a web view if you want a cross platform solution. Slack for example works almost exactly the same in my web browser as it does in electron. If you want a solution that works on Linux, MacOS, and Windows AS WELL as the web browser then the web view approach is pretty obvious.

Lastly the JavaScript web development experience is great with hot module relacement and Chrome’s developer tools. Not to mention the JavaScript open source community is amazingly strong and there is a lot of innovation going on. To simply dismiss all of this because of personal reasons is fine by me but I don’t agree with your view.

“It works the same on the desktop as it does in my web browser” is an indictment, not a feature. People use cross-platform toolkits because they don’t want to do the work to fit in with the platform their user chose, not because they confer any advantages to the user.

That is certainly one way to look at it. I'll propose another way to see it: There are always trade offs. For example, you could hire enough people to simultaneously work on a Mac OS version, a Windows version, an iOS version, an Android version and a web version of your product. Of course this is going to cost a lot of money and this cost will be passed on to the users. If the users prefer the subtle differences between the UI in platforms so much that they would prefer to pay more for a product than that would be an advantage. Otherwise that is a disadvantage. Potentially a really big disadvantage. There is also a case to be made that some people would definitely want the product to work the same in the web browser as it does on their desktop. Slack is a good example of this. I don't want to learn a new user experience for the moments when I'm on another machine without Slack installed and I just want to respond to a comment quickly, I'm very happy the web experience and the desktop experience are similar.

Making absolute statements about why people make certain choices or believing them can definitely lead to false conclusions. People don't only use cross platform toolkits because they do not want to do work. Sometimes it is the best solution given the features and constraints. I like to think of it as being pragmatic.

>If you're impressed by a webserver being able to interact with the OS for things like accessing files or databases,

I don't think anyone is "impressed" by it. It is just useful. The point of electron is being able to write javascript applications that run on multiple platforms.

Using Lazarus (and Pascal) means you need to learn another language to write native applications from the one you use to write web applications.

I'm not taking a position here, I am just pointing out the pros and cons. I am neither a javascript nor pascal programmer so I have no dog in this fight.

Lazarus looks quite cool, but I don't see it addressing mobile app development, which makes it a non-starter for me. Electron doesn't support mobile directly, but the web app built for Electron can also be packaged in Cordova (or similar) for Android and IOS.

You CAN do mobile, but those platforms are not well supported (Work is ongoing and improving, but not good enough to rely on yet, imo)

This is the best description of electron and related technologies in a very long time, possibly ever.

Thank you.

Running a server app and pointing your browser to it may work for you. Less sophisticated users will struggle with this approach starting with coordinating two things. You are also getting some bundling advantages with it - in particular electron contains node (and the right version with which the app was tested) which is also not a given on innocent users computers. Last but not least one gets support for building bundles for multiple OS platforms.

Java apps on the desktop became more prevalent and usable when Java was bundled in. The Electron is not so different from what worked for Java.

You get access to some features that a browser doesn't allow like better access to a file system or taking a screenshot.

Plus it gets rid of visual clutter like the tab bar and treats your app like an actual application rather than a simple website for viewing.

How is that a selling point though?

People using desktop toolsets never even have to think about that "problem" because it just doesn't exist when you're using the right tools.

There are three types of tools for every job..

* The right kind

* The wrong kind

* The wrong kind but we'll make it work

Electron hits squarely in the third category by hiding the browser and webserver and pretending it's a real desktop application.

It’s all about cross platform support. The reason you will see advantages listed this way is because the web browser is the real competitor here. So when people talk about what Electron can do they are comparing to the most obvious alternative of a web app.

The web browser is not the real competitor here, that's a web developer fallacy if ever I saw one.

As soon as you move to the desktop, you're competing with the desktop toolsets.

People comparing Electron to the browser is missing the entire point of what Electron is for, which is pretending to be a native application.

You’re also competing with native mobile tool sets on native.

If you want to write software for a platform, write software for that platform. Don’t write software for some other platform, try to make it fit, and then declare it good.

Pretending or just ignoring because Electron is 95% developer benefit and 5% user benefit (only because the app might not exist otherwise).

The web and its technologies are far from stable, cheap and simple to learn. And browser-based UIs are pretty much where native UIs were 30 years ago, just a bit slower.

Cross-platform: yes, if you ignore the fact that there are only 2 browsers left, both being buggy and incomplete (as they've been for many years) and with no other implementation in sight, or even remotely feasibly for small to medium-sized companies or teams. Also they're so bloated and isolated from the native environment that you might just as well install a Linux virtual machine and call it a cross-platform UI.

No, thanks. I'll wait for a better cross-plattform UI solution.

> pretty much where native UIs were 30 years ago,

In reverse, I would argue, Hundreds of "Native UIs", most of them obsolete or dead, have shown to be incapable to express cross-platform, flexible layout capabilities of 1990s HTML/CSS combo.

The most recent, yearly updated mobile OSes appear to be cooler, however we'll see in 10 years how they will end up.

> In reverse, I would argue, Hundreds of "Native UIs", most of them obsolete or dead, have shown to be incapable to express cross-platform, flexible layout capabilities of 1990s HTML/CSS combo.

But most haven't. If you want the capabilities of the HTML versions unable to even center vertically or requiring invisible images to format tables, there are plenty of UI to choose from. Qt, Wx are extremely capable nowadays.

This isn't an actual critique, it's just dismissal. "Buggy" is just an adjective. Don't do this.

I don’t understand why the entire browser engine needs to be bundled with each app.

Why not have libchrome or a libelectron that moves more slowly than chrome six week release cycle (maybe do 6 months) then have apps build to it and share the library.

the entire browser engine needs to be bundled with each app

No. It depends on the package manager. E.g: https://www.archlinux.org/packages/community/x86_64/electron...

A shared electron package used by a few different apps: see the "required by" column...

As electron gets more popular, this will be the standard in Linux distributions (at least historically thats how dependencies handled there), Windows has different standard (self contained everything) so there it is the normal way - everybody already used to it for decades...

Developers target a runtime with very specific APIs. If the runtime changes developers wouldn't even bother to write the apps.

If Electron apps would specify requirements instead of bundling the whole runtime, you will have to wait for the runtime to be downloaded the first time the app runs. You will still end up with multiple versions of the same runtime running on your system.

Is it possible to stabilize the runtime or is it moving too quickly?

Not for all applications, but for enough applications to make it well worth it.

The most obvious Electron alternative on any platform is of course doing things the way we sort of used to: Get your toolkits and compilers out, your hands dirty, and your integrity clean and code some honest to God desktop applications.

If you absolutely need to do web primitives inside your app, well then, html engines used to come in a few megabytes and no external deps. If your webcode needs the entire Chromium monstrosity bundled in order to run, someone has been doing something entirely wrong.

I obviously prefer to use native apps as well, but your comment sounds like some sort of bizarre moral judgement, not a rational programming decision.

In a way, it is a moral issue.

By choosing to go the Electron way, you're imposing a huge computational penalty on your users, just to make your life easier. Now multiply the overhead by the number of users, and that's how much electricity your decision just cost globally. This also manifests in frustration, like due to decreased battery life on laptops. And with enough popular software written this way, this pushes users to replace their perfectly good computers earlier than necessary.

(The lats point applies to web bloat even more; I'm really annoyed when a non-tech person asks me for help, because their computer "works slow, it must have viruses", only for me to discover that the computer is perfectly fine, it's just their favorite pages went through another rewrite and are now each 5x more bloated than they used to be.)

You are probably right, I'm being highly subjective. I loathe the entirety of Electron & consorts with real passion, retrograde, unfashionable bittweaker that I am.

Especially when the OS vendors are at fault by each pushing their own API for the same thing to wall their gardens.

We can only defeat that by having another awkward "OS" in a VM which browser/electron is.

I don’t like walled gardens any more than the next guy, but it’s easy to push this argument into absurd territory. Are OS vendors required to offer identical APIs, to the point where it’s immoral for them to have differentiated functionality and useful features? What is even the point of having different operating systems then?

Common APIs between operating systems also introduce the common denominator problem: if OS vendor A wants to add some cool new API for third party devs to use, they have to wait until other OS vendors also implement that API, otherwise they risk other OS vendors never implementing it and devs never using the API.

Or, as jacoblambda wrote several comments above, just use Qt.

The most obvious counter-argument: one shared codebase vs. your five.

Native is awesome when you have the money.

Not exactly. I am building HTML-NOTEPAD (https://html-notepad.com) from the same sources ( https://github.com/c-smile/sciter-sdk/tree/master/notepad ) for all desktop platforms.

It uses sciter (https://sciter.com) which is sort of micro-electron if you wish. Distribution of the app is 2mb rather than 200mb.

People have been writing shared codebase apps for decades even before the Javascript craze.

What do you think the cross-platform browsers you're packaging in Elecron are written in?!

> What do you think the cross-platform browsers you're packaging in Elecron are written in?!

The cross-platform browsers are written in a whole lot of platform-specific code.

False dichotomy. There are plenty of ways to share code across these platforms, without writing everything in JavaScript.

Meh, I write cross platform applications, single code base, and compile to native executables on Windows, Linux, and Mac with no problem and no extra Chromium bloat.

FreePascal + Lazarus.

I've done delphi in the past but I haven't heard about it for a while. How big is the community nowadays? What about libs? Package manager? Dependency-hell? Unit-testing frameworks and other toolings? How easy is it to stop the whole application and inspect everything, evaluate some code in parent stack and see if the issue was resolved so that you know exactly what to do?

It's not only about GUI designer and fast cross-platform compiler.

Online package manager can search, download, and install packages.

I have libs/packages for everything I need, dunno about your needs.

Not sure about the community size but it's plenty big and plenty helpful, lots of cool new stuff going on.

Plenty of debuggers available and you can pause things and inspect stuff.

Lazarus has seen loads of updates the last few years, it's worth taking the time to set it up to fit your needs and learn the shortcuts.

How do I run that on web, the most important platform today? I'm also not aware of any comparable community like Node.js has.

And I say that as someone who was writing Pascal professionally ~5 years ago.

We're not talking about web applications, we're talking about Electron.

But sure, if you want to do Pascal on the web there are things like Smart Pascal.

We're talking about ways to do multiplatform applications, which includes the web. You suggested Pascal but that doesn't run on the web without changing the code. Enclosing the application in Electron shell does not mean it's the only way it's going to be ran, actually most of the time you do it because you already have a web application and a server.

You can't run an Electron app on the web without changing code either, seeing as it's a browser AND a webserver combo.

You also don't take a webapp and separate server and just drop the two into a folder and run it as an Electron app without changing code

Not true. You can code the app in a way that allows you to share code completely between web, server and Electron app; there will just be a little boilerplate in the Electron app around it.

Much less difficult if you follow basic software engineering practice when writing your software - split out platform-dependent parts and abstract them away, write remaining 90%+ of your codebase without worrying about the platform.

The day OS vendors come together and standardize their API's, much like browser vendors do, I will build apps with native code.

Well Qt is pretty much there for desktop. Almost everything can be done in a relatively straight forward, platform independent way as long as you aren't doing mobile.

>as long as you aren't doing mobile.

That to me is the biggest issue. There's "cross platform" and there's "cross platform".

QT gets you the major desktop platforms, but not a ton more.

The web gets you desktops, mobile phones, tablets, game consoles, TVs, car infotainment systems, even my fucking watch!

Obviously you aren't going to handle all of those without some custom code for a few platforms, but when the web is a target platform for a project at all, it's often worlds easier to just spend the time on improving the mostly single codebase rather than try to do multiple codebases. And I genuinely believe that outside of larger companies, having the whole company dedicated and focused on improving one codebase is going to end up with a better user experience than splitting those same resources up over several codebases.

If your app is desktop-oriented only, then Qt is such a fantastic system to work with! But it's increasingly rare that software targets desktop only.

My problem that I find is that mobile, consoles, TVs, car entertainment systems, watches, and so on all need fairly distinctly different UIs from desktop and if you have to redesign the entire UI for them anyway, then why not do it in a native system that handles them well. Odds are most of the heavy lifting will either be fairly trivial or done in a separate back-end be it on a server or locally. At that point it doesn't really matter what you write the front end in as long as the back-end has a decent API.

Also quick edit: A number of car dash UIs do actually run on Qt and Qt does support mobile but Qt does its own compositing instead of the OS.

Can you give an example of a good Qt application? The only one I’ve used recently is VirtualBox, which is terrible, but I don’t know if that’s Qt’s fault or not.

The Battlenet launcher from Blizzard is a decent app that suprised the hell out of me when I found out it was Qt. Some others are Maya, EAGLE, Krita, Mathematica, VLC, and Dolphin emulator.

There are multiple libraries that give you just that with significantly lower footprint than a full browser engine (which is just a horribly inefficient blob of bloat you're trying to use as a cross-platform shim).

FPC + Lazarus, single tool with cross-compilation.

It's not like browsers all got together and agreed on a standard API, literally every browser does things differently from the others.

uhm, browser vendors literally got together and standardized APIs. That doesn't mean there's no bugs or unspecced territory in the current implementations. Obviously these need to be solved. Through more standardization.

> someone has been doing something entirely wrong.

Agreed. Seems like there is no alternative, though; what you said in your first paragraph definitely is not a comparable alternative except if you're handing out money my company could use to do what you suggest.

Let's move away from hiding browsers in windows and pretending they're not browsers hiding in a window.

FPC + Lazarus, native executables, cross platform.

You’ve mentioned this several times now as though it’s some magic sauce that everybody is missing.

But it’s not like FPC/Lazarus is the only portable GUI solution — Qt, Fox, Swing, SWT, Gtk etc. also exist, and don’t require a fringe language (and I say that as someone who did Turbo/Borland Pascal and Delphi development for more than a decade). What Lazarus offers is a Delphi-type form builder tool, but that seems a lot less interesting in this day and age of heavily customized UIs that aren’t static grids of square components — in particular, we increasingly rely on responsive layouts and smooth animations between them.

Moreover, I’ve yet to see a FPC app (or any app for that matter that isn’t Electron or web) that doesn’t look like an old fashioned Windows-style GUI app. Do you have any examples?

It's not magic sauce, it's a counter-point to the "Electron gives you cross platform deployments" argument.

Yes, there are many GUI toolkits, the LCL creates native applications while some others do not, but it's certainly not the only one.

It's the one I prefer so I use it as an example over QT, Swing, JavaFX, etc.

Lazarus form builder let's you create forms very quickly and easy, and OS themed design.

If you want other types of GUI designs you can do that too, though personally I prefer standard OS design.

As far as static grids and square components, I think you're looking at old stuff..

You can make things as squiggly as you like, and of course you can always use images and colors to design your GUI and let your imagination run wild, and it'll look entirely non-native.

Responsive design isn't that challenging either, use anchors and smart design.

I don't have any examples of desktop applications I've made, that look like web-apps, no, but I might make some after you giving me this idea, and I'll be doing it with FPC/Lazarus.

I’m still not convinced that it’s relevant to the discussion — it’s an old-school GUI builder, Electron isn’t, and it’s a bit of an apples-to-oranges comparison.

People gravitate to Electron not just because you can’t build cross-platform apps in it, but because the underlying UI tech is just the web. You can even do as Slack did, which is to offer the exact same app in the browser. You can’t do that with FPC/Lazarus. The latter is geared towards fairly static layouts, not the kinds of snappy, fluid, single-window apps that Electron is used to build. It’s just a very different world.

Nobody is doubting that you can build decent Windows-style apps with FPC/Lazarus, just as they’re not doubting that you can do it with Qt.

It's arguably the most advanced gui builder available.

As for snappy, fluid, single-window apps that is 100% doable and up to the gui developer.

It's not hard to use groups and switch between views, and make things dynamically resize or move around.

QML apps look modern and quite good really.

Pascal lost the language war, just like countless other "good" languages. Fantastic that it is working out so well for you, but you are the exception here. You're visible because(at least today) you've managed to post about it 3 times on HN that I have read. Maybe you've posted even more that I haven't seen yet.

Random searches in "dice.com"(pick any job site you want) for "Pascal" yields 5 positions. "Python" yields 8,950. "C++" yields 6008. Even "8086 assembly" yields 1,378 jobs. "Java" yields 17,000+. There is a trend here if you care to see it.

You are obviously passionate about Pascal. That's awesome. Keep using it, and squeeze it for everything its' worth. Please don't be disheartened when technology moves on without you though, often in directions that feel "wrong" to us. Electron feels wrong to me, but it doesn't matter. Technology is going to move where technology is going to move, and sometimes you have to get on board with choices you dislike to avoid being left behind entirely.

PS: I cut my teeth on Pascal in the early 90's, and wish it had become more popular as well.

"Moves on without you", I work in CFML, JavaScript (including various frameworks and engines), Java, Object Pascal just about every day, I've released code in many more languages professionally.

I'm using Node.js right now along with AWS for example, not my favorite combo but it's an appropriate solution being used as a webserver.

I've posted about FPC because it's one of the right tools for the job and the one I prefer over C/C++, Java, etc. for desktop applications.

I don't mind spreading the word about FPC, but really what I'm trying to push for is that there are appropriate tools for desktop development such as C, C++, Python, Nim, Go, Object Pascal, and a bunch more. I just happen to like and push for one of those.

Especially with the "benefits" for Electron like cross-platform deployments, are things that other languages such as Java or Object Pascal, also does and does pretty dang well.

Recently there has also been some interest in making chrome usable as a runtime to load web content as/in native apps, especially since with native webview the experience would vary across different platforms (windows 10 below will try to load it on ie!), i was working on https://github.com/SiDevesh/Quark-Go using the cool https://github.com/zserge/webview library, recently started redoing it with https://github.com/GoogleChromeLabs/carlo

The author is wrong in one point, Electron is not based on Chrome, it's based on Chromium, and you don't need to trust Google because it's 100% open source.

By default, Chromium still integrates heavily with Google services. See project ungoogled-chromium for details: https://github.com/Eloston/ungoogled-chromium

Since when does electron make you log in with Google?

Integration with Google services does not require logging in to Google services.

For a benign example: using Google search

For a less benign example: your browser/device/network being tracked for ads when using Google search

Electron is not a search engine or a browser, and it does not serve ads.

Google Play Services (on Android) is not a search engine or a browser, either.

Google Home does not serve ads, either.

My original comment's grand-parent did not claim if Electron was a browser or a search-engine, or if it showed ads, just that it is not necessarily independent of Google services just because it's built from Chromium.

The problem with electron isn't electron -- it's the standards that it's built on. Replacing one flavor of it with another doesn't move the needle significantly.

I posted this earlier in an Electron discussion, but there are a couple of libraries that take this approach cross-platform, like zserge/webview [1] and Tether [2].

[1] https://github.com/zserge/webview

[2] https://github.com/quadrupleslap/tether

Rails Turbolinks utilizes this technique for iOS: https://github.com/turbolinks/turbolinks-ios

Video explanation/demonstration: https://youtu.be/SWEts0rlezA

Cross-platform is the key problem.

If I want to write a Mac-only app, I can do that in Objective-C/Cocoa, and be quite happy.

For Linux, native means fighting with primitive C and X11 or Gtk, etc., which I can do but I loathe it.

For Windows, I have no idea, C# maybe? I'd rather eat broken glass than install Windows and find[ed.] out.

So if I'm doing cross-platform, my current working choices are Electron, Java, FreePascal/Lazarus, or Scheme.

Electron's easy to build all three platforms on, performance is OK despite the bloated example of Slack.

Java would need to bundle the JRE everywhere, and I've been largely Java-clean for 10 years.

Lazarus is semi-broken on Mac currently, only 32-bit like stone age tools, Cocoa port is unfinished. Maybe they'll get their shit together someday, I like it when it works.

Scheme native binaries are hard and experimental, but getting better.

Using a WKWebView on Mac, then writing a completely different wrapper on Linux & Windows, is unacceptable for my uses.

So my actual shipping code is Electron.

Electron and other wrappers are just shit in my opinion as these consumes a lot of precious resources.

Maybe devs instead of being lazy suckers could start to worry about this aspect.

Give it a few years. We’re at the limits of what’s photolitographically possible with silicon. As soon as Moore’s law halts all this wasteful crap will go down the shitter.

This is perfect for writing compact and portable web apps. I built a basic chrome that runs an index.html page and everything linkable after that and all I have to do is inspect myweb.app file and change whatever html, css or js I want. Simpler impossible. And with a little help from Swift I can have all the power of macOS in my hands.

It is neither a hammer nor a nail, it just works for some specific purposes.

This is how Apache Cordova (previously PhoneGap) works.


WkWebView is a huge improvement over UIWebView on iOS or WebView on macOS.

However on macOS it is missing one important feature (to me at least) that used to work with WebView:

You can't capture the image of the web browser window any more.

You used to be able to go something like:

    NSBitmapImageRep *bitmapdata = [view bitmapImageRepForCachingDisplayInRect: bounds];
    [webView cacheDisplayInRect: bounds toBitmapImageRep: bitmapdata];

    [NSView cacheDisplayInRect:(NSRect)rect toBitmapImageRep:(NSBitmapImageRep *)bitmapImageRep] 
But that's a synchronous API, and since WkWebView runs in another process, it requires a remote procedure call, so Apple simply returns a blank image from that call now.


I think the iOS way of capturing a screen snapshot from WkWebView still works, though, but I can't remember off the top of my head...

However, Apple added a new method to Safari, but last time I checked it was only in the beta Safari and not supported in the version installed on the operating system. (When you make a WkWebView it uses some specific framework that's not necessarily the latest beta version of Safari you've installed.)

//iOS func takeSnapshot(with snapshotConfiguration: WKSnapshotConfiguration?, completionHandler: @escaping (UIImage?, Error?) -> Void)

//macOS func takeSnapshot(with snapshotConfiguration: WKSnapshotConfiguration?, completionHandler: @escaping (NSImage?, Error?) -> Void)

But the problem with this method is that it takes a totally different rendering path ("this is a software painted snapshot"), so some stuff may look different, and WebGL stuff doesn't appear, and it's a whole lot slower than cacheDisplayInRect used to be).


This bug describes the problem and the issues and the less-than-ideal solution:


Summary: [Cocoa] No reliable way to get a snapshot of WKWebView

I hear a lot that WKWebView is an improvement, but all I see are some pretty significant limitations compared to WebView:

- no screenshots

- no printing

- no user stylesheets

- no cmd-F find

- no delegate method for hover-over-link

- no access to container NSScrollView (on macOS)

- harder to customize context menu (AFAICT)

- ignores URLProtocols (10.13 added a new way to implement custom protocols for WKWebViews with a completely different interface than NSURLProtocol/WebView)

I'm dreading the day when Apple is going to require me to 'upgrade' my WebView to WKWebView.

All I want to do is supply a byte stream containing HTML, and have it displayed in an NSView, with standard features. This doesn't seem like an obscure case, or a difficult problem. I don't understand why none of Apple's web views ever had simply a load(stream:NSInputStream) method. This was hard with WebView, and WKWebView made it a lot harder.

Yes, it's a mixed bag with some things better and others worse. But having a great JavaScript engine with the JIT enabled is pretty important for many applications.

But breaking up the browser into different processes and communicating via messages and sharing textures in GPU memory between processes (IOSurface, GL_TEXTURE_EXTERNAL_OES, etc) is the inextricable direction of progress, what all the browsers are doing now, and why for example Firefox had to make so many old single-process XP-COM xulrunner plug-ins obsolete.







So I get a better JavaScript engine, at the cost of making 10 features I need worse. I don't even want a JavaScript engine. I just want to display some HTML.

I'm sure for some use cases it's "progress" but I'm really having trouble seeing it right now. It would be an improvement if I were writing a web browser but I don't understand why it had to make the simple case worse.

Chrome and Firefox with WebRender are going the opposite direction and just putting all their rendering in the chrome process/"GPU process" to begin with.

Yes I know, that's exactly what I meant by "breaking up the browser into different processes". They used to all be in the same process. Now they're in different processes, and communicate via messages and shared GPU memory using platform specific APIs like IOSurface. So it's no longer possible to write an XP/COM plugin for the browser in C++, and call it from the renderer, because it's running in a different process, so you have to send messages and use shared memory instead. But then if the renderer crashes, the entire browser doesn't crash.

> It is cheap

And so the results look cheap.

Emm... nativescript?

NativeScript is cool -- I really like it.

But as far as I understand it, there's a bit of a fatal problem going forward on iOS, last time I looked at it a year or so ago (I'd be thrilled if they've come up with a way to address this problem):

The iOS NativeScript bridge uses the old deprecated UIWebView and JavaScriptCore's Objective C integration stuff that lets you directly call back and forth between Objective C and JavaScript.

However, that Objective C bridging stuff is not supported on WkWebView, since it runs in a separate process, and has a different way of sending messages to the web browser, but not calling native code directly or passing pointers to objects or buffers in memory.

Why would you want to do that? To get direct access to an array of binary floating point numbers, or the pixels of a canvas or WebGL texture, instead of converting to and from JSON, or serializing images as data urls with base 64 encoded png files, for example. (Yech!)

You can send messages back and forth to WkWebKit, but that's vastly less performant than the direct calling UIWebKit JavaScriptCore bridging stuff, which operates in the same process and memory space.

And the NativeScript iOS integration layer is totally dependent (built on top of) on the way the JavaScriptCore bridging stuff works, and would have to be completely rewritten from scratch (and be much less efficient and require a lot more plumbing on both sides), in order to support that kind of out-of-process messaging to WkWebKit.

The great thing about NativeScript is that gives you has such an efficient high bandwidth interface to native code from JavaScript. But it just necessarily uses an old crappy JavaScript engine with no JIT.

One of the best thing about using WkWebKit is that the Just In Time compiler is enabled, so it's blazingly faster than running JavaScriptCore in the same process (which has it disabled, since non-Apple apps aren't allowed to write to code memory).

Of course it depends on how much of your application is written in JavaScript and would benefit from the JIT, and how much it depends on calling and sending data back and forth between native code and JavaScript. But the NativeScript way of doing things makes many assumptions that would make it very slow with RPC messaging instead of direct calling.

PhoneGap/Cordova is fine using WkWebKit because it uses a JSON messaging interface in the first place, not the more efficient higher bandwidth Objective C bridging stuff. It's JavaScript/Objective C bridge is much simpler than NativeScript, and people don't use it the same way that NativeScript is designed to be used.

NativeScript, as cool and amazing as it is, is deeply tied to old technology on iOS, JavaScriptCore and UIWebKit.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact