Introducing Magento PWA Studio

[jzetlen]

Magento is becoming a Progressive Web Application platform. That is to say, we at Magento are making a suite of tools for building online stores as Progressive Web Applications. These tools will help developers learn PWA techniques, build lightning-fast PWA frontends, and create PWA components and extensions for reuse or sale on the Magento Marketplace. Taken together, we’re tentatively calling this suite of tools the Magento PWA Studio.

Reader, this blog post aims to answer some of the questions that you’ve already thought of upon reading that opening paragraph. I’m excited to tell you about what we’re up to.

A Progressive Web Application is a software application, written in the Web platform and running in the browser, that behaves like a cloud-delivered native application. It’s an

application because it installs and runs code on the shopper’s device or computer, with more speed and capability than the “single-page JavaScript apps” of the past. It’s web because it’s written in the languages of the Web—HTML, CSS, and JavaScript—instead of in some domain-specific language or in a native framework captive to one platform. And it’s progressive because it lazy-loads itself, along with any relevant data and assets, as the user navigates around your store. All this results in a developer experience with the ease, portability, global reach, and open standards of the Web, and an end-user experience with all of the speed, usability, offline operation, device integration, and delight of a native application.

At Magento, we firmly believe that Progressive Web Apps (hereafter PWAs) are the future of the web, and that someday soon, the techniques that we call PWA today will become as mandatory for a good website as responsive design and image compression. And so, we entered into a collaboration with Google to make PWAs a part of the Magento story.

PWAT?

The term “Progressive Web Application” itself was invented by Google, though Google doesn’t have any intellectual property ownership over PWAs in the way that (for example) Adobe owns Flash. Instead, PWAs are built from open standards, which Google often promulgates and implements, but which are never proprietary. Google maintains a portal full of research and documentation to explain these things, which you’ll find yourself leaving open in a browser tab as you learn and implement PWAs. And Google makes the canonical tool for evaluating PWA performance, Lighthouse.

What distinguishes a PWA from any reasonably fast website?

• Minimizes network traffic, so that it can work well on a slow or nonexistent connection.
  • First pageload serves a very small shell document with inlined resources to get to First Meaningful Paint
  • Web traffic is served over HTTPS and heavily edge cached
  • Installs a ServiceWorker that does intelligent caching on subsequent requests
  • No postback or page refresh: single-page JS app routes on the client and interacts with data via slim API requests
  • App code itself loads new functionality progressively as-needed, just like data
• Uses non-blocking techniques to keep UI responsiveness at 60fps, so that it feels like a native app instead of an uncannily slow simulation
• Doesn’t touch DOM elements directly, instead rendering through a view component library such as Polymer, React, or Vue
• Defers complex calculations to avoid layout thrash, potentially even sending them to the ServiceWorker, to achieve true concurrency and avoid locking the one JavaScript thread owned by UI
• Inlined CSS from the “Critical Render Path” establishes dimensions for all elements immediately, so that the page does not “jump around” as content loads
• Installs a ServiceWorker to expand the capabilities of the client-side single-page app so it can act more like a “smart client” that doesn’t require network traffic for every interaction
  • Intercepts all network requests and dispatches them via route matching to “middlewares” registered by modules or themes
  • Caches deserialized requests/response pairs using in-JavaScript data structures
  • Detects offline mode, notifies user, and begins serving the traversed portion of the store in response to AJAX requests
  • Can request Push Notifications permission and run a JavaScript function in the ServiceWorker when a notification is received…even when the browser is closed!
• On supported OSes (first Android, now Windows Phone, and soon more), registers itself as an app that could live on your home screen alongside native apps, rather than launching in a Web browser tab
  • Circumvents the restrictive app stores of various vendors
  • Write once, run anywhere
  • Still runs in a browser process (WebView), but OS treats it as a separate app and removes the browser UI from around it
  • Installs instantly—you’ve downloaded it already!—much faster than installing a native binary app from an app store

There will be quite a bit of new stuff in this! I know how that feels to read. We are keenly aware that some of our tools have been opaque or difficult to master, especially in the frontend. And furthermore, we know that PWAs represent a slight change to the skillset of the frontend developer. That’s why almost all of our early-stage design thinking is concerned with developer experience and developer discoverability. We aren’t just building and releasing a “PWA theme”. We’re focused on the end-to-end experience of self-education, feedback cycle, quality assurance, deployment, and extension.

We’ve also kept ourselves attentive to developer experience by involving members of the Magento community in our early meetings and decision-making processes. We’re not stopping there, either. As more of this project solidifies, we’re bringing in a wide swath of community frontend developers, so we can stay in touch with the experience of making Magento work for your own clients. We’re talking to JavaScript people, CSS people, trainers, business leaders, full-stack developers, and neophytes. If you want to talk to us about this, we’d love to hear from you. The strength and success of the Magento PWA Studio will be due to the diversity of voices giving us guidance from our awesome community, more than from grand designs by me or anyone else.

My personal definition of success for this project is that Magento 2 itself should come with a suite of independent, but interoperating, tools—the aforementioned Studio—that can guide a novice developer to hacking on a new Magento PWA in minutes, and then help that same developer get to a reliable and highly optimized production build of that PWA.

Every person who starts learning and making Magento PWAs with the Studio will be one more Magento developer making faster stores in less time, with less frustration and more confidence in the work. And every Magento PWA rolling off the line will be just one more instant shopping channel in your customer’s pocket, loading faster than the competition and giving you more powerful tools to manage your relationship with your customer.

(Also, these tools will be open source.)

The Magento PWA Studio and the Apps We'll Make With It

The core concepts and technologies in the Magento PWA Studio are currently:

API Layer 

Magento REST API coverage is already impressive, but the PWA Studio will require some new API methods to work some of its magic—and the PWAs may also need different or more efficient API endpoints at runtime.

We’re also having preliminary internal discussions about adding another style of API that can provide slimmer, more customized responses than REST designs sometimes do; we’re doing some experimenting with GraphQL, a popular choice for building web services that support PWAs and other bandwidth-sensitive things.

Application Shell 

The Application Shell is a simple PHTML file, made by hand early in the project and edited rarely. It’s the basis for the HTML response from every route handle, and is responsible for:

• Inlined critical CSS and global data
• Minimal branded UI during load (header bar, at least)
• Indexable and socially linkable metadata for the page
• Seed JavaScript file for bootstrapping the PWA runtime and loading data

At runtime, the Application Shell template should receive an Application block instance, that can supply it with inlined asset strings and metadata listed above.

Application Framework

The Magento PWA Studio will want to work with a Magento store running in “headless mode”, using a tiny subset of existing storefront page rendering functionality. The PWA is still hosted by Magento at the same origin, but once it is running, it only interacts with Magento data via API calls. Our PWA implementations will likely be single-page JavaScript applications, running on a new core JavaScript framework which:

• Implements the “unidirectional dataflow” pattern, using pure components, render methods and virtual DOM reconciliation instead of dirty state checking, string templates and two-way data-binding
• Uses ReactJS to do all rendering and event handling inside the App Shell, and a core library of simple view components and higher-order behavioral components that enable progressive loading, extensible by third parties
• Uses Redux to manage all shared state, as well as a core library of Redux reducer functions for common tasks, that can be composed together to make business logic
• Adds a Redux store middleware for ServiceWorker-mediated requests, which can rely on the ServiceWorker for batched updates or push updates, or fall back where ServiceWorkers are not available
• Uses React-Redux to bind state transformations to views and optimize renders
• Swaps out React with Preact in the final production bundle, for maximum performance
• Uses CSS Modules to isolate and scope stylesheets to components, with some potential customizations to expose a familiar stylesheet paradigm to third parties
• Uses Jest and Storybook to help developers test components, reducers, and actions at build time and in developer mode
• Builds, bundles and minifies with Webpack, as part of its standard 12-factor deploy, enhanced with custom Webpack loaders and plugins to pre-compile store configuration into the frontend

The App Framework build will emit static assets that can be read by the Application block, and then injected into the App Shell. It is core functionality, and is distinct from the Studio Starter Theme.

Developer experience

The App Framework will not only be a sturdy foundation for a Progressive Web App, it will also be a self-documenting teaching tool. Developer experience is priority one in the design of the Application Framework’s patterns and behaviors. Developer-mode error messages will be verbose and will deep-link to documentation. Compile-time AST analysis will try to catch common errors and explain step-by-step how they might be fixed in console messages. If any concept novel to Magento (such as CSS Modules or Webpack plugins) has any common “gotchas”, then in subsequent releases, we’ll remove those misleading parts of the development experience if we can. And if we can’t, we’ll document the heck out of it.

For readers who follow Web frontend trends, the big headline here is probably that we chose the React ecosystem for our JavaScript architecture, and the Magento PWA Studio will make “React apps”. We are really excited about this choice; I can’t wait to show our work to all you patient frontend folks in the Magento community who have been wishing aloud for a smoother developer experience.

React

React has the strongest and broadest developer happiness track record of any modern view system. There are tradeoffs with React and React-alike libraries, and there are always intriguing alternatives. But React has three things that are absolute top priorities for us:

1. A top-notch developer experience, with nearly no state management to worry about and near-instantaneous feedback when a developer makes a change
2. A large, supportive, and famously nice community of users, maintainers, open-source add-ons, and advice outside the Magento ecosystem
3. A structured format for view changes (the Virtual DOM tree) that can be statically analyzed and/or transformed more easily than a string template with delimiters. Future optimizations will therefore be easier and more composable, since React components are written in standard JavaScript (after the simple JSX transform) and can therefore be parsed into interoperable ECMAScript syntax trees.

The Magento PWA Studio may one day support alternate application frameworks and build pipelines; we’re certainly building it to be extensible. But our journey starts with a firm commitment to ReactJS, its developer experience, and the great architectures that prevail in its community.

The Application Framework is pretty dense with technologies and patterns that are new to Magento frontends, and there are still more basic features of the Studio to discuss. In some upcoming posts, I’ll talk about:

• The Starter Theme, a reference implementation of a full Magento Theme in the Application Framework
• ServiceWorkers, the modern browser feature that adds the speed and capabilities of a native app to the Web platform, and the Magento PWA Studio’s tools for creating them
• The Build Pipeline, a custom-made build-test-deploy system in NodeJS, using that thriving ecosystem’s industry-leading tools for optimizing and bundling JavaScript and other assets

Seriously, I can hardly wait to share more. Until next time!

Afterword: Why PWA Now?

It’s worth reiterating, if just from a technical point of view, why Progressive Web Applications are the future of eCommerce in general and Magento in particular. In short, PWAs are not some special flavor of Web app; instead, they represent the modern-day best practices for making any interactive website. That’s analogous to responsive web design: when RWD emerged a few years ago and rapidly took over the web production world, the tone was less “here’s a fun new thing”, and more “here’s the right way to do things in general”. And like responsive design, there are a number of different technologies that contribute to a PWA. There are ways that a website can officially declare itself as a PWA, but that’s not a magic wand: A PWA is made by following the architecture and performance guidelines that make your site actually load progressively, and be usable and immersive in the middle of network operations or other work.

The list of core PWA features from the “Distinguishing Features” section above looks suspiciously like the requirements for a Smart Client (or its antecedent, the Fat Client architecture; I’ll stick with the lesser-known “Smart Client”, because I feel like it). It’s true: the community of Web developers tried to make smarter, more app-like website platforms already a couple of times, because the expectations of Web users kept growing, and with them, the need for sophisticated in-browser behavior. Java Applets didn’t stick, and neither did Silverlight or Flex. But this time is quite different. In an upcoming post, I’ll tell you why I think so.

We’ll have FAQs for you soon. Meanwhile, please do start the conversation at the Magento 2 Theming forum!

To Be Continued: On The Evolution of the Web Platform, And The PWA Moment.

[dewimorgan]

At first, like many old web devs, I was put off by this idea, because of past experience with "web apps" or "applets", using Flash or Java, universally recognized by developers and users alike as the Wrong Way to Web.

Thankfully, turns out PWAs are almost the exact opposite of that old type of "Web Applet":

• Rather than breaking URLs and bookmarkability for pages, every "page" is bookmarkable, and they can add even more possibilities for bookmarking.
• Rather than breaking SEO, they can even help it, though PWA SEO optimization is still a very new field.
• Rather than breaking accessibility, they can make it easier to be compliant, and can also help with i18n support.
• Rather than breaking open-in-new-tab, they can even communicate between the multiple tabs or windows for a site, and have them talk to the server as a single app, reducing bandwidth use and giving a more seamless experience across tabs.
• Rather than adding cruft to a page, they can reduce it.
• Rather than breaking cacheing, they're built around cacheing, so they can help.

So rather than destroying and detracting from the browsing experience, they leave it visually and functionally unchanged, but give developers a toolkit of extra things they can add, mostly "under the hood", which Just Work for the user and make their website more joyful to use. I doubt Magento could provide every possible feature that PWAs can do, out of the box, but by enabling PWAs, all those cool extra abilities can be added by extensions.

Applets are dead: long live PWAs!

[BenCrook]

A game changer, I'm looking forward to working with this!

Is there a rough estimation of when the studio will be available? Hopefully time is on your side this time and us devs aren't left with something that's out of date as it took so long to develop. I mainly refer to choosing LESS and Knockout for M2, they were probably a good choice when M2 was first being worked on but no longer the best choice by the time it was released.

[hancz]

thanks for the post. We've been looking forward to Magento's decision about PWA. We faced the same dilema so it came at the right moment.

Can you share more info on the following topics? We would really appreciate because any thougts can show us direction for the next weeks/months.

• Starter Theme how it's going to look? Is it going to a cover all the M2 front feaures like Luma theme covers? If so then a better name would be Default Theme. Is Magento team going to develop the components and provide instructions how to customize the look for client's theme? Implementing all M2 front features is a huge task and it would take long so we wonder what exactly the starter theme is.
• Data flow/state management are you going to provide any help with app state? Will it be components developers responsibility to get all the data from API. To better explain my question let's assume that Magento provided us with some comonents and we have a product view component. Our client requests to add a new sub component which requires extra info from API (i.e. product warranty details). Will the "App Framework" (I guess it's only for backend part but I used that name for possible frontend counterpart) allow to get those data by adjusting GraphQl query. I'm aware that there are too many unkown things at this moment but hopefully you can share some thoughts.

The reason I'm asking those questions is that we as the partner agency don't want to reinvent the whell and duplicate efforts. However on the other hand we want to work and deliver PWA stores to our clients as soon as possible. Thanks in advance. 

[Wouter Samaey]

Will this be in Community Edition?

[realchriswells]

Very much looking forward to this. No dates announced yet, but hopefully soon so I can get my mits on it!

[sschroeer]

I'm very glad to hear that, I am currently researching possibilities for Magento 2 headless solutions and the PWA Studio idea supports this in a tremendously positiv way.

I'm very shure we will see more and more of this kind of setups in the next years.

The benefits and flexibility has it's price in manner of bigger learning-curves but in my opinion this is a huge step forward.

[Tom Robertshaw]

Great news. 

I did have one question about the comment of swapping our React and Preact. As I understand it, Preact isn't a like-for-like replacement for React, hence the performance improvements. What's the reason for using React in development and then swapping it out rather than using solely Preact? Perhaps it's a risk management decision, Magento wants to commit to React rather than Preact?

It'd be great to see the service worker tool to applicable regardless if the Magento 2 store was built on top of React and an MVP of which could foreseeably be released in advance of the starter theme. 

I look forward to finding out more detail in the upcoming blog posts! Thanks to you and Magento for the transparency. 

[akent99]

Some initial feedback to respond to questions so far.

• We are going to develop in the open, and sharing early and in Agile way. The impliction is there are not hard baked timelines yet. Generally we are going to work on architectural concepts first (what will replace current layout system, how will themes work, etc) with proof of concept demos. Basically we want to solve the hard technical problems first. Then there will be a phase of "production quality" (themes, sample data). Phase 1 is meant for people interested in the future who want to be involved in designing the future, phase 2 is more "okay, this is becoming real, everyone should pay attention".
• Regarding "start theme", we welcome input here. However it is not our first priority - this is more of a phase 2 consideration. Without working out more how themes will work, its hard to be precise at this stage. Our UX team are already thinking hard here. There are lots of new issues with PWAs such as consideration about "should we make the search button active before the full page renders".
• We will include data flow/state management - but a lot of work is still required there. Both client side and server side caching strategies are important design points. We need to bake this in so all extensions know the rules and play well together.
• Should you hold back on doing your own PWA for customers now? That is hard to say. An agency doing a project for a single customer will move faster than Magento which is trying to work out platform answers for problems like the extension developer experience. We are sharing our plans so agencies can make that decision with knowledge of where we are up to and where we are going. If a merchant does decide to go ahead, hopefully any rework can be minimized because they know "we are investigating React, not Angular".
• This will be in Magento Open Source (community edition). The reason why is simple - it would be unreasonable to ask extension developers to support to frontend stacks on an ongoing basis. (Goal is to have a clean cutover at a specified release level, but it is hard to finalize without more understanding of the full story. Very important question however.)
• No dates, but will be developed in the open and community feedback welcome as we go. This is to make sure we solve real world problems, but also so if people want to start early for customers before we are ready, they can reduce any later rework.
• React vs Preact - I will leave that once for the deeper experts! But it is possible to build apps that work with both. This is an area of investigation.

[MidnightDesign]

Any thoughts on writing this in TypeScript instead of JavaScript?

[svossen]

How can I as a (frontend) developer get involved (once the project is more solidified)?

[akent99]

If you want to get involved, we have just set up a #pwa slack channel in the community engineering team slack. So if you join that slack (see https://community.magento.com/t5/Magento-DevBlog/Community-Engineering-Update-August-2017/ba-p/74220 for how to join) then subscribe to the #pwa channel. We will be doing occasional posts to the forum, but slack allows much more interactive discussions if you want to be involved deeper. The discussions there are just starting to kick off now!

[pssdigital]

Will that news affect the roadmap on Magento PWA ?https://techcrunch.com/2017/09/15/wordpress-to-ditch-react-library-over-facebook-patent-clause-risk/...

[akent99]

We are seeking legal counsel on React (and GraphQL). An official answer needs to wait for that.

Unofficially, (personal opinion, not necessarily that of my employer, [insert any other appropriate legal disclaimers here]) it can be argued the patent clause gives you MORE protection that without it. I don't think BSD etc copyright licenses give you any *patent* protection. In fact, its all "no warantees", "use at own risk" etc.

Oh, I just found this article: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c4... - basically says if their patent claim ever managed to stand up, then most likely it would cover Vue, Preact, etc as well. In those cases you have NO patent protection using those libraries, so React may actually be SAFER since Facebook explicitly let you use it.

I find it slightly interesting in a way. So many open source people say they hate patents. They stifle ideas. Patent trolls are evil people, yada yada. But when Facebook grants protection against their patents (as long as you don't attack them back), then people complain? It almost feels like Facebook are trying to say "lets all agree to not use patents against each other". But hey, as I said, this is just purely personal opinion - I don't have a legal background.

So Magento will form its own official legal opinion. We certainly take the legal aspects seriously. Working on that right now. We will then come out with an official statement.

[paales]

Hello!

I’ve though about writing a few lines, but I seem to be unable to do that, so I’ve written all my points down.

I'm a Magento developer since 1.1, Netherlands, CTO, Have build multiple PWA’s, have experience with React and Polymer.

First let met state that I am *really* happy with the direction the team is going in. I truly believe this is a great step forward and is going in the direction the web should be going.

If have a few arguments to make which can be summarized as: Use patterns, standards and principles, do not use libraries, not giant frameworks and especially don’t mix programming languages languages.

Web Components
I’m not sure if Magento should be betting on React. React is a framework, please do not buy _so_ strictly in a framework. React _will_ go away in a few years and is anti to the web-concept. React is an abstraction on top of the web to be able to build React Native.

If we were to really embrace the web as a serious platform (and we should) then we should go with open standards. One of those things is the new Web Component specification. Web Components are a nice API to build React-like components to be used in an application the way you want it. Web Components aren’t a framework, isn’t even a library, it are just web specifications.

I’m not sure what the actual advantage is to use ‘virtual dom’, if you use Web Components everything is statically analyzable like it should.

Web Components allow for:
- Pure components (no state, simple components like a button)
- CSS/JS/HTML encapsulation
- CSS/JS/HTML API’s: CSS variables, Element properties attributes and methods.

The library to build Web Components is completely irrelevant. One of the more popular ones is of course Polymer (3.0), but you can use any one of them.

Please note that web components aren’t a view layer. React is, Vue is and Polymer can be.

The important part is that Web Components are (or can be) compatible with any other view layer that is available. This decouples the actual components from the view layer which seems a great idea to me.

Performance matters
Performance matters and Magento has always been abysmal in this regard. If you need to push a complete application of the wire in a fraction of a second you better have your metrics pointed towards this.

PWA’s are harder to optimize in terms of performance than normal websites! You _need_ to have a greed/red light every step of the way to actually get something performant. Without this light, performance _will_ slip (as M1/M2 show). Lighthouse is the answer in this one. Every commit should have their lighthouse score integrated. And it should alway be 90+

ES6 is here
Browsers fully support ES6 imports and all the features of ES6. Build processes aren’t required anymore for development. If you make it so that they aren’t that will lower the barrier to entry soo much. (I’m probably in the minority here)

Do not introduce PHP in this
An app-shell does _not_ need to be generated by a phtml file. If there is nothing you are listening to, please listen to this. Decouple your frontend from your backend. Do not let the backend slip into the frontend.

Maybe this is the most important point of all, I’m not sure. But having build a website where the backend is 100% decoupled from the frontend is SO much fun.

Development velocity and assembly vs configuration
I’m not sure how to exactly explain this. Currently everything is difficult to change, but you are able to configure everything. I think this frontend should abandon that strategy in some way.

Make 90% of the system super easy to understand, 10 minutes of exploring should give you the idea: "Oh, yeah, this is how it works, that shouldn't be too hard to modify" Complex parts should be understandable within a few hours and should be fully understandable with a day.

If things are easy, not everything has to be build by Magento Inc., things become easier to customize and therefor more variety will arise.

It should be 10 minutes to add an additional field to the checkout. Thats it, if you keep that as a benchmark, we’re absolutely heading in the right direction.

Good luck
I’m not sure if this is the case any more and I hope everybody has been shaken up. Magento 1 was notorious for living in the future. It was big, it was ambitious, had frontend requirements that were gigantic for it’s time. It required JS to add a product to the cart (OMG ;-) ).

Of course times change, customers change, but we still have the current frontend. PWA isn’t about being conservative. PWA is about living in the future.

All in all, even if all points of mine are dismissed, these are great steps in the right direction. I can’t wait to offer my customers PWA’s and especially I can’t wait for Magento to be as much fun to develop with as our current PWA projects.

I have a ton more points and nuances I’d like to make, but I’ll keep it at this for now

Best of luck!

Paul Hachmang
CTO of H&O

[fzemmel]

I’m not sure if Magento should be betting on React. React is a framework, please do not buy _so_ strictly in a framework. React _will_ go away in a few years and is anti to the web-concept.

and

An app-shell does _not_ need to be generated by a phtml file. If there is nothing you are listening to, please listen to this. Decouple your frontend from your backend. Do not let the backend slip into the frontend.

I fully agree with Paul.

[rossmc]

Interesting community project doing something similar with VueJS

https://github.com/DivanteLtd/vue-storefront

[naczu]

React is an open source library under BSD, but has an additional patent clause: Additional Grant of Patent Rights Version “If you are using or considering using React in a project, you might want to consult a lawyer. Because of the patent clause, you are not allowed to do anything that constitutes as competing with Facebook. If you do take legal actions or in other ways challenge Facebook, your license to use React is immediately revoked. Your license is also revoked if you have any legal disputes if you have legal disputes with any other company using React. This is the reason why both Google and Microsoft employees are not allowed to use React.js in their work — according to Rob Eisenberg, creator of the Aurelia framework and a former member of the Angular 2 development team.” — http://react-etc.net

https://mentormate.com/blog/polymer-vs-angular-future-web-apps/

[pierreocci]

Hi,

This is not a problem anymore since September 2017. React was relicensed and is now under the MIT License: https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

Don’t worry.

[david_pawlicki]

When it comes to  Magento 2 PWA headless solution, Vue Storefront could be a good fit. Based on Vue.js designed for any eCommerce backend like Magento. We’ve just released the 1.0RC version. Among the added new features, most of the tasks were focused on: stability, extensibility and code quality. Check out more on the website https://www.vuestorefront.io/

[bhanu_sharma]

Hello,

I am a designer at Headline Interactive and we are planning to make our website www.zooster.nl in Magento Studio. As a designer what are the possiblities in PWA regarding the functionalities, interactions en flow of the website?

[Baumanator]

We're very interested in using Magento with a headless approach and are wondering if there might be any new information on this at the Imagine Conference in April. Looking forward to learning more about PWA Studio.

Also the Vuestorefront contribution is nice project we have been following and are glad to see the community has already started what I believe many ecommerce companies are considering in their next generation web stores.

[ericerway]

Absolutely! We've been hard at work with our "pre-alpha" release of the PWA Studio which is now available. In addition, we have done several demos recently with the Magento Community including Reacticon two (2) weeks ago. Full release will be part of Magento 2.3 later this year and we're focused on our "beta" at Imagine 2018 next month which will fully enable contribution.

Demos can be found on our Google Hangout with Community Engineering and our latest code is always on Github.

• YouTube: https://goo.gl/eVqNr8
• GitHub: https://github.com/magento-research

Hope that helps. Let us know if you have any questions. Thanks for the question.

[vivek_chaturvedi]

@jzetlen@ericerway 

Can the architecture of PWA is capable enough to build apk and ipa also. As we can make pwa and android, ios builds to submit on playstore and appstore with ionic 3 framework.

I must say that react is capable for web and mobile web only but if you are building an architecture considering the mobile then make it scalable to launch the PWA and mobile apps on relative store for the same, then your and developers motive to capture ecommerce market in mobile will be achieved 100%.

Please check this link - https://ionicframework.com/pwa

I hope my little knowledge will help you to decide or will give us some more points to give faith on our architecture.

Regards

[jzetlen]

@vivek_chaturvedi My first reaction to your comment is that you shouldn't need to build apk and ipa packages with a Progressive Web App, since both iOS and Android now support adding a PWA to the home screen without going through the App Store. However, I understand if your market strategy is highly optimized for the app stores specifically. If you prefer the Ionic platform and don't want to migrate, you can produce an Ionic PWA using its own tools:

ionic cordova build browser

This will produce a Web app, which you can then modify to add ServiceWorker capabilities as shown in the article you linked.

If your team is highly optimized on the Ionic workflow, and your market strategies are focused on app stores, then you should probably get into the PWA space first by using Ionic's PWA features. I don't know how performant they will be, or how suited to your particular market, but that will probably always be the case with any framework like Ionic that abstracts the platform away. If your team doesn't find the Ionic PWA satisfactory, then the next logical step is moving to Magento PWA Studio (and in general to writing for the Web directly); your team would need to pick up new skills, but they would be very useful ones.

Here's some additional background info; you may already be aware of it as an experienced Ionic developer, but for others reading I thought it might be helpful.

Ionic (and React-Native and Xamarin) provide an abstract API for view objects, routing, data and device access, and they build apps that use native system calls at runtime for those things in iOS and Android.

In contrast, the term "Progressive Web Apps" refers to the set of Web standard APIs that do similar things, but using standards supported at runtime by both Android and (newly) iOS. Magento PWA Studio uses those APIs directly, so that developers can write for the open Web instead of writing to a Magento-specific subsystem.

Both systems are powerful, flexible, and successful, but they serve different needs; it's hard to make them work together, because they both play the same role: they provide the view, component, data, and device building blocks for developers to make an app.

[vivek_chaturvedi]

@jzetlen@ericerway Thanks for the detailed answer. I agree that the future of the web and mobile is definitely PWA. Magento is the first choice for all developers to develop eCommerce website, and Magento PWA Studio is the very wise step of Magento Community to involve the mobile users more effectively ( compare to responsive websites).

Our team also develop web and mobile applications and we use Magento in almost every eCommerce websites. I believe that Magento PWA Studio is not only the service worker and manifest but it's a step to use 3-tier architecture officially for front-end application with high-performance REST APIs. Maybe in future ( version 3 /4 ) Magento officially develop REST APIs with nodeJS and with the power of NoSQL DB for high performance, or introduce any serverless architecture of the frontend for the real-time web. ( However, Magento gives it's developers all the freedom to do above things but I'm talking about official versions )

So, my earlier question was not specific to any project. But I want that Magento PWA Studio architecture should be more developer friendly and highly scalable, and the same code can be used to develop the frontend for all platforms for any kind of project. As all developers ( including me ) want to use official PWA Studio rather than their custom architecture.

Also, I know it's not launched, but by when you will be able to provide any set of instructions to developers, if we want to setup and play with Magento PWA Studio ( any beta version)?

Sorry for so many queries

[ericerway]

Thanks for your questions! We share the same excitement on PWA and the need for an improved developer experience. I'm confident you will love what we've been developing to date. 

With the technologies we've chosen and examples we've already seen of PWA in the community, reusability of code is a priority for us. We're planning to release our next "beta" of PWA Studio at Imagine 2018 in a few weeks ahead of the general availability later this year with Magento 2.3. In the meantime, we have posted the "alpha" version on Github at github.com/magento-research and have several demos available on the Community Engineering channel.

Let us know if you have any additonal questions. Thanks again.

[Shankx]

Hello Team,

Has the release of ReactJS+PWA pushed further? 
Is it still part of 2.3 ? Any update post Imagine2018 on release date for the suite?

I would really like to get clarity on this ASAP, else we'll have to start building this capability outside Magento on our own. Please suggest.

[ericerway]

Good morning, Shankx!

PWA Studio is still on track and part of Magento 2.3 later this year and we released a few examples from the Venia theme recently at Imagine. The presentation from @jzetlen from Imagine 2018 has been posted (below) and there is lots of activity in GitHub and with Community Engineering in the #pwa Slack channel. Here are a few resources that should help.

- Docs: https://magento-research.github.io/pwa-devdocs

- GitHub: https://github.com/magento-research

- Presentation: Sweet Themes Are Made of This - Imagine 2018.pdf (Imagine 2018)

Please let us know if you have any other questions. Thanks again.

-Eric

[pierreocci]

Hi Shankx,

If you want to start now and go in production in 2018, instead of
building it yourself you can also use one of the existing solutions
(Deity, VueStorefront, Front-Commerce) that are more advanced in terms
of features.
It won’t prevent you to use PWA Studio when it will be ready or if the
project is simple enough to use the few features available in the next
few months (catalog only for instance).

[normanwalter]

Hello all,

does anyone knows more about the following:

* when the frontend will become more headless and will work with Reactjs, does it also meen that new extentions / third party extentions should/have to be shipped with an own reactive frontend component?

* why using React.js instead of Vue.js? a specification for the use of React the most extension provider will switch to react components for there frontend parts or am I completely wrong?

Sorry if my questions are more simple and I hope that I don't overlooked previous answers in this regard. :-)

We're also very interested in using a headless approach of Magento and looking forward to see what comes next. 

Regards Norman

[mounika_chawla]

Do you know why this much Spotlight on what is PWA

In the last few years, mobile users are increasing, furthermore billions of people use smartphones which increases their quality of life

So, the optimization of user knowledge on the phone is essential. Lets see a a quick snapshot of

what is PWA 

[evrigmarke0a8a]

Magento PWA development services are becoming increasingly popular as more and more businesses are moving towards offering a seamless online shopping experience to their customers.

Benefits of Magento PWA development services:

• Improved Performance
• Better User Experience
• Increased Conversion Rates
• Cross-Platform Compatibility
• Reduced Development Costs
• Improved SEO
• Offline Capabilities

Magento PWA development services can provide businesses with a range of benefits, including improved performance, better user experience, increased conversion rates, cross-platform compatibility, reduced development costs, improved SEO, and offline capabilities. By utilizing these services, businesses can provide their customers with a seamless shopping experience that drives engagement, loyalty, and ultimately, revenue.