search

microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.78k stars 319 forks source link

Proposal: Bring back WinJS #151

Open JaiganeshKumaran opened 4 years ago

JaiganeshKumaran commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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

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 commented 4 years ago

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

ghost commented 3 years ago

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

JaiganeshKumaran commented 3 years ago

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

ghost commented 3 years ago

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

pjc2007 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

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 commented 3 years ago

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.

dhusemann commented 3 years ago

Just want to make sure we are talking about the baseline of FluentUI, FluentUI React builds on https://github.com/microsoft/fluentui and those web components are fully web standard components. And if looking at a just a component based system I would look at its base https://www.fast.design/docs/components/getting-started/

ghost commented 2 years ago

@andrewleader @btueffers this issue should be closed because it belongs to xlang repo.