Designing a Progressive Web App with Firebase – Designer vs. Developer #25

Designing a Progressive Web App with Firebase – Designer vs. Developer #25


DAVID EAST: All right. I’m going to be rolling
my sleeves up and writing code all day. And I was shocked to
see that most of my time was spent in user studies. MUSTAFA: Historically,
we’ve been designing and developing sites where
you load everything in one go. But that doesn’t seem
to make much sense. One of the challenges for
designers and developers with PWAs is
Google’s been pushing that this is a great way
to make your site behave like an app-like way. There’s lots of
APIs that you can access, like for mobile
devices, especially. But it’s really hard to do it. The entry barrier’s really high. And I know Firebase
is working on ways to mitigate that, making the
barrier to entry really low and easy to use. How is Firebase doing that? DAVID EAST: Like how
you said there’s these like these app-like things. And so you kind of
think, OK, well, what do people expect with apps? You usually see things that
are 60 frames per second, or things that just feel very
instant, and just you tap it, and it’s there. Data updates. And with the– Firestore is
this database where you just update one thing,
and then almost immediately you see that
other device just update. And it went through the
cloud and everything. And whenever one
change happens, it just synchronizes across all
these connected devices. And that is one of those
things that gives you this app-like element
that you see things that change immediately, that your
data is sort of ubiquitous across all your devices. And also with apps, you expect
them to just work offline. MUSTAFA: Yeah. DAVID EAST: And if you install
an app, for the most part, it’s all there. And Firestore does
the same thing. Whenever you make a change, it
will actually save it locally. So when you go offline– I built a camera PWA. And I was really trying to find
these instances where, what’s something that I can build that
works the same offline that it does online? And if I just do it online,
I see changes across, like a note-taking app. But with the camera app, you
use the web, user media API, built a little
camera, take pictures. And then it saves it,
and this photo feed. And the cool thing is it’s
like I’ll go on an airplane. I can take pictures. It’ll keep it on
the local device. Then once I get
onto the network, it just starts syncing. And that wasn’t something that– I didn’t have to install my own
database on a server or locally or set up all this talking to
IndexedDB and all this stuff. And it’s just like I just
use the Firebase library, and I just sort of get these
features out of the box. And I kind of just get rolling. And I get to care about building
my app, and not caring about, how does offline work? How does this data
connection work? I get to kind of
focus on the things that I would rather be doing. MUSTAFA: So in
terms of using it, one thing I’ve
been speaking about with, say, Alex Russell
was tool adoption is all about ease for the
developer or the designer. So WordPress was the
one install, made it. DAVID EAST: Five-minute install. MUSTAFA: Even though I mean– I know it’s fashionable to hate
PHP and WordPress and whatever. But it’s designed as
a tool for someone to use and get off
the ground just to do the job they want
to do without installing 100 different libraries. It was really good at that. I mean, Firebase,
presumably, is following that same kind of philosophy. It’s just really
simple to set up. DAVID EAST: I mean,
from like the– I’ve been working
on Firebase just– like two weeks ago was my
fourth year on Firebase. And even my first
week there, we spent the– we were actually trying
to launch Firebase hosting. And all I did was spend all this
time in user study meetings. And I had joined this company. We were building real-time
database and JavaScript libraries. And I thought, all
right, I’m going to be rolling my sleeves up
and writing code all day. And I was shocked to
see that most of my time was spent in user studies. And I would just sit in that
double-pane style window. I mean, not literally, but it
felt like that, because you would look at the user. And they would
just be struggling trying to get something set up
that you knew exactly what they needed to do next. You’re like, click that button. Just please click that button. And they look at you, and
they’re like, what do I do? And you’re like,
I can’t help you. And so watching users
not get it shows that it’s a reflection on you. So we’ve been focusing
from the very start. If you can’t just get up
and running in five minutes, it’s not going to work. And so the whole
point we always saw is we paint this picture
of what we want to achieve. So in the beginning, it was,
let’s drop this JavaScript library in. And now we have this
real-time connected app. And you didn’t have
to set anything up. And then we evolved
onto authentication. And it was like,
OK, I want to be able to log in
users with Google, with email password, all these
different types of providers. And I want to run a server. I also drop in a
JavaScript library. And now you have that. And then with hosting,
it was the same thing. How fast can we get that
site from not existing on the internet to
deployed with SSL on a CDN, and just like by default
just has a fast performance? So all those things are
just sort of in our blood. It’s just always been our
number one guiding principle. It’s like low barrier to entry,
get started in five minutes, and just go. MUSTAFA: So say like I wanted– I’m a web designer who
is not very technical, and I just wanted to get my
site up, like a custom domain. I’ve built my– I don’t know– Davideshop.com, whatever. How quickly can I get that
web URL, that custom domain, and my server up together? DAVID EAST: I actually own
DavidEa.st. I’m very proud of that one. So with Firebase
hosting, if you– it doesn’t matter who
your domain provider is. With Google domains,
it’s really easy, because we have
worked with them. But pretty much you deploy
out your Firebase hosting. And you get whatever
your project name is dot Firebase at dot com. And that’s like
SSL out of the box. You have your green
lock automatically. And then we have a sort of
like web UI, where you say, OK, I want to set
up a custom domain. And pretty much we
say, OK, you have to put these records into
your domain registry, and then you click this button. And we’ll check to
see if they exist. And when they do, that’s it. Your domain name is
just set up that fast. MUSTAFA: That’s amazing. I mean, there is some
critique of Firebase, though. And a lot of it has
to do with speed, because we always push using
the [INAUDIBLE] JavaScript. Go the basic minimum. Get something painted on
screen as quickly as possible below 3 seconds. And there’s critique
that the Firebase include is quite large. So it’s almost like there’s
two conflicting things from our point of view. And what can developers
do to solve that problem? And what does Firebase do? DAVID EAST: Well, I
think like the web is kind of at like
this weird point where we’re trying to
do so much with the web. Like you’re saying, we want
it to be more app-like. Well, with apps,
they have this– they can include a 50 megabyte
library that goes through at install time, and it’s
just like it goes over Wi-Fi. No sweat off someone’s back. For the web, that’s
unacceptable. You can never have 50 megabytes
of anything on the web. And so we’re in this battle of,
how do we get more features, but yet not lose this
foundational principle we have of being like fast loading? And so what I’ve
been doing is kind of thinking about, OK, well,
what is the first thing you have to do to load? So you always need this
really minimal viable part of your app. And so the Firestore
library is a larger library, because it does so much. It’s basically like your own
little database in the browser. And even for a database,
it’s still, I would say, really small. But yeah, it does a lot. But you don’t want that. If you’re serving
content to users, you don’t want that library
sitting in your critical path. You can render HTML on the
server, send that down, and you just have HTML, CSS,
and this really minimal layer of JavaScript to
do your rendering. And then what I’ve found is that
when you run sort of Firestore in this way where it becomes an
enhancement on top of that app, then when it loads, the
real-time just kicks in. The offline kicks in. And this architecting
with your app, your user continues
to use it, and then as they continue to use it,
just get that enhancement to it. And you don’t want
to say, OK, my app is only available once
every single asset I have is needed for it. You have to have that
progressive bootstrapping of your app. If you’re going to combine
having features on the web and also being performant. MUSTAFA: I mean, I
know you’re working on an architectural concept
where you’re splitting things into three. Could you explain a
bit more about that? Because there was an
app you were working on. DAVID EAST: I thought I was
coming up with my own thing. But it’s kind of like, if you
think that you’ve done it, you just have to go see if
[INAUDIBLE] has done it first, which he has. He even has a word for it. Progressive bootstrapping is
sort of the way to think of it. So the very minimal thing
you need for your app is just HTML and CSS. That will get you really far. And then a having a JavaScript
sort of layer on top of it, whether you’re
using a framework, like React, Preact,
Angular, whatever, that can just be an enhancement
on top of the HTML and CSS. And at that point,
you have this app that can function every
time it receives data. So something comes over the
network, the view changes, or the user interacts with it. Something in the app
becomes more dynamic. And it doesn’t really matter
where the data comes from. The app can be fairly
like agnostic of that. So if you architect
it in a way where if you just progressively
load Firestore into it, when Firestore is
ready to be loaded, these features just
kind of like trickle in. And then the user just
now all of a sudden might see things
animate on the page when they appear in real-time. Then when they go
offline, that data is then cached on the device. MUSTAFA: Quite often, I
mean, historically, we’ve been designing and
developing sites where you load everything in one go. But that doesn’t seem
to make much sense. So is what you’re
advocating that you’re only calling for features as
and when they’re needed? So you’re not loading the whole
database if it’s not required. You’re not loading
the notification bit if it’s not necessarily
in that particular point. DAVID EAST: I mean, code
splitting in some ways works really well for that. You’re basically saying,
OK, you divvy your app up into separate
routes, like I don’t want to load slash profile
code on my Home page. It doesn’t make sense. I can have a performance
gain by just not including that when it’s not needed. This is more so of a
way where you’re saying, I will need Firestore, but
I don’t need it immediately. And if including this
JavaScript in my critical path is going to cause the app
to take longer to load, then let’s find a way
to sort of ease it up. So we kind of progressively give
the browser what it can handle. So let’s start out
with HTML and CSS. That appears. And then we have our
JavaScript that enhances it. So it becomes very easing. And so we do intend on
having all these things, but if something happens–
the user is not running JavaScript– OK, that’s fine. We still have content for them. Or let’s say they’re on
a really slow connection. Well, we did get
the initial content. And then we also got the
JavaScript framework. But it’s going to take
longer for Firestore to load. And maybe that times out,
and that never loads. But the app still is usable
in each one of these forms. And so we aspire to get all
three of these on the page, but we sort of have
these escape hatches, where as long as we get
to one of these points, we’re going to be OK. Wait. OK. There’s a heartbeat. I think there’s a whistleblower. MUSTAFA: It may be someone
just using their lawn mower. DAVID EAST: Yeah. SPEAKER: It’s actually
getting louder now. No, it’s not. DAVID EAST: [LAUGHS]

8 Comments

  1. Interesting, just been to European tech conference and approximately 20% are aware of PWAs. In my opinion, everything which doesn't require computational power or special hardware access/processing – should be Progressive Web App. When I'm using a LinkedIn on iOS, I'm not sure why should I waste a good 100M+ on nothing more than a content displaying 🙂

  2. I feel as though PWAs make the developer more important because the skills required mimic desktop/store apps rather that trad web-pages. Issues such as first render speed and time to where the app is responsive for the user on first load bring developer skills to the fore. After the PWA is 'installed', potentially on first use, the downloaded assets no longer require a network connection to display the UI and run. Having a great UI/UX is always important but first & foremost PWAs need to be carefully crafted by developers to ensure they are performing very well.

Leave a Reply

Your email address will not be published.


*