NWJS v1.0 - Roadmap

[frank-dspeed]

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.

electron/electron#21457 (comment)

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
#4190 (comment)	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	electron/electron#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

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

[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:
#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]

@theDevelopper

1. npm install --save nw-electron-adapter
2. const app = require('nw-electron-adapter')(window);
3. console.log(app.getPath('all'));

For more information:

• https://github.com/nwutils/nw-electron-adapter

I just finished v1.0.0 of that library. Can you create PR's or submit issues for parts of the API that should be prioritized.

[frank-dspeed]

@TheJaredWilcurt good start but i have a few questions

• Is the API on your Repo Complet i mean the one in the readme?
• Did you code something to keep track of the api ? so we know when we would need to implement something new?

Overall awsome effort already i am happy that we get that kicked off but i would love if we could set priority on tooling to keep up todate.

[theDevelopper]

@TheJaredWilcurt we do not use Electron or any of its code. I do not see any relevance in that library. I have never used Electron nor am I planning to do so. So there is no need for me to have an adapter replacing any Electron code that I do not use.
All I said is that Electron has stuff NWJS does not

[frank-dspeed]

@theDevelopper it is not about you it is about us we want parity as that will drive users and attention and this is still the better project so thanks for your input

[theDevelopper]

@frank-dspeed I was mentioned so i answered! I cannot test what I do not need.

[TheJaredWilcurt]

@theDevelopper you specifically mentioned app.getPath(name) as a convenience lacking from NW.js. So I created a library that has that exact feature you requested, then linked you to it with instructions on how to access it. Sorry for literally giving you what you asked for.

@frank-dspeed The status of every piece of the API is denoted in the README. This is a very detailed repo built in 3 days with 100% test coverage. It currently only has 2 of the 103 API/Event items complete. Not all of these will be relevant to NW.js. The rest of the API will be untouched unless people contribute to the repo. I have other projects to work on that people will actually use, so I won't be touching this one again unless it has user adoption/contributions.

[theDevelopper]

@TheJaredWilcurt you are right, I did. But I did not specify that I need it. I said:

another thing we struggled some years back was getting system relevant paths via the NWJS API

and then linked to the Electron documentation showing that they have more than NWJS. In the end we solved getting the paths that NWJS does not offer. I am sorry that I said that NWJS is lacking in path informations. I am sorry that I linked to an example documentation on electron side showing more options. And I am sorry that I can write code and solved the issue in the past for my company.

What your module does as per the modules instruction is: replace Electron API:

Goal
// Be able to replace
const app = require('electron').app;

I neither requested such module nor I am I in need of it. I think it is great for everyone in need, but I cannot help testing it. All it does right now is calling the NWJS API, which I can do (and do) directly.

In my opinion it would be better to have the missing path information integrated in the NWJS API directly. Or at least a neutral module that can be used outside NWJS.

But seeing that this whole topic is being treated a bit too aggressive for my taste, I am out...

[frank-dspeed]

@TheJaredWilcurt thanks for the update.

[TheJaredWilcurt]

@theDevelopper Sorry if the tone sounded aggressive. Thank you for bringing attention to an area of inconvenience that could be improved. You mentioned converting the app.getPath(name) to a stand-alone Node library that does not rely on NW.js. Currently the only NW specific part of the code is nw.App.dataPath which could be re-written to do an OS specific lookup in process.env. If that is something that interests you, the code is available here:

• https://github.com/nwutils/nw-electron-adapter/blob/master/src/api/getPath.js
• https://nwjs.readthedocs.io/en/latest/References/App/#appdatapath

I think it could be improved if made stand-alone, personally not a fan of the throw technique that Electron does for errors. Only put it in for parity.

[Kruithne]

Potential candidate for this table: #7591

[edbaafi]

Issue	Labels	Description/Tasks	Electron Reference	PR's
#5999	P2, feature-request, (MacOS)	customize titlebar style (e.g. hidden titlebar while preserving "traffic lights" on MacOS)	electron feature / example in slack app

Above seems pretty important for a modern MacOS app as most native apps have content and controls bleeding into the titlebar. If electron's performance wasn't so bad I would trade the convenience of es modules for this as the end user doesn't know or care if we use rollup or webpack but they do notice if an app feels outdated.

[edbaafi]

Issue	Labels	Description/Tasks	Electron Reference	PR's
#7639	feature-request	Make "main" optional when setting "node-main"	loading from a script file is electron's default

I initially came here looking for any information on using es modules with browser APIs (as this issue mentions ESM), but in terms of feature parity with electron, removing the need for a main would be required.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[TheJaredWilcurt]

Related project: https://github.com/nwutils/electron-to-nwjs

[lemanschik]

Note for my self add #8143 custom url handlers / protocols

convert this issue to a AI Maintained one with this github account.