Projectreunion: Proposal: Bring back WinJS

[Jaiganeshkumaran]

Proposal: Bring back WinJS

WinJS was a great way to create native Windows apps with JavaScript. Now we need to use third-party frameworks like React Native or Electron. While these frameworks are cross platform, they are tied to non-standard technologies (React for React Native, NodeJS for Electron).

Summary

Although existing WinJS apps still run, you can no longer create new WinJS apps using Visual Studio 2019. WinJS was a great technology and these cross-platform frameworks can't do a lot that WinJS did since it's provided by Windows.

Rationale

• WinJS is another option for Windows Runtime apps and it was really popular back in Windows 8 days.

Scope

| Capability | Priority |
| :---------- | :------- |
| This proposal will allow developers to create new WinJS apps using Visual Studio 2019 | Must |
| This proposal will allow end users to use modern web-based WinRT native apps | Should |

[contextfree]

I'd separate the approach to JavaScript apps from Windows 8/early 10 days into two parts

1. The WinJS controls library and binding framework, providing a way to write webtech-based apps with a look and feel that matches the Windows design language (Metro at the time, now Fluent). It seems to me that at this point that's been pretty well superceded by Fluent UI which does the same thing more or less but is better supported, more modern, more compatible with the rest of the web ecosystem, etc.

2. The WinRT projections for JavaScript and TypeScript. These don't exist anymore in WebView2 and Chromium-based Edge, and so using Windows APIs from JavaScript code (PWA, WebView2, Electron apps, React Native apps ...) has to go through some bridging layer like NodeRT, or done in a C++ module, etc. It seems to me this was a pretty powerful and useful capability that was lost, so conceptually it seems good to bring it back in some form, even though I can see how the move to Chromium could make that more difficult to do in practice.

"WinJS" was/is sometimes used to refer to the whole of support for JS-based apps (1 and 2, plus the hosting mechanisms) and sometimes only to refer to (1), the JS controls and binding library, which has caused confusion. Anyway it would be good to have (2) again.

[jonwis]

How we _should_ have done this, knowing what we know now:

• WinUI3 "native frame" for the app
• Hosting a WebView2 for HTML/JS content
• An xlang-flavored JavaScript binding for WinRT APIs
• An easy bridge so WebView2 content can call up into objects hosted in the native frame
• Some simple copy-and-pasteable bootstrapping code that gets everything all hooked up
• Additional tooling to take a directory of HTML/JS and produce an MSIX

Aside from the xlang-flavored projection all of this is achievable today, we just don't have it all together yet.

But to your point, this wouldn't be "WinJS" - this would be an "HTML/JS-based native platform app."

[Jaiganeshkumaran]

@contextfree Although Fluent UI is by the same company it looks and feels completely different so it doesn't look native to Windows. Microsoft should make WinUI and Fluent UI more similar so that I can host a web app inside a WebView2 and it will look native to Windows. Also Fluent UI uses React which means I must use React for my web app, I can't use standard web technologies. For this we already have Electron and React Native. I want a fully standard Fluent UI which I can use with any web framework or without one at all.

[dragonDScript]

Both React and Node are standard. MS is focusing on other stuff now.

[Jaiganeshkumaran]

@dragonDScript It's not. You can simply take a plain HTML + JS and use it with React Native.

[dragonDScript]

Anyway, Win JS was good. And I want to get it back too!

[pjc2007]

In my case I have an Ionic app hosted as a UWP (via Cordova). Ionic, and now another third party component I use has dropped support for old Edge, so we really really need to be able to use Webview2. This would be a perfect use for it - hosted in the latest .net 5 UWP container app where we can use Visual studio 9 (and future versions), and to be able to call into native code via the plugins (or even straight from the JS as I have done) as before,

[mdtauk]

Bring back the projections into WinRT, but lets let FluentUI or Fast with Fluent Design Kit - handle the UI and controls please.

We don't need additional ways to do the same thing, and it would be better to focus on a single Web UI framework.

[Jaiganeshkumaran]

Bring back the projections into WinRT, but lets let FluentUI or Fast with Fluent Design Kit - handle the UI and controls please.

We don't need additional ways to do the same thing, and it would be better to focus on a single Web UI framework.

First Microsoft should make Fast and Fluent UI be really Fluent instead of telling this is where we're going. Edge Legacy had the best browser UI ever and the new Edge still doesn't compare.

[mdtauk]

Bring back the projections into WinRT, but lets let FluentUI or Fast with Fluent Design Kit - handle the UI and controls please.
We don't need additional ways to do the same thing, and it would be better to focus on a single Web UI framework.

First Microsoft should make Fast and Fluent UI be really Fluent instead of telling this is where we're going. Edge Legacy had the best browser UI ever and the new Edge still doesn't compare.

I think the plan is to bring both WinUI and FluentUI closer visually.

I too hope Acrylic will make its way to Edge eventually, but that may rely on WinUI 3 supporting it, and for cross platform efforts to handle macOS's Vibrancy effects, and whatever Linux may do for Translucency

[Jaiganeshkumaran]

The real plan is to get rid of effects that are unique to WinUI (eg: reveal) because they are harder to implement on other platforms and current methods could have performance issues and by doing that they can achieve consistency easily and call Fluent UI's design as the new Fluent.

[mdtauk]

The real plan is to get rid of effects that are unique to WinUI (eg: reveal) because they are harder to implement on other platforms and current methods could have performance issues and by doing that they can achieve consistency easily and call Fluent UI's design as the new Fluent.

Me and you have had this exchange many times, so I won't repeat it here.

• Acrylic is coming, WinUI 3.1 will enable Win32 apps to use it.
• Reveal (light theme) does not produce the effect they are happy with for the Sun Valley refresh, and so they no longer want to use it, instead animating the controls themselves, instead of the borders around them. Reveal will be supported in a 3.X version of WinUI however.
• FluentUI have various control styles that the WinUI team are now implementing with their controls (specifically the buttons, text, and form controls)
• FluentUI and WinUI will both be moving to support "Design Tokens" which will enable sharing of design styles despite the different technologies involved

You can talk about why you think those changes are happening, but at some point you have to accept the reasons given publically, and try to put forward your wishes in a way which is persuasive enough to be considered.

[mlynch]

Wanted to add that there are a lot (more?) of web developers building desktop and mobile apps not with React Native.

The story for people using standard web tech used to be more clear in UWP land but has gotten really confusing lately. PWAs don't provide enough API access so people are using Electron, but as a win32 app connecting to windows 10 APIs is a nightmare.

I really hope Microsoft doesn't just tell JS/web developers to use React Native, that would be a mistake.