PWA template - Githubissues

xamlsharp commented 6 years ago

I'm extremely excited about this project, but even more so if Blazor could be integrated with the principles behind creating "Progressive Web Apps". Of course, this would mean that interop with the Service Worker would be required (among other things).

With the recent beta release of Google's Flutter, can Microsoft one-up them by using a better language with better tooling in order to create apps with an even better reach? Blazor PWA's just might be the answer...

SteveSandersonMS commented 6 years ago

We're definitely keen to ensure Blazor can be used for PWAs! At the moment it seems like a fairly independent concept, in that you could use Blazor with PWA-type APIs to enable offline support and all the other PWA features, but you could also choose not to.

Eventually we might have some kind of out-of-the-box PWA template though for now we're focused on building the core technology.

veikkoeeva commented 6 years ago

@xamlsharp Indeed, in http://aurelia.io/ Gitter it was briefly discussed how this could be achieved. Interesting times.

vanderstack commented 6 years ago

@veikkoeeva are you able to recap any of what was mentioned or link to it or a timestamp? I missed the discussion, but am very interested in how we could use C# to build PWA's, and this idea being talked about within the aurelia community has my interest piqued even further.

veikkoeeva commented 6 years ago

@vanderstack It was more on private accounts, but there's something spilled publicly at https://gitter.im/aurelia/Discuss?at=5a8ea5c3888332ee3ab8c422. Contemplating and idly chatter more than springing into action, as of now at least.

Sorry for the delay, healing from influenza currently.

touseefbsb commented 6 years ago

Definitely +1 to this, I've been ignoring web development for many years just bcz the chaos of too many frameworks. I am a c# developer and would love to see a full stack c# web development model to develop modren sin page web apps along with pwa features ( which is a must in all framework these days ) and if all of this can be done without touching any kind of vanilla js or even any js framework totally, it would be ideal. I can bear with basic html and css stuff for styling and UI, but no javascript please.

rstropek commented 6 years ago

@touseefbsb I am sharing your excitement about Blazor. However, I think for quite a long time working with Blazor will go hand in hand with working with JavaScript. There are so many useful JS libraries out there. It might take years (if it even ever happens) until all of them come with nice Blazor support. The same happened with TypeScript. It took quite a long time until JS libraries and TypeScript went along well. And TypeScript is nearer to JS than Blazor is.

I think every Blazor developer will need good HTML+CSS+JavaScript/TypeScript skills in the near- to mid-term future.

touseefbsb commented 6 years ago

@rstropek first think that typescript transpiles to javascript, but blazor runs .net directly into the web without converting into js, correct me if I am wrong though. but if this is true this changes everything. I understand we still need to learn html/css but to be honest that isnt as big a problem, the main issue was javascript if blazor can solve that, I am all in for web development. Also if blazor manager to create a proper template system like xaml style or any style near to it, then we wont be working much with html/css either, because then community will start to create components and controls for the ui using blazor and it will hide all the html/css from a normal user of the blazor controls. template controls based on porperties is the best thing in this scenario. but if u want advanced stuff or want to create/edit ur own controls then obviously u need html and css, but the third wheel can be and should be c# instead of js.

fonix232 commented 6 years ago

@touseefbsb I doubt Blazor will drop the current Razor template base. It would be stupid to do so. The whole app runs on client side, and there are already pretty well written HTML+CSS renderers, why would the team want to write their own?

Sticking to the current Razor templates is the way in my opinion.

Also, for JS... Most of the web is in JS. Even Bootstrap uses quite some JS logic to do stuff. Right now you have two options: rewrite all frameworks with Blazor and C#, or write simple "binding libraries" for such components. I think in the near future, Vue/React components will be easily ported, similar to how the Xamarin project wrote Objective Sharpie for generating binding libraries. And I think the latter will prevail. But until that is done, you'll have to write JS code.

touseefbsb commented 6 years ago

then what is the main advantage of blazor if we still have to write js? @fonix232

zbecknell commented 6 years ago

@touseefbsb I don’t think anyone is saying you have to write JS, but that you should remain familiar as a practicality for the foreseeable future. I’m with you on the desire to write less JS, but it will take time.

touseefbsb commented 6 years ago

@zbecknell yeah I understand it will take time, but atleast its a good start with blazor :)

Jacknq commented 6 years ago

Vue reactivity, component communication and its integration with blazor, that would be reaal awesome!

touseefbsb commented 6 years ago

the very basic reason of blazor was so that we dnt have to use frameworks like vue and angular etc, I really hope blazor sticks to its own framework and keep making it better for c# developers, instead of integrating it with other popular frameworks, which will increase the problem it was supposed to solve :)

danielmeza commented 6 years ago

@touseefbsb I was thinking the same thing, if blazor becomes that way it will become odd to use. However some UI framewors running on JS will use the JavaScript Interop to and wrap their controls inside Components to avoid to rebuild the entire framwork and for sure many other libraries like JQuery will be ported to to some kind of wrapper.

touseefbsb commented 6 years ago

@danielmeza all these wrappers just make me uncomfortable bcz then this will be another xamarin, which can never be 100 percent native performant, yes writing the whole framework can take time but it will be worth it to start from root and build it all up in c#instead of just wraping everything we dnt wanna use and make some parts of app in c#

fonix232 commented 6 years ago

Why would it be odd? It would be a merge of the best of both worlds - the simplicity and syntax of C# while using the existing structure and objects of Vue/React/etc.

Yes, it doe not alleviate the need for a native framework, but with the amount of resources available written in JS, it would be stupid to not have an easy option to use them.

nicowernli commented 6 years ago

@fonix232 I don't see the need of Vue Components or Javascript libraries if you can write the code in C# with Blazor. Actually what Blazor does is what Vue and React do but better, because it doesn't use Javascript (btw I'm a full-time JS developer). Thats the whole point of WebAssembly, using any other programming language apart from Javascript. If you are going to implement Vue or React in Blazor whats the point? You better keep writting Vue or React apps without Blazor and thats it.

fonix232 commented 6 years ago

@nicowernli you might not see it, but someone coming from an existing knowledgebase of Vue and JS libraries who does not want to rewrite the 200+ dependencies a project would have, that person sees the importance of converting step by step.

First step is having the overall final framework set as Blazor, that uses a few JS libraries, Vue/React, and so on. So they put their existing codebase in a wrapper for Blazor, and first replace smaller libraries with optimized C# code, then step by step phase out the rest of the elements.

This would also help with initial adoption - sure, it will be JS running for some time, but until there's a Blazor component library at least on par with React's baseline offering, I don't see many people converting.

nicowernli commented 6 years ago

I don't think people that is ok using JS will "convert". And after using Blazor in really small things (I'm still learning it) I can't find many differences against Nuxt, or Next to be honest. If you already have a massive app, migrating it anything different that what is using will be a pain in the **se anyway.

danielmeza commented 6 years ago

@nicowernli and @touseefbsb I'm agree with you both and the goal for this proyect must be "Create a C# way to work on web client" but some nesesary functionality are missing yet, lke SignalR until they can be impelmented, in this case JavaScript Interop will be necessary to accomplish those features. We need to mantain the gap there to avoid covert the framework in other Xamarin like @nicowernli say

danroth27 commented 6 years ago

but some nesesary functionality are missing yet, lke SignalR

There is now a Blazor SignalR client being maintained by the community: https://github.com/BlazorExtensions/SignalR

touseefbsb commented 6 years ago

thankyou for the reference @danroth27 , u just proved how fast community is willing to help once we get serious abt this, people really want to get as far from JS as possible, as u can see JS developers like @nicowernli are also considering blazor, the thing is I understand interop might help in migration etc, but if interop exists, eventually blazor will become lazy project bcz u can do most of the stuff with JS interops and blazor itself will never become an original framework without js interop dependency, or it may take too long to become one. on the other hand if our complete focus is making it 100 percent pure c# framework then whole community of .net developers will be willing to help and its progress will be really fast and very soon it will be as good as Vue, react, angular, and then u will see it will be doing everything they can and some stuff which even vue, react cannot, because web assembly can do everything better in a more simpler way, and interops will just make blazor too lazy to re-invent the wheel in c# for its own good.

touseefbsb commented 6 years ago

@danielmeza if you dont want blazor to become another xamarin, then dont use interop and wrappers, because that is the same mistake xamarin has been doing, no matter how good they are, wrappers and interops always have their drawbacks in performance, being dependent, app size, web development has unnecessary hell and difficulty bound to it, we need to make web developmnt as simpler as native apps so that any normal developer out there can easily develop high quality web apps instead of needing a team of 20 ( 2 of which just decide which framework to use and how many npm dependencies we will need and which versions etc ). I am a uwp developer and I only need to know c# and xaml, and I can literally create any kind of uwp app possible alone myself as an indie developer. but when I think about web first of all I have to do research of choosing a UI framework, then luckily if I convince myself to choose one ( which seems highly impossible ) then I need to decide on their version, then decision of backend technology stack, then which pattren will I use to connect these 2, then which flavor of JS I will write in my app, typescript, es6, es7 and some more, will I use webpack ? static pages or dynamic, there are infinite decisions to make and a single developer gets too tired to even start a high quality web app. ideally for me what blazor should do is just use c# and xaml, but I get it bcz web has been all abt html and css, then blazor should use c#, html and css, and thats it, no webpack, and no other thousand libraries and frameworks. and community will keep helping through nuget packages as always. :)

rarera commented 6 years ago

Fantastic idea. I would love this, and this could be strategically valuable to Microsoft to close the app gap. A PWA implemented with Blazor would be just fantastic.

Terricide commented 6 years ago

If you are a UWP developer you should check out the uno platform.

touseefbsb commented 6 years ago

yes I have checked the uno platform but it is still in early days and the product still has its flaws and very less support in the community but it is definitely something I am hopeful about in the future :) @Terricide

krdmllr commented 6 years ago

I'm currently working on creating a pwa using blazor. I just added all files that are required for a pwa to a blazor project, you can find the pwa here: https://krdmllr.github.io/DotnetPwaSample/ and the code here: https://github.com/krdmllr/DotnetPwaSample Would the added serviceworker/manifest and modified index.html be enough for the template or would this require some data caching strategy aswell? Also, the serviceworker is currently written in js and you need to add all .dll's to a list. I could not find a way to auto generate the list or work with wasm here yet.

danroth27 commented 6 years ago

Would the added serviceworker/manifest and modified index.html be enough for the template or would this require some data caching strategy as well?

I was thinking we would want to provide some prebuilt caching strategies, similar to what @madskristensen worked on for ASP.NET Core a while back: https://madskristensen.net/blog/progressive-web-apps-made-easy-with-aspnet-core/

Also, the serviceworker is currently written in js and you need to add all .dll's to a list. I could not find a way to auto generate the list or work with wasm here yet.

At some point we may want to look at implementing service workers in .NET, but for now I think implementing them in JS is ok. For the list of assemblies I think you might be able to leverage the blazer.boot.json file that get produced when building the app.

krdmllr commented 6 years ago

@danroth27 thank you for the infos. The blog post is interesting, i will see if i can use some of the ideas in my pwa. mads is using a backend to generate some of the files, i thought a standalone client project would be better for a template, what do you think?

danroth27 commented 6 years ago

i thought a standalone client project would be better for a template, what do you think?

Yup, I agree.

danielterabyte commented 5 years ago

Hi, guys. Is there any update in this matter?

I am starting a POC at work and it would be very good to have PWA Blazor app.

Thanks.

danroth27 commented 5 years ago

No progress on our side, but there are some community efforts based on Blazor you might look at, like Bionic

richbryant commented 5 years ago

Dead link there, @danroth27

treg commented 5 years ago

https://github.com/BionicFramework/

On Mon, Dec 17, 2018, 4:17 AM Rich Bryant <notifications@github.com wrote:

Dead link there, @danroth27 https://github.com/danroth27

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/aspnet/Blazor/issues/183#issuecomment-447792877, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvMbNcESrqtqqo5s9VgljOUWgL0y_hxks5u529BgaJpZM4SWLTF .

roboriaan commented 5 years ago

For those who might be interested in a Blazor starter template that is cached for an offline scenario using 'Service Workers' : https://github.com/roboriaan/BlazorServiceWorker

danroth27 commented 5 years ago

@roboriaan Nice! Have you considered making this template available as a NuGet package so it can be installed and used from the .NET Core CLI?

roboriaan commented 5 years ago

@danroth27 Sure thing. I'll get cracking on it. Keep you guys posted.

roboriaan commented 5 years ago

@danroth27 @xamlsharp

I've made this template available as a NuGet package :

dotnet new -i RC.Blazor.Hosted.Service.Worker
dotnet new blazorserviceworker

danroth27 commented 5 years ago

@roboriaan Awesome! It would be good to advertise the package on the readme in your GitHub repo so folks know there is a quick way to try it out. Once you've done that, we should get this on the Blazor Community page. Just send us a PR and we'll add it.

roboriaan commented 5 years ago

@danroth27 I've updated the readme. To be honest, I'm a bit unfamiliar with pull requests. I did create one. Do I just send the link?

danroth27 commented 5 years ago

@roboriaan I meant send a PR to the https://github.com/aspnet/blazor.docs repo to update the community page with a link to your project. Once you've finished updating your readme I'm happy to help you out with that.

roboriaan commented 5 years ago

@danroth27. Ah I see. Awesome! That would be great if you could help me out on that. The readme file is updated.

AngelMunoz commented 5 years ago

Hello everyone, to add my two cents it would be intresting to see guidance on how to tailor Blazor based PWA's with the WinRT API. I know in javascript if I'm running on a C#'s WebView or the visual studio 2017's pwa templates I can do the following and boom, we've got native stuff showing around:

if(window.Windows) {
  const msg = new Windows.UI.Popups.MessageDialog("Hello World!");
  msg.showAsync();
}

I'm not sure Blazor can do this right now perhaps it can but via js interop but I bet writing full C# PWA tailoring would be nice.

Anyways if we had a PWA Template that had this kind of tailoring it could enable some future scenarios for different businesses/individual devs .

(btw, not sure if this can fit better on a different issue or this is fine)

Difference commented 5 years ago

Could PWA be made to have a shared cache, "a cross domain service worker resource"?, hosted by Microsoft for the Blazor dotnet runtime?

danroth27 commented 5 years ago

@Difference This might be just due to my ignorance about service workers, but I'm unclear on what you're asking for. A shared cache for what? Hosted by Microsoft where?

Difference commented 5 years ago

@danroth27 Please let me hurry up and grab that ignoramus hat back to somebody who actually deserves it, and sorry for not explaining better.

Quick answers : A shared cache for the Blazor.Browser.dll , mono.js , mono.wasm etc. files.

Hosted by Microsoft at some sensible url, in the same way we can use resources such as bootstrap: href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous"

I had the thought, that since all Blazor Client side apps will be using the same Runtime, it could save a lot of bandwidth and cut down time where the user has to wait, if the runtime files was not downloaded once per app, but rather once per browser.

This might be achieved if the common shared Runtime, where builtin to the browser ( a possibility for Edge? ) or if the Runtime files where only downloaded if not already present in a shared browser cache, - a cache that was not sandboxed to the individual app.

As I read the service worker documentation, it is possible to store files, fetched from a cross domain origin, so in theory, these common files could be hosted at a central location, and fetched from there. ( https://asp.net/dotnet/blazorruntime/Microsoft.AspNetCore.Blazor.Browser.dll , mono.js , mono.wasm etc.) BUT the spec does not seem to allow apps to share files cached.

I think that this idea might be very close to the thoughts behind, "foreign-fetch" https://developers.google.com/web/updates/2016/09/foreign-fetch A concept that seems to have been removed from the w3c Service Worker specs ( https://github.com/w3c/ServiceWorker/issues/1188 )

Getting the files from a common MS location, would allow bugfixes, performance enhancements and general updates to the runtime to be rolled out, without the need to update the individual web apps.

There may very well be other and better schemes for solving this, but the ambition seems good to me.

ScottRFrost commented 5 years ago

Blazor seems to be approaching 1.0. Any word on if we're going to have an official PWA template ship with it?

danroth27 commented 5 years ago

We expect to shift our focus from Blazor Server to Blazor WebAssembly after shipping .NET Core 3.1 later this year. As part of the Blazor WebAssembly work we expect to look at addressing PWA scenarios.

JeroMiya commented 5 years ago

Sounds like this is gaining traction, which is great. Might be a good time to flesh out some Blazor PWA requirements now. PWA caching is more complex than it seems, as you have to think about application and cache integrity. These are some common features provided by other front-end-frameworks with official PWA/service-worker support:

The whole application must be cached together, and updated as one unit not individual files. For example, you never want to have a more up-to-date version of index.html but an out of date version of the mono wasm runtime. Other PWA implementations implement this with a sort of autogenerated secondary manifest file, which hashes every file in the application together to form a version hash.
Individual file integrity: The same secondary manifest file that stores a hash of the application as a whole also needs to store the hashes of each individual file. When downloading and caching these files, the service worker needs to validate the file contents against the hash to ensure individual file integrity.
For unhashed content, such as files from a CDN that are not available at build time, the service worker still needs to download and cache these files, but it should respect the http caching headers for those resources, for instance downloading new copies of the files when the http caching headers indicates that the cache has expired.
The service worker should not update resources of an app that is currently running, including resources that are lazy loaded after the initial app loads (if you use a pre-fetch caching strategy). This means that the service worker may need to maintain multiple versions of the app and all resources while those tabs are open, and clean up old versions of the app when tabs are closed and no longer running.
Error recovery on failed file hashes (plus possibly retry behavior), and other safe mode errors.
Fail safe logic - example: deleting the secondary manifest file from the server side (thus resulting in a 404 for the secondary manifest file), should result in fail safe behavior by the service worker such as clearing all caches and de-registering itself. Additionally, a special service worker that simply unregisters itself and any other service workers that you can serve at the old service worker URL.
Configurability to e.g. bypass the service worker caching mechanisms or change the caching policy on a file-by-file and file-globbing basis, or configuring groups of resources at once with different caching policies.

Bob-HL commented 4 years ago

The major problem is that blazor.webassembly.js loads *.DLL using xhr but not fetch API.

dotnet / aspnetcore

PWA template #5479