TranslateProject/sources/talk/20170908 Betting on the Web.md

[Betting on the Web][27]
============================================================

![](https://static.joreteg.com/large_background.jpg)

 _Note: I just spoke at [Coldfront 2017][12] about why I’m such a big proponent of the Web. What follows is essentially that talk as a blog post (I’ll add a link to the video once it is published)._ 

 _Also: the Starbucks PWA mentioned in the talk has shipped! 🎉_ 

I’m  _not_  going to tell you what to do. Instead, I’m going to explain why I’ve chosen to bet my whole career on this crazy Web thing. "Betting" sounds a bit haphazard, it’s more calculated than that. It would probably be better described as "investing."

Investing what? Our time and attention.

Many of us only have maybe 6 or so  _really_  productive hours per day when we’re capable of being super focused and doing our absolute best work. So how we chose to invest that very limited time is kind of a big deal. Even though I really enjoy programming I rarely do it aimlessly just for the pure joy of it. Ultimately, I’m investing that productive time expecting to get  _some kind of return_  even if it’s just mastering something or solving a difficult problem.

 [### "So what, what’s your point?"][28] 

> > More than most of us realize we are  _constantly_  investing

Sure, someone may be paying for our time directly but there’s more to it than just trading hours for money. In the long run, what we chose to invest our professional efforts into has other effects:

**1\. Building Expertise:** We learn as we work and gain valuable experience in the technologies and platform we’re investing in. That expertise impacts our future earning potential and what types of products we’re capable of building.

**2\. Building Equity:** Hopefully we’re generating equity and adding value to whatever product we’re building.

**3\. Shaping tomorrow’s job market:** We’re building tomorrow’s legacy code today™. Today’s new hotness is tomorrow’s maintenance burden. In many cases the people that initially build a product or service are not the ones that ultimately maintain it. This means the technology choices we make when building a new product or service, determine whether or not there will be jobs later that require expertise in that particular platform/technology. So, those tech choices  _literally shape tomorrow’s job market!_ 

**4\. Body of knowledge:** As developers, we’re pretty good at sharing what we learn. We blog, we "Stack-Overflow", etc. These things all contribute to the corpus of knowledge available about that given platform which adds significant value by making it easier/faster for others to build things using these tools.

**5\. Open Source:** We solve problems and share our work. When lots of developers do this it adds  _tremendous value_  to the technologies and platforms these tools are for. The sheer volume of work that we  _don’t have to do_  because we can use someone else’s library that already does it is mind-boggling. Millions and millions of hours of development work are available to us for free with a simple `npm install`.

**6\. Building apps for users on that platform:** Last but not least, without apps there is no platform. By making more software available to end users, we’re contributing significant value to the platforms that run our apps.

Looking at that list, the last four items are not about  _us_  at all. They represent other significant long-term impacts.

> > We often have a broader impact than we realize

We’re not just investing time into a job, we're also shaping the platform, community, and technologies we use.

We’re going to come back to this, but hopefully, recognizing that greater impact can help us make better investments.

 [### With all investing comes  _risk_][29] 

We can’t talk about investing without talking about risk. So what are some of the potential risks?

 [### Are we building for the right platform?][30] 

Platform stability is indeed A Thing™. Just ask a Flash developer, Windows Phone developer, or Blackberry developer. Platforms  _can_  go away.

If we look at those three platforms, what do they have in common? They’re  _closed_  platforms. What I mean is there’s a single controlling interest. When you build for them, you’re building for a specific operating system and coding against a particular implementation as opposed to coding against a set of  _open standards_ . You could argue, that at least to some degree, Flash died because of its "closed-ness". Regardless, one thing is clear from a risk mitigation perspective: open is better than closed.

the Web is  _incredibly_  open. It would be quite difficult for any one entity to kill it off.

Now, for Windows Phone/Blackberry it failed due to a lack of interested users... or was it lack of interested developers??

![](https://d33wubrfki0l68.cloudfront.net/9c118bc64747a753804bf88f16237bfe1c71905e/8d334/images/2/ballmer.jpg)

Maybe if Ballmer ☝️ has just yelled "developers"  _one more time_  we’d all have Windows Phones in our pockets right now 😜.

From a risk mitigation perspective, two things are clear with regard to platform stability:

1.  Having  _many users_  is better than having few users

2.  Having  _more developers_  building for the platform is better than having few developers

> > There is no bigger more popular open platform than the Web

 [### Are we building the right software?][31] 

Many of us are building apps. Well, we used to build "applications" but that wasn’t nearly cool enough. So now we build "apps" instead 😎.

What does "app" mean to a user? This is important because I think it’s changed a bit over the years. To a user, I would suggest it basically means: "a thing I put on my phone."

But for our purposes I want to get a bit more specific. I’d propose that an app is really:

1.  An "ad hoc" user interface

2.  That is local(ish) to the device

The term "ad hoc" is Latin and translates to **"for this"**. This actually matches pretty closely with what Apple’s marketing campaigns have been teaching the masses:

> There’s an app **for that**
> 
> – Apple

The point is it helps you  _do_  something. The emphasis is on action. I happen to think this is largely the difference between a "site" and an "app". A news site for example has articles that are resources in and of themselves. Where a news app is software that runs on the device that helps you consume news articles.

Another way to put it would be that site is more like a book, while an app is a tool.

 [### Should we be building apps at all?!][32] 

Remember when chatbots were supposed to take over the world? Or perhaps we’ll all be walking around with augmented reality glasses and that’s how we’ll interact with the world?

I’ve heard it said that "the future app is  _no_  app" and virtual assistants will take over everything.

![](https://d33wubrfki0l68.cloudfront.net/447b9cdc5e549f874d40fcccbdc6a4225d898677/b3dce/images/2/echo.png)

I’ve had one of these sitting in my living room for a couple of years, but I find it all but useless. It’s just a nice bluetooth speaker that I can yell at to play me music.

But I find it very interesting that:

> > Even Alexa has an app!

Why? Because there’s no screen! As it turns out these "ad hoc visual interfaces" are extremely efficient.

Sure, I can yell out "Alexa, what’s the weather going to be like today" and I’ll hear a reply with high and low and whether it’s cloudy, rainy, or sunny. But in that same amount of time, I can pull my phone out tap the weather app and before Alexa can finish telling me those 3 pieces of data, I can visually scan the entire week’s worth of data, air quality, sunrise/sunset times, etc. It’s just  _so much more_  efficient as a mechanism for consuming this type of data.

As a result of that natural efficiency, I believe that having a visual interface is going to continue to be useful for all sorts of things for a long time to come.

That’s  _not_  to say virtual assistants aren’t useful! Google Assistant on my Pixel is quite useful in part because it can show me answers and can tolerate vagueness in a way that an app with a fixed set of buttons never could.

But, as is so often the case with new useful tech, rarely does it complete replace everything that came before it, instead, it augments what we already have.

 [### If apps are so great why are we so "apped out"?][33] 

How do we explain that supposed efficiency when there’s data like this?

*   [65% of smartphone users download zero apps per month][13]

*   [More than 75% of app downloads open an app once and never come back][14]

I think to answer that we have to really look at what isn’t working well.

 [### What sucks about apps?][34] 

1.  **Downloading them certainly sucks.** No one wants to open an app store, search for the app they’re trying to find, then wait to download the huge file. These days a 50mb app is pretty small. Facebook for iOS 346MB, Twitter iOS 212MB.

2.  **Updating them sucks.** Every night I plug in my phone I download a whole slew of app updates that I, as a user, **could not possibly care less about**. In addition, many of these apps are things I installed  _once_ and will **never open again, ever!**. I’d love to know the global stats on how much bandwidth has been wasted on app updates for apps that were never opened again.

3.  **Managing them sucks.** Sure, when I first got an iPhone ages ago and could first download apps my home screen was impeccable. Then when we got folders!! Wow... what an amazing development! Now I could finally put all those pesky uninstallable Apple apps in a folder called "💩" and pretend they didn’t exist. But now, my home screen is a bit of a disaster. Sitting there dragging apps around is not my idea of a good time. So eventually things get all cluttered up again.

The thing I’ve come to realize, is this:

> > We don’t care how they got there. We only care that they’re  _there_  when we need them.

For example, I love to go mountain biking and I enjoy tracking my rides with an app called Strava. I get all geared up for my ride, get on my bike and then go, "Oh right, gotta start Strava." So I pull out my phone  _with my gloves on_  and go: "Ok Google, open Strava".

I  _could not care less_  about where that app was or where it came from when I said that.

I don’t care if it was already installed, I don’t care if it never existed on my home screen, or if it was generated out of thin air on the spot.

> > Context is  _everything_ !

If I’m at a parking meter, I want the app  _for that_ . If I’m visiting Portland, I want their public transit app.

But I certainly  _do not_  want it as soon as I’ve left.

If I’m at a conference, I might want a conference app to see the schedule, post questions to speakers, or whatnot. But wow, talk about something that quickly becomes worthless as soon as that conference is over!

As it turns out the more "ad hoc" these things are, the better! The more  _disposable_  and  _re-inflatable_  the better!

Which also reminds me of something that I feel like we often forget. We always assume people want our shiny apps and we measure things like "engagement" and "time spent in the app" when really, and there certainly are exceptions to this such as apps that are essentially entertainment, but often...

> > People don’t want to use your app. They want  _to be done_  using your app.

 [### Enter PWAs][35] 

I’ve been contracting with Starbucks for the past 18 months. They’ve taken on the ambitious project of essentially re-building a lot of their web stuff in Node.js and React. One of the things I’ve helped them with (and pushed hard for) was to build a PWA (Progressive Web App) that could provide similar functionality as their native apps. Coincidentally it was launched today: [https://preview.starbucks.com][18]!

<twitterwidget class="twitter-tweet twitter-tweet-rendered" id="twitter-widget-0" data-tweet-id="905931990444244995" style="box-sizing: inherit; max-width: 100%; position: static; visibility: visible; display: block; transform: rotate(0deg); width: 500px; min-width: 220px; margin-top: 10px; margin-bottom: 10px;">[View image on Twitter][10] [![View image on Twitter](https://pbs.twimg.com/media/DJKEJ1IXkAAxsY0.jpg:small "View image on Twitter")][5] 

> [ Follow][1] [![](https://pbs.twimg.com/profile_images/566823446147919872/H3Hwtjyp_normal.jpeg) David Brunelle @davidbrunelle][6]
> 
> My team at [@Starbucks][7] has been building a PWA, and it's now in beta! Check it out at [https://preview.starbucks.com ][8] if you're an existing customer!
> 
> [<time class="dt-updated" datetime="2017-09-07T23:13:12+0000" pubdate="" title="Time posted: September 07, 2017 23:13:12 (UTC)">7:13 AM - Sep 8, 2017</time>][9]
> 
> *   [ 4949 Replies][2]
> 
> *   [ 140140 Retweets][3]
> 
> *   [ 454454 likes][4]

[Twitter Ads info and privacy][11]</twitterwidget>

This gives is a nice real world example:

*   Starbucks iOS: 146MB

*   Starbucks PWA: ~600KB

The point is there’s a  _tremendous_  size difference.

It’s 0.4% of the size. To put it differently, I could download the PWA **243 times**in the same amount of time it would take to download the iOS app. Then, of course on iOS it then also still has to install and boot up!

Personally, I’d have loved it if the app ended up even smaller and there are plans to shrink it further. But even still, they’re  _not even on the same planet_  in terms of file-size!

Market forces are  _strongly_  aligned with PWAs here:

*   Few app downloads

*   User acquisition is  _hard_ 

*   User acquisition is  _expensive_ 

If the goal is to get people to sign up for the rewards program, that type of size difference could very well make the difference of getting someone signed up and using the app experience (via PWA) by the time they reach the front of the line at Starbucks or not.

User acquisition is hard enough already, the more time and barriers that can be removed from that process, the better.

 [### Quick PWA primer][36] 

As mentioned, PWA stands for "Progressive Web Apps" or, as I like to call them: "Web Apps" 😄

Personally I’ve been trying to build what a user would define as an "app" with web technology for  _years_ . But until PWAs came along, as hard as we tried, you couldn’t quite build a  _real app_  with just web tech. Honestly, I kinda hate myself for saying that, but in terms of something that a user would understand as an "app" I’m afraid that statement has probably true until very recently.

So what’s a PWA? As one of its primary contributors put it:

> It’s just a website that took all the right vitamins.
> 
> – Alex Russell

It involves a few specific technologies, namely:

*   Service Worker. Which enable true reliability on the web. What I mean by that is I can build an app that as long as you loaded it while you were online, from then on it will  _always_  open, even if you’re not. This puts it on equal footing with other apps.

*   HTTPS. Requires encrypted connections

*   Web App Manifest. A simple JSON file that describes your application. What icons to use is someone adds it to their home screen, what its name is, etc.

There are plenty of other resources about PWAs on the web. The point for my purposes is:

> > It is now possible to build PWAs that are  _indistinguishable_  from their native counter parts

They can be up and running in a fraction of the time whether or not they were already "installed" and unlike "apps" can be saved as an app on the device  _at the user’s discretion!_ 

Essentially they’re really great for creating "ad hoc" experiences that can be "cold started" on a whim nearly as fast as if it were already installed.

I’ve said it before and I’ll say it again:

> PWAs are the biggest thing to happen to the mobile web since the iPhone.
> 
> – Um... that was me

 [### Let’s talk Internet of things][37] 

I happen to think that PWAs + IoT = ✨ MAGIC ✨. As several smart folks have pointed out.

The one-app-per-device approach to smart devices probably isn’t particularly smart.

It doesn’t scale well and it completely fails in terms of "ad hoc"-ness. Sure, if I have a Nest thermostat and Phillips Hue lightbulbs, it’s reasonable to have two apps installed. But even that sucks as soon as I want someone else to be able to use control them. If  _I just let you into my house_ , trust me... I’m perfectly happy to let you flip a light switch, you’re in my house, after all. But for the vast majority of these things there’s no concept of "nearby apps" and, it’s silly for my guest (or a house-sitter) to download an app they don’t actually want, just so I can let them control my lights.

The whole "nearby apps" thing has so many uses:

*   thermostat

*   lights

*   locks

*   garage doors

*   parking meter

*   setting refrigerator temp

*   conference apps

Today there are lots of new capabilities being added to the web to enable web apps to interact with physical devices in the real world. Things like WebUSB, WebBluetooth, WebNFC, and efforts like [Physical Web][19]. Even for things like Augmented (and Virtual) reality, the idea of the items we want to interact with having URLs makes so much sense and I can’t imagine a better, more flexible use of those URLs than for them to point to a PWA that lets you interact with that device!

 [### Forward looking statements...][38] 

I’ve been talking about all this in terms of investing. If you’ve ever read any company statement that discusses the future you always see this line explaining that things that are about to be discussed contains "forward looking statements" that may or may not ultimately happen.

So, here are  _my_  forward looking statements.

 [### 1\. PWA-only startups][39] 

Given the cost (and challenge) of user-acquisition and the quality of app you can build with PWAs these days, I feel like this is inevitable. If you’re trying to get something off the ground, it just isn’t very efficient to spin up  _three whole teams_  to build for iOS, Android, and the Web.

 [### 2\. PWAs listed in App Stores][40] 

So, there’s a problem with "web only" which is that for the good part of a decade we’ve been training users to look for apps in the app store for their given platform. So if you’re already a recognized brand, especially if you already have a native app that you’re trying to replace, it simply isn’t smart for you  _not to exist_  in the app stores.

So, some of this isn’t all that "forward looking" as it turns out [Microsoft has already committed to listing PWAs in the Windows Store][20], more than once!

**They haven’t even finished implementing Service Worker in Edge yet!** But they’re already committing hard to PWAs. In addition to post linked above, one of their lead Developer Relations folks, Aaron Gustafson just [wrote an article for A List Apart][21] telling everyone to build PWAs.

But if you think about it from their perspective, of course they should do that! As I said earlier they’ve struggled to attract developer to build for their mobile phones. In fact, they’ve at times  _paid_  companies to write apps for them simply to make sure apps exist so that users will be able to have apps they want when using a Windows Phone. Remember how I said developer time is a scarce resource and without apps, the platform is worthless? So  _of course_  they should add first class support for PWAs. If you build a PWA like a lot of folks are doing then TADA!!! 🎉 You just made a Windows/Windows Phone app!

I’m of the opinion that the writing is on the wall for Google to do the same thing. It’s pure speculation, but it certainly seems like they are taking steps that suggest they may be planning on listing PWAs too. Namely that the Chrome folks recently shipped a feature referred to as "WebAPKs" for Chrome stable on Android (yep, everyone). In the past I’ve [explained in more detail][22] why I think this is a big deal. But a shorted version would be that before this change, sure you could save a PWA to your home screen...  _But_ , in reality it was actually a glorified bookmark. That’s what changes with WebAPKs. Instead, when you add a PWA to your home screen it generates and "side loads" an actual `.apk`file on the fly. This allows that PWA to enjoy some privileges that were simply impossible until the operating system recognized it as "an app." For example:

*   You can now mute push notifications for a specific PWA without muting it for all of Chrome.

*   The PWA is listed in the "app tray" that shows all installed apps (previously it was just the home screen).

*   You can see power usage, and permissions granted to the PWA just like any other app.

*   The app developer can now update the icon for the app by publishing an update to the app manifest. Before, there was no way to updated the icon once it had been added.

*   And a slew of other similar benefits...

If you’ve ever installed an Android app from a source other than the Play Store (or carriers/OEMs store) you know that you have to flip a switch in settings to allow installs from "untrusted sources". So, how then, you might ask, can they generate and install an actual `.apk` file for a PWA without requiring that you change that setting? As it turns out the answer is quite simple: Use a trusted source!

> > As it turns out WebAPKs are managed through Google Play Services!

I’m no rocket scientist, but based on their natural business alignment with the web, their promotion of PWAs, the lengths they’ve gone to to grant PWAs equal status on the operating system as native apps, it only seems natural that they’d eventually  _list them in the store_ .

Additionally, if Google did start listing PWAs in the Play Store both them and Microsoft would be doing it  _leaving Apple sticking out like a sore thumb and looking like the laggard_ . Essentially, app developers would be able to target a  _massive_  number of users on a range of platforms with a single well-built PWA. But, just like developers grew to despise IE for not keeping up with the times and forcing them to jump through extra hoops to support it, the same thing would happen here. Apple does  _not_  want to be the next IE and I’ve already seen many prominent developers suggesting they already are.

Which bring us to another forward-looking statement:

 [### 3\. PWAs on iOS][41] 

Just a few weeks ago the Safari folks announced that Service Worker is now [officially under development][23].

 [### 4\. PWAs everywhere][42] 

I really think we’ll start seeing them everywhere:

*   Inside VR/AR/MR experiences

*   Inside chat bots (again, pulling up an ad-hoc interface is so much more efficient).

*   Inside Xbox?!

As it turns out, if you look at Microsoft’s status page for Edge about Service Worker you see this:

![](https://d33wubrfki0l68.cloudfront.net/6e28110b29d042e6472c3512748ecb9f541dcb67/a2b7d/images/2/edge.png)

I hinted at this already, but I also think PWAs pair very nicely with virtual assistants being able to pull up an PWA on a whim without requiring it to already be installed would add tremendous power to the virtual assistant. Incidentally, this also becomes easier if there’s a known "registered" name of a PWA listed in an app store.

Some other fun use cases:

*   Apparently the new digital menu displays in McDonald’s Restaurants (at least in the U.S.) are actually a web app built with Polymer ([source][15]). I don’t know if there’s a Service Worker or not, but it would make sense for there to be.

*   Sports score boards!? I’m a [independent consultant][16], and someone approached me about potentially using a set of TVs and web apps to build a score keeping system at an arena. Point is, there are so many cool examples!

The web really is the universal platform!

 [### For those who think PWAs are just a Google thing][43] 

First off, I’m pretty sure Microsoft, Opera, Firefox, and Samsung folks would want to punch you for that. It [simply isn’t true][24] and increasingly we’re seeing a lot more compatibility efforts between browser vendors.

For example: check out the [Web Platform Tests][25] which is essentially Continuous Integration for web features that are run against new releases of major browsers. Some folks will recall that when Apple first claimed they implemented IndexedDb in Safari, the version they shipped was essentially unusable because it had major shortcomings and bugs.

Now, with the WPTs, you can drill into these features (to quite some detail) and see whether a given browser passes or fails. No more claiming "we shipped!" but not actually shipping.

 [### What about feature "x" on platform "y" that we need?][44] 

It could well be that you have a need that isn’t yet covered by the web platform. In reality, that list is getting shorter and shorter, also... HAVE YOU ASKED?! Despite what it may feel like, browser vendors eagerly want to know what you’re trying to do that you can’t. If there are missing features, be loud, be nice, but from my experience it’s worth making your desires known.

Also, it doesn’t take much to wrap a web view and add hooks into the native OS that your JavaScript can call to do things that aren’t  _quite_  possible yet.

But that also brings me to another point, in terms of investing, as the world’s greatest hockey player said:

> Skate to where the puck is going, not where it has been.
> 
> – Wayne Gretzky

Based on what I’ve outlined thus far, it could be more risky to building an entire application for a whole other platform that you ultimately may not need than to at least exhaust your options seeing what you can do with the Web first.

So to line ’em up in terms of PWA support:

*   Chrome: yup

*   Firefox: yup

*   Opera: yup

*   Samsung Internet ([the 3rd largest browser surprise!][17]): yup

*   Microsoft: huge public commitment

*   Safari: at least implementing Service Worker

 [### Ask them add your feature!][45] 

Sure, it may not happen, it may take a long time but  _at least_  try. Remember, developers have a lot more influence over platforms than we typically realize. Make. your. voice. heard.

 [### Side note about React-Native/Expo][46] 

These projects are run by awesome people, the tech is incredibly impressive. If you’re Facebook and you’re trying to consolidate your development efforts, for the same basic reasons as why it makes sense for them to create their on [VM for running PHP][26]. They have realities to deal with at a scale that most of us will never have to deal with. Personally, I’m not Facebook.

As a side note, I find it interesting that building native apps and having as many people do that as possible, plays nicely into their advertising competition with Google.

It just so happens that Google is well positioned to capitalize off of people using the Web. Inversely, I’m fairly certain Facebook wouldn’t mind that ad revenue  _not_  going Google. Facebook, seemingly would much rather  _be_  your web, that be part of the Web.

Anyway, all that aside, for me it’s also about investing well.

By building a native app you’re volunteering for a 30% app-store tax. Plus, like we covered earlier odds are that no one wants to go download your app. Also, though it seems incredibly unlikely, I feel compelled to point out that in terms of "openness" Apple’s App Store is very clearly  _anything_  but that. Apple could decide one day that they really don’t like how it’s possible to essentially circumvent their normal update/review process when you use Expo. One day they could just decide to reject all React Native apps. I really don’t think they would because of the uproar it would cause. I’m simply pointing out that it’s  _their_  platform and they would have  _every_  right to do so.

 [### So is it all about investing for your own gain?][47] 

So far, I’ve presented all this from kind of a cold, heartless investor perspective: getting the most for your time.

But, that’s not the whole story is it?

Life isn’t all about me. Life isn’t all about us.

I want to invest in platforms that increase opportunities **for others**. Personally, I really hope the next friggin’ Mark Zuckerburg isn’t an ivy-league dude. Wouldn’t it be amazing if instead the next huge success was, I don’t know, perhaps a young woman in Nairobi or something? The thing is, if owning an iPhone is a prerequisite for building apps, it  _dramatically_  decreases the odds of something like that happening. I feel like the Web really is the closest thing we have to a level playing field.

**I want to invest in and improve  _that_  platform!**

This quote really struck me and has stayed with me when thinking about these things:

> If you’re the kind of person who tends to succeed in what you start,
> 
> changing what you start could be  _the most extraordinary thing_  you could do.
> 
> – Anand Giridharadas

Thanks for your valuable attention ❤️. I’ve presented the facts as I see them and I’ve done my best not to "should on you."

Ultimately though, no matter how prepared we are or how much research we’ve done; investing is always a bit of a gamble.

So I guess the only thing left to say is:

> > I’m all in.

--------------------------------------------------------------------------------

via: https://joreteg.com/blog/betting-on-the-web

作者：[Joreteg][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]:https://joreteg.com/
[1]:https://twitter.com/davidbrunelle
[2]:https://twitter.com/intent/tweet?in_reply_to=905931990444244995
[3]:https://twitter.com/intent/retweet?tweet_id=905931990444244995
[4]:https://twitter.com/intent/like?tweet_id=905931990444244995
[5]:https://twitter.com/davidbrunelle/status/905931990444244995/photo/1
[6]:https://twitter.com/davidbrunelle
[7]:https://twitter.com/Starbucks
[8]:https://t.co/tEUXM8BLgP
[9]:https://twitter.com/davidbrunelle/status/905931990444244995
[10]:https://twitter.com/davidbrunelle/status/905931990444244995/photo/1
[11]:https://support.twitter.com/articles/20175256
[12]:https://2017.coldfront.co/
[13]:https://qz.com/253618/most-smartphone-users-download-zero-apps-per-month/
[14]:http://fortune.com/2016/05/19/app-economy/
[15]:https://twitter.com/AJStacy06/status/857628546507968512
[16]:http://consulting.joreteg.com/
[17]:https://medium.com/samsung-internet-dev/think-you-know-the-top-web-browsers-458a0a070175
[18]:https://preview.starbucks.com/
[19]:https://google.github.io/physical-web/
[20]:https://blogs.windows.com/msedgedev/2016/07/08/the-progress-of-web-apps/
[21]:https://alistapart.com/article/yes-that-web-project-should-be-a-pwa
[22]:https://joreteg.com/blog/installing-web-apps-for-real
[23]:https://webkit.org/status/#specification-service-workers
[24]:https://jakearchibald.github.io/isserviceworkerready/
[25]:http://wpt.fyi/
[26]:http://hhvm.com/
[27]:https://joreteg.com/blog/betting-on-the-web
[28]:https://joreteg.com/blog/betting-on-the-web#quotso-what-whats-your-pointquot
[29]:https://joreteg.com/blog/betting-on-the-web#with-all-investing-comes
[30]:https://joreteg.com/blog/betting-on-the-web#are-we-building-for-the-right-platform
[31]:https://joreteg.com/blog/betting-on-the-web#are-we-building-the-right-software
[32]:https://joreteg.com/blog/betting-on-the-web#should-we-be-building-apps-at-all
[33]:https://joreteg.com/blog/betting-on-the-web#if-apps-are-so-great-why-are-we-so-quotapped-outquot
[34]:https://joreteg.com/blog/betting-on-the-web#what-sucks-about-apps
[35]:https://joreteg.com/blog/betting-on-the-web#enter-pwas
[36]:https://joreteg.com/blog/betting-on-the-web#quick-pwa-primer
[37]:https://joreteg.com/blog/betting-on-the-web#lets-talk-internet-of-things
[38]:https://joreteg.com/blog/betting-on-the-web#forward-looking-statements
[39]:https://joreteg.com/blog/betting-on-the-web#1-pwa-only-startups
[40]:https://joreteg.com/blog/betting-on-the-web#2-pwas-listed-in-app-stores
[41]:https://joreteg.com/blog/betting-on-the-web#3-pwas-on-ios
[42]:https://joreteg.com/blog/betting-on-the-web#4-pwas-everywhere
[43]:https://joreteg.com/blog/betting-on-the-web#for-those-who-think-pwas-are-just-a-google-thing
[44]:https://joreteg.com/blog/betting-on-the-web#what-about-feature-quotxquot-on-platform-quotyquot-that-we-need
[45]:https://joreteg.com/blog/betting-on-the-web#ask-them-add-your-feature
[46]:https://joreteg.com/blog/betting-on-the-web#side-note-about-react-nativeexpo
[47]:https://joreteg.com/blog/betting-on-the-web#so-is-it-all-about-investing-for-your-own-gain