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
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.
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?
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.
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 core concepts and technologies in the Magento PWA Studio are currently:
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.
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:
At runtime, the Application Shell template should receive an Application block instance, that can supply it with inlined asset strings and metadata listed above.
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.
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.
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:
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:
Seriously, I can hardly wait to share more. Until next time!
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.