NWJS v1.0 - Roadmap

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 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
#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
#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
	Good-First-Issue, P1		app.getPathName		Released
#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 / example in slack app
#7639	feature-request	Make “main” optional when setting “node-main”	loading from a script file is Electron’s default
#7651	feature-request	Handle new windo POST from webview	postBody on 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

[theDevelopper]

I think for me one “big” missing feature in NWJS that Electron has is macOS TouchBar support: Electron: https://www.electronjs.org/docs/api/touch-bar

NWJS issue: https://github.com/nwjs/nw.js/issues/5501

another thing we struggled some years back was getting system relevant paths via the NWJS API. Like System Logs Directory, User directory (can be done with node module ‘os’) and such. While NWJS offers a way to get the App Data Directory it just lacks compared to Electron: https://www.electronjs.org/docs/api/app#appgetpathname This of course can be handled with a simple module rather than the NWJS API but some paths might be app specific like the App Log Directory on macOS (~/Library/Logs/{appName})

[TheJaredWilcurt]

One thing you could do is look through the existing issues for “Electron” and start cataloging and verifying the features here. With NW2 many of them may have already been adopted and older issues may not have been updated. But this effort of cataloging and organizing this information would do very useful particularly in prioritizing of new features. I think the best route for this would be to create a new GitHub Issue Label for “Electron Parity”. Now NW.js is a different beast and likely won’t ever be able to have full parity in a sense that you could just run a migration script or swap out all require('electron')'s for a require('nw-electron-adapter') or something. People will still need to re-write their codebases against a different API. but most features that are possible in Electron are either already built into NW.js or could be feasibly added.

@frank-dspeed What I need from you:

• Start cataloging all existing Electron feature requests here
• Verify if the feature is already in NW.js so we can close those tickets
• @ me when you get to stopping points and I’ll go through and label/close those Issues

If you want to start PR’s to solve existing issues, that would be great too.