Microsoft is today confirming its plans for Progress Web Apps (PWAs) in Windows 10. The company has been talking a lot about PWAs in Windows 10 recently, and the release of Windows 10 Redstone 4 in March/April will mark the beginning of PWAs in Windows.
PWAs, for those unfamiliar, are modern web apps built on web technologies that offer a native-like experience, while being able to utilize some of the core OS features such as push notifications. Microsoft is adding support for PWAs with the addition of Service Workers in EdgeHTML 17, which is coming out with the release of Windows 10 Redstone 4. With support for PWAs, Microsoft Edge users will be able to run and use PWAs in their desktop browser and get a native experience, including the ability to run offline apps, enable push notifications, etc.
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
But PWAs in Windows 10 are more than just about the browser. Microsoft is actually bringing PWAs to the Microsoft Store. Just like regular Universal Windows Platform apps, developers will be able to package their PWAs as a UWP app and release it on the Microsoft Store. But Microsoft is also using the Bing crawler to look for quality PWAs on the web, and automatically add them to the Microsoft Store.
With the Bing crawler, Microsoft will be actively looking for PWAs on the web and bring them to the Microsoft Store as long as they meet the quality standards. Microsoft says PWAs will have a higher chance of being added to the Microsoft Store if they make use of Service Workers, use a secure connection, have a rich app manifest, have gone through automatic testing, and meet the usual Microsoft Store standards. Microsoft has already started searching for PWAs on the web, and Windows Insiders will likely be the first ones to start seeing some of the early PWAs on the Microsoft Store over the coming weeks.
The addition of PWAs in the Microsoft Store will mean that Windows 10 users will have access to a wider array of applications on the store. There’s a huge lack of native UWP apps on the Microsoft Store right now, and PWAs could help fill that gap going forward. Microsoft is, however, clear about the fact that PWAs are not here to replace UWP applications. The company says apps that require to be completely native should continue to rely on the Universal Windows Platform, even though PWAs in the Microsoft Store will get access to all the native WinRT APIs.
Believe it or not, PWAs are a big deal, and Microsoft isn’t playing around — the implementation is already here, and getting the execution right will be critical for Redmond.
skane2600
<blockquote><a href="#243743"><em>In reply to John_Noonan:</em></a></blockquote><p>IMO, Microsoft should have been developing major UWP apps in parallel with implementing the UWP environment. Then they could have released both at the same time. What they actually did was akin to launching a new gaming console with only simple games like Pong available.</p>
skane2600
<blockquote><a href="#243796"><em>In reply to Waethorn:</em></a></blockquote><p>"but full Office is in the store now."</p><p><br></p><p>You mean you can get the full Win32 Office from the store now? Because the full capabilities of Office can't be implemented in the UWP environment even if bridged.</p>
skane2600
<blockquote><a href="#244069"><em>In reply to hrlngrv:</em></a></blockquote><p>So have you actually tried to automate Excel from the outside but from within the UWP environment? If so, what entity within the UWP environment is hosting the scripts?</p>
skane2600
<blockquote><a href="#244082"><em>In reply to hrlngrv:</em></a></blockquote><p>I guess I wasn't clear. I'm talking about automating from outside the Excel app but inside the UWP environment. It you have to rely on the Win32 environment then not much has been accomplished. A true UWP-based Full Microsoft Office should be able to do everything the Win32 version can when running in Windows 10 S mode.</p>
skane2600
<blockquote><a href="#244121"><em>In reply to hrlngrv:</em></a></blockquote><p>Thanks for checking it out. Yes, it would be interesting to see if a special exception was made among Office applications. Having to run a second Office app to control the app one is interested in is a rather heavy approach as opposed to running a light-weight script.</p><p><br></p><p>IMO, a lot of the power of automation is the ability to interact both with Office and the file system. For a project I wrote a few years ago, the user could right-click on a folder, which launches a script that looks for Word files within that folder with a certain name pattern and then updates their filenames based on the user-supplied date, launches Word and then makes some specific modifications to each document. The requirements were a bit unusual but it was what the client wanted and reduced his editing time by about 90%. I wanted to avoid adding macros to the documents or changing the configuration of his Word installation since he'd be adding new documents and I didn't want things to break if he installed a new version of Word. I wasn't going to be paid for maintenance but felt an obligation to make sure he could use it for a long time.</p><p><br></p><p>Perhaps most of that could be done through another Office app, I don't know.</p>
skane2600
<blockquote><a href="#244242"><em>In reply to hrlngrv:</em></a></blockquote><p>"OTOH, VBA macros don't need to be in the same file as the files with which they're interacting."</p><p><br></p><p>It's unclear to me how that would work. Where would the VBA macros be hosted? My goal was to avoid altering either the documents or the Office installation. </p>
skane2600
<blockquote><a href="#244316"><em>In reply to hrlngrv:</em></a></blockquote><p>Thanks for the additional information. So, if I understand what you are saying, you still have to host the VBA in some kind of Office program regardless if the VBA is physically located in an external file. My whole point was to not alter the Office configuration in any way (as well as not putting macros in the target Word files). </p>
skane2600
<blockquote><a href="#244335"><em>In reply to hrlngrv:</em></a></blockquote><p>If you're automating through a script, you don't need macros at all (which I guess you already know since you wrote one above). </p><p><br></p><p>What you describe might be OK if it could be designed in such a way that it could access and modify multiple Word documents without having the filenames and locations embedded within in it or asking the user to explicitly list them. I guess if the user would be required to identify the folder the files were in that would be about equivalent to what I implemented although a little less convenient. </p><p><br></p><p>This has become quite the theoretical discussion given that I'm unlikely to ever write anything like this again. Still it's useful information. Thanks.</p>
skane2600
<blockquote><a href="#244075"><em>In reply to Jeremy_Petzold:</em></a></blockquote><p>I presume the reason is because the UWP environment can't support full Office.</p>
skane2600
<blockquote><a href="#244672"><em>In reply to rmac:</em></a></blockquote><p>I think XAML makes it easy (or at least possible) to create some very sophisticated UIs, but it's overly complicated for more typical scenarios. These days we are in a pro-declarative era but like everything else imperative vs. declarative is a trade-off. </p>
shameermulji
<blockquote><a href="#243783"><em>In reply to Evilsushi:</em></a></blockquote><p>Are you sure Apple has adopted PWA? As far as I understand they're pushing Swift as the future of their platforms.</p>
dontbe evil
<p>I'm sick of these js heavy and slow web apps, hopefully will help to populate the store, and later will can have native, fast and light uwp apps</p><p><br></p>