An Opinionated React Progressive Web App Repository
github.com
github.com
https://github.com/facebookincubator/create-react-app/blob/m...
Although, in truth I'd use the much smaller preact library -
I agree, if you wanted to start from scratch with your own structure create-react-pwa is probably a better repository for you. However, if you like the opinions formed in this repo then it will allow you to get started straight away with static type checking, e2e testing, unit testing, tree shaking, and code splitting all built in.
You raise a good point regarding Preact, it is something that I have considered but decided to stick with React until it became problematic.
In earlier days this was first sign of being progressive, but new generation of developers doesn't seem to care about this?
PWA's are something that Google is pushing pretty hard right now, to me that suggests there is becoming less of a concern around JavaScript being turned off than previous years.
The former is about web apps that bridge the gap between web and native. Technologically the foundation lies in using service workers for offline support, and serving the app over SSL. Not only do these web apps work offline but when using modern browsers on mobile (e.g. Firefox/Chrome on Android) it's possible to "install" them and use them like native apps.
The latter is about websites that don't rely on CSS or JS to provide critical interaction, i.e. making the website work if neither CSS nor JS is available (though generally this is simplified to "when JS is disabled").
Apart from the name the two are only related in that both are intended to help users in sub-optimal scenarios (e.g. on slow/unreliable connections).
The complete abandonment of any form of progressive enhancement is depressing. We need to get some real metrics on user engagement (slow load over poor connections), SEO drawbacks (yes google can index this stuff but does it rank as well?) and accessibility (how well do screen readers really cope?).
Get some facts and start hitting people over the head with them.
Hopefully that will change.
Sounds like your gripe is less with client-side code than with JavaScript as a language.
We have a saying for that in my native language. It roughly translates as "All I hear is mimimi...".
No company will ever publicize this data.
That is not to say that UX should be thrown out of the window for the former, of course.
I do agree that something like NYT shouldn't be a web app.
EDIT: I should mention that a lot of these things come down to requirements, of course. I don't think it's fair to say that every web app must be PWA compliant... it depends!
The biggest argument seems to be laziness: "Progressive enhancement is hard, here's a term that I can apply liberally to give myself an excuse not to bother". That may make a good business argument on a case-by-case basis, but it's not an absolute, and I don't see why it necessarily applies to webapps but not to websites.
Also, React has made progressive enhancement a lot easier than it used to be
> The biggest argument seems to be laziness: "Progressive enhancement is hard, here's a term that I can apply liberally to give myself an excuse not to bother".
It's always going to come down to the requirements and an understanding of who is using your web app.
In some cases, you should absolutely optimize for PWA... Facebook, for example, is a webapp that considers users in developing countries with shotty networks. They also optimize for those with blindness.
Implementing those features in a webapp like Kibana (visualizer for elasticsearch data) would be a wasted effort given the user demographic and the purpose of the app.
TL;DR: "It depends"
EDIT: I just realized I may not have addressed your point " I don't see why it necessarily applies to webapps but not to websites.". I think the answer is simply "Webapps are inherently more complex than websites, therefore, more strict web requirements need to be met". This is an easy way to compartmentalize it, but isn't an absolute.
My point is that they are not very progressive when they fail to run without javascript, independent of what name Google marketing team put on this bad practice.
The reason websites should work without JS is that JS may fail to load (or worse: load incompletely or very slowly) over dodgy connections.
PWAs help by optimising repeat visits. This isn't exactly useful for something like news sites (where users typically visit individual articles at a time and may never come back for weeks/months) but can be immensely helpful for apps like Facebook where users will come back frequently.
PWAs also help by emphasising load performance. So even if the connection is slow, the app may still load quickly and reduce the time until the first meaningful paint and the time-to-interactive.
PWAs are orthogonal to making the app "work" without JS. You don't lose anything by making a regular "progressively enhanced" app a PWA. You also don't gain anything by making one that is not "progressively enhanced" a PWA.
However by using something like React to render the app you can use the same technology to render it on the server, delivering full content to the browser on the first paint. Where you take it from there is up to you and has nothing to do with PWAs or non.
However, that still doesn't rule out producing a "progressively enhanced" progressive web app. In fact, React (which this project uses) makes progressive enhancement even easier with ReactDOMServer and the componentWillMount/componentDidMount differentiation. So the downvotes are particularly unwarranted.
You need to have a manifest.json file which provides all the information for installing your app to your devise. For more information see https://developer.mozilla.org/en-US/docs/Web/Manifest.
You also need to reduce the Time To Interactivity (TTI) to be under 5,000ms. Webpack is doing a lot of the heavy lifting here by performing tree shaking, vendor chunking and route based chunking. All things that contribute to getting this under 5,000ms.
If you would like to know more information as to how to achieve a good PWA, I would urge you to run Lighthouse against the demo which will outline all the things that contribute to a good PWA.
https://developers.google.com/web/progressive-web-apps/check...
What is your opinion?
* if the reducers/actions/action creators/action types/sagas are UNIQUE to the component and are not being used elsewhere then it should sit together in the same folder .
* if they are more generic/being used in more than one place then I would put them all in a separate folder, since all of those parts are actually doing more or less one thing - manage a specific sub-section of your app's state.
This sub-section of your app's state can then be shared by many more than one entry point, which is extremely useful for me.
A REAL example:
I took the redux-login-saga-flow (https://github.com/sotojuan/saga-login-flow/tree/master/app), changed the folder structure so now i can just import the login state management into every entry point i want, and bam - it just works, since all of that state sits under 'login'.
I can now create a new webpage and add all of the login complexity in only a few minutes of work .
I Hope I was clear
(edit: some cleanup and spacing)
https://github.com/simonfl3tcher/react-progressive-web-app#h...
To be honest, you could hook this up to server-side rendering one way or another. However, I haven't looked at server-side rending too much, and I am not sure what the affect of doing this would be on the TTI. As a result, I cannot say one way or another whether this would be a good idea or not.