Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Create guidance for Progressive Web Apps #2320
The developers will learn:
This is bit below is being worked on.
changed the title from
Add a section for Progressive Web Apps
Create guidance for Progressive Web Apps
Dec 7, 2015
I think that developers would love to experiment with these things themselves, so maybe some info on how to get it working on appengine etc would be useful.
I recently ported my Web NFC demo to appengine and added http2 support, auto-selection of images based on DPR and an app shell: https://weneed-1147.appspot.com/
Talking to people working as front end developers, their hard problem is being able to convince their clients that there is a value in all this, because their clients just want something which works 100% the same way across common browsers (incl IE9 etc) and they want it fast. We need to explain how to make progressive web apps, which even progresses from old browsers into newers ones, then onto the launchers etc. and we need to have simple clear presentations that these developers can reuse themselves to convince their clients of the value in doing all these things.
This here is a very good presto explaining some of the issues from the frontend developers side: http://www.slideshare.net/cheilmann/the-state-of-the-web-helsinki-meetup
The above should also discuss responsive design, as it is important that the app shell is also responsive if the main content is. Also you may want to mention screen orientation lock which can be very useful for games
Btw, I wish we could stop calling what Reach does for server rendering - it is not really rendering anything on the server but doing DOM diffing, at least AFAIK
"Questions a developer will ask: What is the set of technologies involved? How can I get some background in each of these?"
Should it say, "what set of technologies and techniques?" Responsiveness, app-shell construction, and linkability are more about how than what.
@deanhume great feedback. Silly question, is debugging a prog-web-app any different from debugging a normal web? Or is it now we have SW we have to manage that as well? Or is it more?
Regardless, I think we are missing a huge swath of testing guidance in our work.
@PaulKinlan From what I've heard, companies often order a website as one thing, and demands the required features and where it should be supported. This often leads to developers having to choose the lowest denominator and/or add extra code (performance penalty) to make it seem to work the same way across browsers.
I think it would be useful with a presto explaining why you don't need to offer exactly the same experience across all browsers (new and old) - what the penalty is when you try doing so, and what you gain if you instead progressively enhancing the experience.
Many companies believe that they must offer the same experience everywhere and that they need to support all browsers out there in order to reach as many people as possible, but often they do not understand the cost of attempting to do so.
Last I interviewed a new GDE, we were talking about Service Worker, and he mentioned that they tried pitching that to their clients, but there first questions were always "does it work everywhere?" and when the answer is "no, currently in Chrome", they don't care, because they don't really understand how catering for specific platforms/browsers helps them. Maybe it is also because they see it as "one browser" thing, instead of a feature that with time will just work everywhere and benefit their other platforms as well.
I second that strongly!
People will give a positive response once they see a sample PWA but after they hear about the partial support they backup...hoping that the situation will change soon.