From Alex Russell’s Fluent keynote, “Progressive Web Apps and What’s Next for the Web”:
I submit that distribution is the single hardest problem in all of software. Distribution friction turns out to define entire application ecosystems. It’s the thing that singles out the web as being the easiest, most friction free platform for distributing software that the world has ever seen. …So it’s a little bit surprising to me, then, that when we made the shift to mobile devices we haven’t made the same shift in terms of how we distribute software. We’ve taken a couple of steps backwards
Alex is right. In business, as in everything, having a good idea is not enough. Getting that good idea in front of people, and making it as easy as possible for them to adopt, is the real trick.
That’s why I would love to see the Chrome team work more directly with JavaScript frameworks to improve their support for new web platform features.
The Chrome team are obviously smart folks who care passionately about the web, but I think they could be more effective in getting their ideas in front of workaday web developers who aren’t plugged in to Hacker News and the Chrome Developers YouTube channel.
I’ve been trying to express this on Twitter, but I think it came across as an attack instead of constructive feedback. Here’s my attempt to outline some changes Googlers could make that I think would improve the web for everyone.
Something I’ve come to realize is that frameworks like Angular, Ember and React are the single best distribution channel for getting new web platform ideas into real apps.
Let me give a concrete example.
(For those playing along at home, PRPL is a term coined by the Chrome team and stands for: Push critical resources for the initial route, Render initial route, Pre-cache remaining routes, Lazy-load and create remaining routes on demand.)
Alex laments that PRPL is not the out-of-the-box experience for React or other frameworks, and suggests that Polymer is a long way ahead. The point, implicitly, is that if you care about mobile web performance (and who would cop to not caring about that?) then you should be using Polymer instead of one of these legacy frameworks.
The fly in the ointment is that there aren’t that many Polymer apps yet, and in order to take advantage of its PRPL-ness, you’re going to need to first learn Polymer and then convince your boss you need to drop feature work for a few months and rewrite your app.
In the most recent Ember Community Survey from earlier this year, 74% of respondents were on one of the two most recent stable releases. The bulk of the remaining respondents were on the last stable 1.x release, setting them up to move to the latest release once they refactor away any deprecation warnings.
In practice, this means that it’s a short hop from us releasing new features to those features making their way into big, shipping, production apps.
React, with its unidirectional data flow and lightweight component model, brought a new and improved programming model to front-end development. Frankly, I was jealous, and we wanted Ember developers to have the same thing.
Rather than releasing Ember 3.0 with a brand new API and telling people to start planning for the big rewrite, we implemented an optimized engine called Glimmer as a standalone library. Then, we did the long, hard work of integrating it into Ember in a backwards-compatible way.
This week, we enabled Glimmer 2 in Ember’s canary channel. Just by upgrading, users should see performance improvements and a significant (up to 80%) reduction in template file size. We didn’t need to cajole them into rewriting. We met them where they are today.
Google has an institutional tendency to go it alone.
Consider Dart, Google’s attempt to replace JavaScript. Engineers at Google thought JavaScript was too slow and underpowered a language to be the substrate of the web.
From the Dart (then called Dash) internal announcement:
Complex web apps — the kind that Google specializes in — are struggling against the platform and working with a language that cannot be tooled and has inherent performance problems. Even smaller-scale apps written by hobbyist developers have to navigate a confusing labyrinth of frameworks and incompatible design patterns.
Dash is the leapfrog effort that is designed to be a clean break from Javascript. It will seek to keep the parts that have made the Internet so successful, but fill in holes everyone agrees it has.
They poured enormous time and money into Dart, even building an entire IDE, without much to show for it. Contrast Dart’s adoption with the adoption of TypeScript and Flow, which layer improvements on top of JavaScript instead of trying to replace it.
Or consider Native Client, Google’s non-standard sandbox for running native code on the web. Their strategy was to implement rapidly in Chrome, demonstrate to the world the performance benefits, then let the threat of losing marketshare coerce other browsers into adopting their approach wholesale. But running in one browser is not enough to make something “the web”—it has to run in all browsers.
To this day, Blink remains the only browser that supports NaCl. Meanwhile, Mozilla’s asm.js project focused on defining a subset of JavaScript that could be optimized to run at native speed. Because asm.js-compatible JavaScript is still “just JavaScript,” it can run anywhere JavaScript runs—it’ll just be faster on browsers that support asm.js. And it’s a good base to incrementally evolve towards a true bytecode for the web, called WebAssembly, which is currently happening collaboratively with other browser vendors, including Google.
I’m sure you can think of other examples of Google projects that have shown promise but had a hard time gaining traction because adoption was considered less important than engineering excellence. Counterintuitively, the decision to abandon consensus and race ahead alone ends up costing more time that it saves. While there are always outliers, by and large, incrementalism is the winning strategy on the web.
I imagine the millions of dollars Google pours into these projects and I think, just a fraction of that budget could be spent making sure framework users have an easy on-ramp to all of the good stuff coming to the web.
Google has done stellar work on Service Workers, Web Components, HTTP2 and more, and I want nothing more than to get those features into as many web apps as possible. Here’s what I think Google could do to improve the real-world experience of writing a web app in 2016.
Embrace Community Frameworks
I would love to see the Chrome team offer a full-throated endorsement of frameworks. Instead of a tepid “Yes, frameworks exist. Some people like them. But have you considered Using the Platform?,” acknowledge the benefits of frameworks and help people understand how to use them effectively.
One of the highlights for me from this year’s Google I/O was Addy Osmani’s Progressive Web Apps across all frameworks talk. In it, Addy delved into how users of Ember, React and Angular can start taking advantage of Service Worker today. He highlighted addons that make integration as simple as a single npm install. You’re left thinking, “Wow, this is awesome, I can add it to my app right now.”
But it’s more than that. Addy has been proactive in reaching out to us, asking how he can help us adopt PWA techniques, and listening to our concerns. In my opinion, Addy should be a role model for how browser vendors do community outreach. I would love if he had more resources to work on this.
My hope is that 2017’s Google I/O Chrome keynote closes by saying, “We’ve seen a lot of cool new stuff today, and we’re excited to tell you we’ve been working closely with the open source frameworks you already use to make it easy to adopt today.”
Prioritize Framework Performance
As it was put to me, “the V8 team has focused first and foremost on being fast for fast code and only secondarily on speed for code that chooses to use slow patterns.”
This is an absolutely noble goal, but the reality is that most JavaScript is not written like C; real world JavaScript tends to be very dynamic. Incredibly subtle changes can impact performance by an order of magnitude or more. It’s impossible to reason about; you’d have to audit each change in low-level tools like IRHydra by hand, which is to say, performance regressions are common.
The proof is in the pudding: whatever the microbenchmarks say, when it comes to real world applications, other JavaScript engines tend to perform better than V8. It’s no accident; they include representative framework apps in their performance test suites.
I would love to see V8 incorporate benchmarks of large Ember, Angular and React apps in their performance suite. A JavaScript engine must be optimized for the code that exists, not the code you wish existed. It’s not okay to say “You’re slow on Chrome because you wrote slow code, rewrite your framework” when performance is so much better on other browsers.
Contribute Directly
All of the popular web frameworks are open source and have vibrant communities around them. There are people whose dream job would be working for Google to bring the latest and greatest web technologies to the framework they love.
Use some of the budget to hire a few core contributors whose full-time job is making the default Ember CLI, create-react-app or ng-cli experience PRPL- and PWA-compatible. Default behavior counts for a lot. Developers have a cognitive budget just like everyone, and they’ve been told to develop accessibility-first, mobile-first, test-first, and more.
What if instead of trying to stand out in the avalanche of advice developers are overwhelmed with, you could get them to do the right thing just by using a tool they already know?
Secure-by-default is a principle the Chrome security team has adopted, because they know it’s not realistic to be able to educate every user about always-evolving security best practices.
For similar reasons, I would love to see Chrome adopt fast-by-default as a principle, going to where developers are today and making sure the tools they already know how to use do the right thing, automatically.
Whether we think they’re smart enough or not, developers of all stripes are going to be writing more web apps, not fewer. Let’s challenge ourselves to build tools that help everyone create fast web apps by default. I’m eager to do my part. Chrome dedicating resources to work directly on popular frameworks would be an incredibly high-impact way to improve the performance of today’s web apps for a very small investment.
Being directly involved with frameworks is also a great way to improve the standards process. Having Googlers embedded in outside communities allows the folks designing new platform features to get rapid feedback from a diverse set of communities, not just internal Google projects. Having diverse, first-hand knowledge of how new features are being used will help mitigate against blindspots and catch design flaws earlier, when they’re easier to fix.
When you work as hard as the Chrome team does to land new features in the browser, I can understand why it’s frustrating to see people treating adoption with what seems like a lack of urgency. I still remember a talk from a few years ago when a member of the Chrome team chastised Ember for “going in the wrong direction” by not immediately adopting Web Components, which were described as the future of the platform, despite only having been introduced a few months prior.
Working on greenfield apps and frameworks can easily seduce you into thinking that it must be either laziness or stupidity that would prevent others from seizing on the same bright ideas.
It turns out incrementalism carries a significantly higher implementation cost. You have to move slowly and carefully. It’s tedious and often boring. Most software engineers prefer working with clean code and beautiful architecture; incrementalism is anything but, often having to support two paradigms at once. You write split-brain code.
But once you do ship, developers get the new features without having to learn an entirely new system for building apps. They don’t have to wait for approval to do a rewrite. They can improve their app without slowing down their own feature work. You do 10× the work, but you reach 1000× the audience.
Ember has been working on making PRPL the out-of-the-box experience, and has been for awhile. Mobile web performance is our #1 priority, and we’ve got many different ongoing initiatives to improve it. But we need to do it without breaking the many companies and individuals who bet their future on us, and the large and growing ecosystem of addons that our community relies on.
No team is a monolith, and I know the Chrome team is made up of different individuals with different opinions.
But Google is still a juggernaut with a $530B market cap that controls how the world searches for information, how they access the web, and how they use their smartphones. It’s no exaggeration to say that the opinions of a few Google employees can impact how billions of people use the web.
I’m not privy to Google’s internal politics; I can only try to read the tea leaves from the outside. That there are some people who embrace community frameworks does not remove the danger from people higher up the org chart who don’t. As someone who believes strongly in an open web, free from the control of any one entity, I can’t help but worry about the worst case scenario.
I would love the Chrome team to openly share the same excitement that I see every day when I talk to developers who love using Ember, Angular and React. Web applications have never been more capable, or more accessible to the average developer. We’ve grown from hacking them together to a cottage industry of sophisticated tools, including frameworks.
These frameworks are as essential to the modern web app developer as CSS and HTML. We should focus on making them the best they can be, not lamenting their existence.
More importantly, frameworks are our best chance for getting all of this awesome new stuff into real apps, today, without yet another rewrite. I’d love to see the Chrome team put their significant talent and energy into helping us make the existing community frameworks better, and actively encourage people to use them.
