PWA JavaScript Stack evaluation criteria

[akent99]

Magento is kicking off an effort on PWAs (Progressive Web Apps, https://developers.google.com/web/progressive-web-apps/). This thread is a place to collect different points of view on how to evaluate options. Please add your thoughts to this thread to share, even if conflicting. I will kick it off with a few of my own, but all views welcome - whether novice or expert.

A number of different people have been experimenting with different technologies already (e.g. React/Preact/Angular/Vue/Polymer/...), which is great and to be encouraged. But at the end we will probably want to pick the best one for Magento based on merit and fit for Magento. These evaluation criteria are to help with this evaluation.

Some thoughts on evaluating a JavaScript stack include:

• How to you re-skin an existing JS Component (e.g. To adjust HTML or CSS for that component).
• How good are the developer tools for the technology?
• What is the size of the community?
• Given it will take time to be production ready, should we pick a stack for the future or based on what it supports today?
• Can you load a module and have new UI components merged into an existing "page"?
  How big would you make one app, vs splitting into multiple page downloads?
  Does the library have good prototyping support?
• Is there good caching support for private data/tagged cached data/etc.
  Does the technology support replacing an existing component with a different one easily?
• How complete is the stack (vs needing lots of other libraries to go with it).
• How good is the documentation and learning resources?

What else matters to you?

[pierreocci]

Hi!

Here are a few other evaluation criteria I could gather:

• How good is the current documentation?
• What are the testing tools and practices in this community (snapshot testing possible?)
• Would it be easy to document components in a pattern library? I believe it makes code reuse easier for theme developers, and if there is a good way to change a component style / content, it would be great to be able to make it in a static pattern library instead of in the Magento page
• Does it allow / promotes the separation of rendering logic from data fetching?
• Would theming be in the JS stack or through stylesheets variables (scss, potscss)? What are the practices in the community and existing / proven solutions to the problem?
• (dreaming) Are there any codemods that could help to convert current phtml to components? :-)
• How easy could it be to reuse components (or at least knowledge) to target other things than the web? (native apps, desktop, Sketch ...)
• How could the interactions between the frontend and the backend be tested to ensure no regressions are introduced? (Swagger, API mocking, Consumer Driven Contracts...)
• How do code splitting work with this library?
• What are the tools available to improve the Developer Experience (live reload, hot reload, devtools support, debuggers, linters, data fetching viewers...)

[mattgreenfield]

I'm confused, building a PWA and using a JavaScript Frameworks to render the front end are different things.
Is Magento going to make the two dependant on each other?

[akent99]

Are you suggestion Magento should add PWA support without standardizing on a frontend rendering stack? Or just saying PWA itself does not mandate a particular stack? They are linked in my mind because I don't see the sense in Magento building in PWA support without also standardizing the render stack and data caching framework. People can always build their own frontend and just use our APIs - go for it! But Magento is planning to providing a PWA app shell and infrastructure including the JavaScript rendering stack. We want to provide guidance for extension developers on how to build an extension and have it work with Magento and other extensions in a PWA for a merchant.

[bambamboole]

In my opinion the frontend build process should move to webpack and use. ue as js framework.
it's modern, lightweight and easy to use.
On top of this it's no problem to build a good pwa.

[AntonS]

A number of different people have been experimenting with different technologies already (e.g. React/Preact/Angular/Vue/Polymer/...), which is great and to be encouraged. But at the end we will probably want to pick the best one for Magento based on merit and fit for Magento. These evaluation criteria are to help with this evaluation.

there is no best and if Magento chooses something then don't make the same mistake third time and don't choose dying frameworks (m1 prototype, m2 knockoutjs)  but instead take another approach on creating frontend component API data structure and communication logic  first so each developer could later choose a framework to implement a component that can exist in some ecosystem (in m2 for example). 

And for choosing a framewrok to implement their own set of components/themes you can't go wrong with existing uiComponent frameworks (like polymer2 etc) that have development and testing pipelines  already worked out and documentation ready + community of devs  often bigger than magento developer community + ensured future on framework. Gaining instant documentation and developer availability for frontend tasks is what developers and merchants need the most.

Don't mix this with creating a component system like magento2 uiComponents are , this is painful to learn and no use of learning this cause you can't use those skills in any other project. Getting up to the task with m2 development needs learning of new tools before you can even start whereas developers who happen to know React/Preact/Angular/Vue/Polymer/... could utilise their existing skills and toolsets to chime in and be productive from day one. 

If API side is strong both for data access (rest apis)  , data processing and component communication side (frontend components)  then you are in a position where you don't need to think about building in more caching layers, other tricks cause those will be already solved within frontend application building process. 

[mpchadwick]

I was a little confused by the fact that this blog post is focused on selecting a JavaScript framework, as usage of a JavaScript framework is not inherently related to building a PWA. But based on discussions on Twitter, I now understand that the goal is build out a new SPA (single page app) frontend which uses the Magento backend API as a data source (the current "headless" idea). This new frontend would be built with the PWA guidelines in mind, and would pass the PWA "test".

With this understanding in mind, my advice would be as follows...

• Set a performance budget (https://timkadlec.com/2013/01/setting-a-performance-budget/). This should be thought of in terms of number of HTTP requests / number of bytes that are acceptable to be transfered for a given page. Because Magento / ecommerce is image heavy (that's the nature of the game with selling products) I think you'll need to be very careful with the amount of scripts and styles you are shipping, which brings me to my next point...
• If you're talking about JavaScript libraries, the total size of the library (in bytes) should be a VERY large factor in influencing your decision.
• As you build out this new system, my advice would be to try to avoid complexity as much as possible. I think this is the primary complaint from M1 developers going to M2 - that the system has become much more complex. I think about how simple systems like shopify are with their templating. I think avoiding complexity should be a primary concern with this new frontend.
• Finally I think that process to roll this out needs to be agile / iterative and you need to be open to change your implementation based on feedback from community. If you roll out a huge overhaul in 2.3(?) for the frontend without getting much feedback from community it could turn out that many developers dislike the system / find problems / have trouble working with it.

Hope this helps.

[mpchadwick]

Just one other thought I had on this point...

>  Finally I think that process to roll this out needs to be agile / iterative and you need to be open to change your implementation based on feedback from community. If you roll out a huge overhaul in 2.3(?) for the frontend without getting much feedback from community it could turn out that many developers dislike the system / find problems / have trouble working with it.

I'm wondering if it would also make sense to do rounds beta testing with front-end Magento developers as you work though the implementation

[akent99]

Thanks for the feedback.

Yes, would love to see any community feedback based on experiments. Wanted to get the "rules of the game" defined first - how would we evaluate different approaches after some experiments done?

At the end of the day we need to pick one - and it won't be everyone's personal favorite. But the more eyes on it, hopefully the better the choices we can make along the way. But I absolutely agree with "try and learn" in small increments. A part of that is working out the sequencing. Quite a few people now have said, for example, the APIs may be more important than the Vue vs React vs Polymer vs ... decision.  The need for server side rendering is another - but perhaps we build in client side only and let advanced sites add server side rendering. I don't know, and agree completely with iterating with community feedback as we go along.

One challenge however is we want to move relatively quickly - try and learn rather than over analyze. The risk is making some wrong choices along the way, but as long as that is understood (and we do our best to correct mistakes) then I would rather move faster than overanalyze. Interesting discussions coming for sure!

[AntonS]

Yes, would love to see any community feedback based on experiments. Wanted to get the "rules of the game" defined first - how would we evaluate different approaches after some experiments done?

make a github repo for 3 framework experiments polymer, angular, react implementing the same component data processing lifecycle (get data, build , render, send data back etc) 

The need for server side rendering is another - but perhaps we build in client side only and let advanced sites add server side rendering.

Premature optimising, thinking too far ahead etc that's why API is more important cause whatever modern framework you choose has already solved rendering issues (both client and server side)

One challenge however is we want to move relatively quickly - try and learn rather than over analyze. 

if you wan't to iterate fast , take current m2 uiComponent structure and remove the overly complete and undocumented component part and just leave the registry and layout system intact and then implement some part of this with different frameworks given that a structure and API is agreed and raise a discussion based on that result

[AntonS]

Yes, would love to see any community feedback based on experiments. Wanted to get the "rules of the game" defined first - how would we evaluate different approaches after some experiments done?

make a github repo for 3 framework experiments polymer, angular, react implementing the same component data processing lifecycle (get data, build , render, send data back etc) 

The need for server side rendering is another - but perhaps we build in client side only and let advanced sites add server side rendering.

Premature optimising, thinking too far ahead etc that's why API is more important cause whatever modern framework you choose has already solved rendering issues (both client and server side)

One challenge however is we want to move relatively quickly - try and learn rather than over analyze. 

if you wan't to iterate fast , take current m2 uiComponent structure and remove the overly complete and undocumented component part and just leave the registry and layout system intact and then implement some part of this with different frameworks given that a structure and API is agreed and raise a discussion based on that result