Let's say I want to use a _javascript_ charting library to draw a fancy graph using WebGL, and have that be a tab in my SWT application.
With SWT's native browser approach, I have to test compatibility on IE, Webkit, and Safari, and all versions that my users might have on their native system.
With Electron, they bundle the Chromium shared library into the install, so that on all operating systems, you know that you have the same browser. When a new Chromium comes out with a new feature, you don't have to wait for industry-wide acceptance. You update your electron base, and now all your users on all operating systems have the latest cutting edge browser tech that you're trying to use.
My competitors can use a cutting edge feature in Chrome that isn't available in IE yet, test it on their dev machine, and ship it. Yes yes, they should test on all platforms first, but Chromium gets lots of upstream cross-platform testing, so they can get away with just shipping it.
If I want to use any HTML5 feature, I have to do all the platform testing I would need to do as though I was developing a browser application. I already ship a JVM with every user download, and it's still smaller than any of the apps on my iPhone. Shipping the Chromium engine with every release is not that expensive.
I agree that swt.jar shouldn't have Chromium embedded inside it. But I think there has to be an "swt-chromium.jar", along with "swt-chromium-win32.win32.x86_64.jar", etc. That way, I can open a browser on any platform and know for sure that it is the specific version of Chromium that I tested against.
https://github.com/wjywbs/javacef is a project that started down this path. In the issues you can see lots of industrial interest, but it never got stable enough to use without building all the binaries from scratch. This is beyond my skill level, but seems like exactly the kind of thing that the SWT team is expert at.
The electron team has been very open about how they integrated with Chromium:
> we can't give up on out-of-the-box engines
2005: If you want to ship a cross-platform app, you can use Cocoa, MFC, and GTK. OR, you can go a lot faster using SWT.
2015: If you want to ship a cross-platform app, you can test your HTML5 components on Safari/Webkit/IE. OR, you can go a lot faster using Electron.
I caught onto this late. When Electron launched, I laughed at how slow and buggy their apps were going to be, because web technology is so unstable. I didn't understand how being able to rely on the browser's stability was going to unlock a really high development velocity for my competitors. And it has done the same for Eclipse's competitors - VSCode and Atom are both very slick. They don't have to test against a million platform combinations - every version guarantees a specific rev of Chromium on all platforms.
If SWT's native browser legacy means that it can't take advantage of Electron's "single reliable browser" innovation, then I think we're going to lose. And it's a shame, because there's still a HUGE place in the market where SWT is a perfect fit. Being able to transition back and forth between lightweight native widgets and a reliable cutting-edge browser would be a very powerful capability. VSCode and Atom choke on files that Eclipse handles very well.