George
February 9, 2021, 3:02pm
30
Well I'm not so sure about that any more. NWJS is doing actually pretty good and we are very satisfied with it. We also started to compile our js code to native with NWJS recently - that is not really possible with Electron.
Also Electron is hitting some road blocks and many users are coming to NWJS
opened 08:25PM - 27 Aug 20 UTC
Electron Parity
## Internals
There existed no Binary Module System that we all could agree on: … chromium, mozilla, servo, webkit, gecko, ......
Now there exist such a pattern: We create so called Context Objects and Inject our Modules into them. So a Context is 1:1 to a Task it can be long or short running. A Task can create Task Objects and pass Capabilitys to them via Reference or Value Passing we call such Component Passing often also Handels there exist many types of Handels in the WebPlatform Standard.
The WebPlatform Standard is the one driven by the WebPlatform Authors it mainly trys to address security and stability concerns of the WebPlatform no matter in what language or Engine it is Implemented. It Defines fundamentals for WebPlatforms like the Above Mentioned Context Task Handel Concepts. It is not related to the W3C in fact it moves much faster as W3C can do it there is no RFC process needed as the new system is so modular every one can make his experiments without any changes to the core concepts.
## Performance or PoC?
and if your in question if or does the new module system work yes it does 1 brave man has mostly invented and tested it on linux and wrote a benchmark that he submitted to https://www.techempower.com/benchmarks/#section=data-r21&test=composite
and it confirms since some years now that this is the right thing to do it outperforms them all it is called just and is rank 1
nodejs ranks 81
## Historical Issue Content
I would like to collect missing features in this issue and then create PR's to get 100% feature parity with Electron as they are not going to implement ESM this is the moment where NW.js can shine when it is able to run Electron apps.
But I am not sure what is missing so it would help if some one could simply comment here missing features that are in Electron but not in NW.js.
https://github.com/electron/electron/issues/21457#issuecomment-647728163
## Global Effort Plan
Electron offers additional API's via patches to Chromium source. We should get the patches inside the Chromium and [Puppeteer](https://github.com/puppeteer/puppeteer) projects as also use the Puppeteer project where ever possible to get the Electron API features.
* [ ] Identify current issues and priorities
* [ ] Identify best project to implement (Chromium, Puppeteer, NW.js) and create the final PR's inside the projects
## Current NW.js Issues
Issue | Labels | Description/Tasks | Electron Reference | PR's | Library?
:-- | :-- | :-- | :-- | :-- | :--
#7548 | ES, P0, GOOD_FIRST_ISSUE | Create default app that ships with NW.js and gets used if no app is supplied it works as a CLI wrapper.
#7499 | P5, binding | Create a method to block screen capture need to verify what they do for Linux or if Electron even supports that on Linux Chrome itself does support that I know that as I experience issues when I use OBS on Linux. https://www.electronjs.org/docs/latest/api/browser-window#winsetcontentprotectionenable-macos-windows
#7482, #951 | P1, binding | Electron API `app.setAsDefaultProtocolClient` in NW,js? | | | [Started](https://github.com/nwutils/node-default-application-protocol)
#7468 | P5, binding | `GetNativeWindowHandel`
#7194 | P5, binding | `WinSetAlwaysOnTop`
#1151 | ARM Support | We Need to verify arm support
#6794 | MacOS Support | MacOS Signing
#6945 | P2 | Verify will prevent unload | [`event-will-prevent-unload`](https://electronjs.org/docs/api/web-contents#event-will-prevent-unload)
#7117 | MacOS | Notraize |
https://github.com/nwjs/nw.js/issues/4190#issuecomment-518070965 | P2 | Alert API dialog-node
|| P5 | ```<webview>``` tag
#5501 | P2, MacOs | Touchbar | [`touch-bar`](https://www.electronjs.org/docs/api/touch-bar)
| | Good-First-Issue, P1 | | [`app.getPathName`](https://www.electronjs.org/docs/api/app#appgetpathname) | | [Released](https://github.com/nwutils/nw-electron-adapter)
#7591 | | Force repainting to allow Steam Overlay | https://github.com/electron/electron/pull/8628 | |
#5999 | P2, feature-request, (MacOS) | Hidden titlebar while preserving "traffic lights" on OSX | [electron feature]( https://www.electronjs.org/docs/api/frameless-window#alternatives-on-macos) / [example in slack app](https://slack.com/downloads/mac)
#7639 | feature-request | Make "main" optional when setting "node-main" | [loading from a script file is Electron's default](https://www.electronjs.org/docs/tutorial/quick-start#create-the-main-script-file)
#7651 | feature-request | Handle new windo POST from webview | [`postBody` on `new-window`](https://www.electronjs.org/docs/api/web-contents#event-new-window) | |
## Update
I identified some issues that are overlapping with the nw.js transperent window support that would enable some of the requested futures here i need to think about api's
@izzy as for your initial topic subject about TypeScript - we thought of that some time ago, and have some parts in TypeScript - but it only delays our production speeds without real gains - and eventually produces messy js code. So we rather stick to full blown ES6 native code.
As for automated testing that is a whole different story, separate from TypeScript. Most of Wappler is its UI which is kind of difficult to test automatically, but we hope some day to be able to run Cypress on it.
The rest of the used frameworks like Server Connect and App Connect has their own testing procedures of unit, rest API super tests, browser tests and more, that we are expanding continuously to be able to produce more and more future proof code.
We hope also to integrate more testing tools soon in Wappler soon, so that you can also produce high quality solutions with it. Some users like Jon already use Cypress for that.
So just to say - we are on top of every development
4 Likes