Going Progressive with Ember
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 28 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/33638 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
EmberConf 201724 / 28
9
13
14
16
17
18
23
24
00:00
VideokonferenzCodeWort <Informatik>Rechter WinkelArithmetische FolgeWeb-Applikation
00:33
W3C-StandardApp <Programm>Mobiles InternetRechnernetzPlastikkarteMobiles InternetBenutzerbeteiligungIdeal <Mathematik>CASE <Informatik>LastWellenpaketAggregatzustandTechnische OptikSichtenkonzeptWort <Informatik>Rechter WinkelPunktFilesharing-SystemTouchscreenMultiplikationsoperatorArithmetische FolgeApp <Programm>Web-ApplikationComputeranimation
01:47
GraphiktablettWeb SiteMobiles InternetBenutzerbeteiligungTouchscreenDesign by ContractVorlesung/Konferenz
02:23
W3C-StandardApp <Programm>Lokales NetzSpezielle unitäre GruppeInstallation <Informatik>App <Programm>BenutzerbeteiligungDifferenteFehlermeldungWeb-ApplikationPunktWeb SiteArithmetische FolgeLastGruppenoperationComputerspielComputeranimationVorlesung/Konferenz
03:42
App <Programm>W3C-StandardApp <Programm>DifferenteInstallation <Informatik>BenutzerbeteiligungWeb-SeiteRechter WinkelCodeClientArithmetische FolgeFluss <Mathematik>Zellularer Automat
04:35
ClientMini-DiscDatensichtgerätBildschirmsymbolGraphische BenutzeroberflächeWhiteboardDeskriptive StatistikInstantiierungDifferenteTVD-VerfahrenPunktSchnittmengeTouchscreenBildschirmsymbolInformationGraphfärbungBrowserGraphische BenutzeroberflächeElektronische PublikationMathematikFlächeninhaltKonfigurationsraumWeb-SeiteApp <Programm>
05:41
WinkelClientSpezialrechnerResultanteApp <Programm>Graphische BenutzeroberflächeInformationBildgebendes VerfahrenHumanoider RoboterBildschirmsymbolMeta-TagGraphfärbungEin-AusgabeBrowserDefaultWeb-SeiteZweiKugelMereologieHypermediaTypentheorieMultiplikationsoperatorStatistik
06:40
SpezialrechnerDatensichtgerätFarbverwaltungssystemInstallation <Informatik>BildschirmfensterInformationMeta-TagCASE <Informatik>KonfigurationsraumHypermediaWort <Informatik>Typentheoriesinc-FunktionElektronische PublikationApp <Programm>BildschirmsymbolMathematikTouchscreenATMBrowserGraphische BenutzeroberflächeBenutzerbeteiligungMultiplikationsoperatorDifferenteInstallation <Informatik>Shape <Informatik>GeradeComputeranimation
08:10
Dienst <Informatik>SkriptspracheWeb-SeiteEreignishorizontInstallation <Informatik>StrahlensätzeSynchronisierungCachingDefaultDruckverlaufKonfigurationsraumDienst <Informatik>Web-SeiteCodeBenutzerbeteiligungApp <Programm>ResultanteSoftwareCachingInstallation <Informatik>EinsSkriptspracheExogene VariableWeb SiteProxy ServerTouchscreenEreignishorizontGruppenoperationp-BlockBrowserSystemaufrufElektronische PublikationAutomatische IndexierungLeistung <Physik>Inhalt <Mathematik>CASE <Informatik>Offene MengeSynchronisierungBildgebendes VerfahrenDefaultThreadPhysikalische TheorieKonfigurationsraumMultiplikationsoperatorIdentitätsverwaltungInstantiierungAutorisierungAnalogieschlussDreiecksfreier GraphComputerspielRechnernetzDigital Rights Managementsinc-FunktionSOLOMON <Programm>Element <Gruppentheorie>Zellularer AutomatAnalysisDemoszene <Programmierung>PunktOrdinalzahlInformationServerProgramm/QuellcodeComputeranimation
13:18
EmulationApp <Programm>Dienst <Informatik>ServerDefaultSoftwareInstallation <Informatik>URLSystemaufrufEinsCachingEinfach zusammenhängender RaumÄußere Algebra eines ModulsFrequenzKonfigurationsraumMetropolitan area networkComputeranimation
14:27
ImplementierungGraphische BenutzeroberflächeInternetworkingGraphiktablettBrowserGraphische BenutzeroberflächeRechenwerkDienst <Informatik>SoftwareentwicklerEin-Ausgabe
15:11
CachingBrowserCachingKartesische KoordinatenFamilie <Mathematik>App <Programm>Computeranimation
15:35
TUNIS <Programm>SoftwareCachingDienst <Informatik>Kartesische KoordinatenDifferenteElektronische PublikationWort <Informatik>Computeranimation
16:13
ProgrammierumgebungRechnernetzInformationsspeicherungAutomatische IndexierungStellenringZeichenketteClientSynchronisierungBrowserBenutzerbeteiligungStellenringWrapper <Programmierung>AusnahmebehandlungEinfach zusammenhängender RaumInformationApp <Programm>InformationsspeicherungServerBildgebendes VerfahrenCachingEndliche ModelltheorieZahlenbereichProgrammbibliothekCASE <Informatik>Elektronische PublikationFunktionalSchlüsselverwaltungPlastikkarteGradientSpezielle unitäre GruppeAnalysisARM <Computerarchitektur>GruppenoperationInstantiierungPCMCIAGeradeMereologiePunktAutomatische IndexierungAggregatzustandWald <Graphentheorie>HilfesystemLastEinfache GenauigkeitZeichenketteDatenbankComputeranimation
19:32
VolumenvisualisierungWeb-SeiteServerBetafunktionBootenApp <Programm>Web-SeiteVolumenvisualisierungBildgebendes VerfahrenTouchscreenLastWeb SiteWeb-ApplikationServerApp <Programm>MaßerweiterungRoutingSyntaktische AnalyseFramework <Informatik>Physikalisches SystemMereologieMobiles InternetPunktZweiMultiplikationsoperatorBootenSoftwareGraphische BenutzeroberflächeGruppenoperationWort <Informatik>UnrundheitSoundverarbeitungAtomarität <Informatik>InstantiierungSinusfunktionBitRechter WinkelWeg <Topologie>Ultraviolett-PhotoelektronenspektroskopieTaskWald <Graphentheorie>t-TestComputeranimation
22:46
Wurm <Informatik>PERM <Computer>GammafunktionMenütechnikVisuelles SystemMaß <Mathematik>KommensurabilitätNormierter RaumVerkehrsinformationSoftwaretestSchnittmengeInformationLastTouchscreenGeradeDienst <Informatik>BildschirmsymbolApp <Programm>Computeranimation
23:22
CachingMenütechnikRuhmasseZeitbereichWeb-SeiteMixed RealityGraphische BenutzeroberflächeInklusion <Mathematik>Physikalische TheorieDienst <Informatik>Web-ApplikationApp <Programm>LastWeb-SeiteComputeranimation
23:48
BootenCase-ModdingURNBootenMultiplikationsoperatorDienst <Informatik>Computeranimation
24:14
BootenPunktCASE <Informatik>Computeranimation
24:37
NormalvektorKonvexe HülleZeitbereichVolumenvisualisierungVakuumZwölfWeb-SeiteLokales MinimumCAN-BusCASE <Informatik>ProgrammbibliothekHilfesystemBootenProzess <Informatik>App <Programm>Web SiteBrowserBenutzerbeteiligungWechselsprungComputeranimation
26:01
XMLComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:12
I'm Samantha. I'm here to talk about progressive web apps and how to do them with Ember today. I work at YWorks with this awesome people.
00:22
Oh, OK. We basically work with Rails and Ember right now, and we come from Uruguay. Homer is pointing there. Where'd you find it? So to start, let's see what a progressive web app is. What's the definition?
00:41
In Adios Mani's words, a progressive web app takes advantage of new technologies to bring the best of mobile sites and native app to users. They are reliable, fast, and engaging, and they originate from a secure origin and are low regardless of network state. Why should we care?
01:01
Someone may be asking. So I have a dream. This year I was vacationing in New York, and I just wanted to know the train times. So I Googled, just as everyone does, and I got this screen. I'm fairly sure most people have seen this screen
01:21
at some point. And I don't actually want to download every app. In some cases, I'm just going to be using the web for a couple of days, or maybe just once. And it's not the only case. Here, I can use this app, so this is not so bad. But it's still asking me to download something,
01:42
even though the web is totally usable from a mobile device. If you were here at last EmberConf, Tom and Yehuda actually talked about this, and what the Ember community was going to be doing to improve the mobile web, and what we can do to use this.
02:00
And that screen that I don't want to see anymore is not the only reason we should care about improving web on mobile devices. Because most of the traffic nowadays come from cell phones. So almost 70% comes from a mobile device. So making our Ember apps work better,
02:21
I think is a safe bet here. So going back to what a progressive web app is, and how we can make one, one of the first points is that our app has to look good on a device. I mean, this is fairly straightforward. I think nowadays, most webs do look good.
02:41
They are responsive. If you try to find an example of a site that is not very good on mobile, it's actually hard to find it. But we can do some small things to improve this. The second point would be that our app could be installed on the device. One of the differences between the web and native apps
03:02
is native apps are accessible through the home screen. We can also achieve this with a web app. They work offline. I think this is one of the biggest differences. Native apps, even if they don't completely work when you don't have connection, at least they show something. They load, and they show up at a better error
03:22
than what we get on the web. But we also have ways to achieve this with a web app. And the big point, the performance, as Juhua talked about, still some people prefer native because they work faster than web.
03:44
So let's start with the looks. Here I have native Trello and web Trello. I'm going to be using this as an example. And I have my progressive Trello client. You can check the code later at GitHub. If you look at both, they do look fairly well on the device.
04:01
There is not such a big difference. There is basically a style difference, but you can get both looks with HTML and CSS. That's not so hard. So the main difference here is the nav bar. So that's the only thing saying the one on the right is not a native app. But we can change this.
04:22
We're going to be seeing this in a minute, also how we can make our app install on the device or get a similar experience to uninstall. For this, we are going to use the app manifest. So the app manifest is basically a JSON file with a set of configurations. For instance, we can tell the name of our app,
04:44
the description, the theme color, the background color, and the icons. And the browser is going to take this information to make the experience better for native users. So here I have my app before the app manifest.
05:02
If I save it to the home screen, I just get a generic icon that doesn't say much. And after I load the app again, I still get the Chrome, the browser. So you know it's not an app. After I add the manifest, I already see some change on an app bar.
05:22
I get the icon that I want. I get the name that I want. Again, I get a splash screen. So it's getting better already. And I lose the nav bar. So at this point, this looks like a native app. There's not such a big difference. And this didn't take much effort,
05:41
except that only Chrome supports the app manifest. Yeah. Well, it's not so bad. Don't despair. We do have ways to get the same result on iOS. You just need to add some meta tags to your HTML.
06:00
You also give the icons, the name, the color. Here is my app on iOS. So the icon they get by default without these tags is better than Android. At least they show an image on my app. And I still see the browser here.
06:20
After I add the meta tags, I get the icon that I want. I get the name that I want. And after I load it again, I lose the nav bar. So we get a similar experience as with the app manifest, which is to add more information.
06:41
This is how you can do it on Windows if anyone needs to support it. Also, some meta tags and a configuration file. Basically, the information is the same in every case. The icons, the colors, the name. But since we are doing Ember here, you don't have to write every file. We have an add-on for this.
07:01
With the Ember web app, you install the add-on and add a configuration file. I'm going to show you there. It's similar to the app manifest. But the add-on by itself generates the JSON file, the meta tags. So you don't have to support every case. The add-on does this for yourself.
07:22
This is how I imagine it would work if the app manifest was supported by every browser. You just need one config file. So up to here, we've seen a small change that we can make to our apps and make them look more native and make the install experience better.
07:40
So we can have the icon that I want on the home screen. But we need to see how to make our app work offline or behave better. So first, that's our app work offline. Here, I'm enabling the airplane mode. I have my app saved on the screen.
08:03
I see the splash screen, and then I see the dinosaur. So yeah, we know this is Chrome. For this, we're going to use the service worker. How many people here have used or heard of a service worker? OK.
08:21
Yeah, I figured. So this is not so new. So for the ones that don't, a service worker is basically a script. It runs on the background. You declare it on your page, and it gets downloaded with your page and installs on the browser. And it runs on the background, so it doesn't block your UI thread, and it allows you to do stuff,
08:42
even if you're actually doing something else on the screen. It doesn't need your web page to be open. The browser can run it, even if your site is closed. And it doesn't need the user to actually do something. You can do a lot of actions.
09:01
Here, we have the lifecycle of a service worker. What happens after it's downloaded by the browser? There's a few events that we actually care more here. The first is install event. This is after your service worker is downloaded. Here, you can, for instance, unload your app assets.
09:22
We're going to see it later. After the install event, if everything works, you get your service worker activated. Here, you know your service worker is running. And I think this is the one that we care most. Basically, your service worker is going to act as a proxy. So for every request that your site makes,
09:42
it's going to go through the service worker. And it gives you the flexibility to actually decide what to do with that request if you actually wanted to go to the server or not. So one thing we could do, as I said, is save all the assets of your app on the install event. So I can download all the HTML, the CSS, the images
10:03
that I need, and save it on my device. And I will have it from now on. So even if I'm offline, I can still show that. It would be something similar to downloading your native app so we can get a similar result. As I said also, it intercepts every request.
10:23
So here, we can, for instance, cache all the responses for every request our site is making. We also can check if the network is available or not and return something from the cache or return any default response or go straight to the network. It gives us a lot of flexibility
10:40
to make our app work offline. Background syncing. Since it runs on the background, it doesn't require your app to be open. You can do some stuff even after the user closed the website. One of the things is bringing more data. If you have a news app, for instance,
11:01
you can download the latest news and then notify the user, because we also have access to push notifications here. So we can get the latest info, show a push notification, just like a native app does. And I love more stuff. The people that is developing service worker is also adding more support for other APIs.
11:24
It's going to give us a lot of power to be able to do stuff from the web that we could only do native before. And yes, we have add-ons for it. So you don't have to write the code for your service worker. I mean, you could, but you don't have to.
11:42
And this is a good start. Both add-ons achieve the same result. They just take a different approach. So you can pick the one you like more. Ember Service Worker takes an applicable approach. So the basic add-on just registers your service worker and coordinates all the add-ons that you have on top.
12:02
So for instance, up to this point, I just have a service worker. But I don't have my app working offline. If I add worker index and asset cache, I have all the assets from my app cached when the service worker is installed. So after I access my app once, I already have this saved.
12:21
And if I am offline, I can at least show the HTML and the CSS. But you still need to handle on the case for the rest of the request the content. And we also have an add-on for that. There's a lot of add-ons, actually, that you can pick. But this one is the basic one for me.
12:42
Basically, what it does is if the network call fails, it returns what you have on the cache. And it also caches what comes from the network. So after a user has accessed your site once, he will be able to at least see what he already saw the last time. They promise that you can have an offline first app
13:01
in 30 minutes, and it's true. The other add-on, you can also do the same thing. It takes a different approach. You need to give a configuration file. So by default, just by installing the add-on, you have your assets cached. If you add here your configuration,
13:23
you can name all the URLs that you want to have cached on the install. So they are going to be available always. Also, what happens when a network call fails, you can have some asset that is going to be returned always by default.
13:42
And you can also name all the URLs that you want to go to the server first. And then if that fails, you can return something from the cache. There are other alternatives also, but these are the basic ones. So here's my app before the service worker. We remember this.
14:02
Here's my app after the service worker. So I don't have a connection, but I'm still seeing the same that I saw on the last first I opened my app. So the app is working offline.
14:21
That's it. Yeah, but it can't be that easy, can it? So nowadays, only Chrome, Firefox, Opera, and Samsung support service workers.
14:41
Edge has it in development, but Safari doesn't. And we don't know if they will and when they will. So we need another solution for this. If you're thinking of not supporting iOS users, they do represent like 22% of users worldwide. And in the US, they are the majority.
15:03
So we can't just leave all these people hanging. So let's enter the application cache. I think everyone or most people have heard of it.
15:20
So it's the old and not so fun brother, let's say. But it does work on every browser. So it's the safe bet if you want to have your app working offline. So for those that don't know the application cache, you basically declare a manifest file.
15:42
And you name all the requests and assets that you want to have cached. So after you access it once, it's going to be on your device saved. You also have to name all the requests and assets that you want to go straight to the network. So the difference between application cache
16:01
and service worker is the service worker is way more flexible since this allows us to decide what to do on each request. Application cache you just have or the cache or the network. You can do both. And yes, we have an add-on. The Broccoli manifest add-on, what it does, you install it.
16:21
And by default, it will generate a manifest that caches all your assets. So at least your HTML, CSS, images are going to be on the cache. But you can also add more functionality to it. You can say which files you don't want to have on the cache, which files are not on your assets and you do want to have on the cache.
16:41
So with this, we have our app working offline on most devices. But we still need to decide what to do with users that want to create something. So for instance, in my Trello case, if I want to create a card and I don't have a connection, I can't now. Because the way the web works, it
17:01
will actually go to the server. Well, we have solutions for this too. We can use the local storage. This is basically a key value store on the browser. It saves just string, so it's not recommended for large sets of data. It's more for preferences. But we also have Web SQL and IndexedDB and local for us.
17:25
That was fast. So Web SQL and IndexedDB are allowed to save more data on the browser. And local for us is a library from Mozilla that wraps all three. So in case your browser doesn't support IndexedDB, it will save your information to local storage.
17:48
And yes, we have items for it. So as the name says, Embell local storage adapter
18:01
is a number data adapter for local storage. So you just add it to your app. You choose which models are going to be saved with this adapter. And the information is going to be saved on the browser. So you don't need a connection for this. Local for us does something similar, except it's using local for us instead of local storage.
18:23
So up to this point, we have a way for users to create a card and save it on the device even if there's no connection. But you need to decide what to do afterwards. When the user is back online, how do you send this information to the server? With these two solutions, we need to implement that other part.
18:43
With Ember Pouch, on the other hand, Ember Pouch is also an Ember data adapter. It uses PouchDB that is also a wrapper for IndexedDB. The good thing is that if you have CouchDB on your server, that's an OSQL database, the thinking is provided for you.
19:01
So you don't need to implement everything. There's already a thinking solution in place. So up to here, we can have our app looking better without much effort. We can improve the experience when it installs on the device. And we can have our app working offline.
19:24
So we already improved the experience of our users a lot. But we still have to do something about the performance. So first, let's compare how our apps behave. Here on the left, I have native Trello.
19:40
And I have my progressive Trello on the right. So both load kind of instantly, and we see something on most cases. But native still shows my content way faster. So we do have ways to optimize it a little bit.
20:04
So the first thing we need to wonder is how does our page render fast on the first render. So before I save it on my device, since we are using Ember, the user is not going to see anything until Ember loads and actually
20:23
renders your site. But there's another way to change this. So for instance, with Ember Cliff fastwood, we can have our app render on the server side. And even if the user doesn't have JavaScript enabled, or even if the JavaScript takes too long to load,
20:43
it's going to see something because we are giving the HTML for the first screen to the device. You just have to install it. It's fairly easy. But you might have to start optimizing some other things. Since you are rendering HTML, you
21:01
have to wonder about the CSS and the images. But it's a way to improve the first render. For a second page render, actually, what we have done to this point does help because we already have our assets saved on the device. It won't take that long to go back to the network
21:22
and download everything again. So it should boot faster the second time. And the time to interaction, as well we have already heard, Ember is a large framework. And your user is not going to be
21:41
able to use the app until all the JavaScript downloads and gets parsed. So we have to figure out ways to reduce the size of the JavaScript. And one way to do it is using Ember engines. So Ember engines is not only meant to reduce the size of the JavaScript for mobile devices.
22:02
Basically, it allows you to compose your app in smaller parts. And with lazy loading, you can ensure that your system doesn't download the whole JavaScript. It downloads just what it's accessing at the time. And once you navigate to another route, it will download the JS for that route if it's in another app.
22:22
So with this, we can make sure that our app, if it's too large, it gets cut in smaller pieces. And the JavaScript size is going to be reduced. We do have some tools to help us in developing progressive web apps. And one that is very good is Lighthouse.
22:42
This is a Chrome extension. Here is how it works. You give it your page, and it will do a set of tests and give you a report. So this is the report I got before I added any of the solutions that I just mentioned,
23:02
before having the manifest, before having the service worker. So my app is not very progressive. Basically, it doesn't work offline. It loads too slow. There's more information, but it also doesn't give you an icon when you save it to the home screen.
23:24
After I add the web app manifest and the service worker and the app cache, if I run Lighthouse again, I already see some improvement here. So my app works offline, and you can save it on the device. And it gives you an icon, but you see the big red there
23:42
that says page load is not fast enough. And I said that we could improve this with fast boot. So let's check if we actually do see some improvement here. And yes, we do. We went from a service 77 to a 90.
24:01
So the first meaningful paint gets green now. It's faster because we are giving HTML. But we still have a time to interactive that is not so green. Let's see what happened with engines. The bad news, at least my experience trying it, is that engines with lazy loading and fast boots
24:23
don't work together right now. So the advantage of adding engines for this case, that was the lazy loading, cannot be used here. Up to this point, people are working on it. So here is what happens if I just
24:40
have engines with lazy loading, but I don't have fast boot. So even though I still get a good experience, the first meaningful paint is not so good. So in this case, it might be better to just have fast boot. So going back to the initial dream of not seeing some library site ask
25:02
me to download their app, I think it's possible to improve the experience of mobile users. I'm not saying that we shouldn't do any app. I'm just saying that we don't need to do an app for everything. And even if you have an app, you still can improve your experience.
25:22
Like the first, add-ons are fairly easy to add, and they give a better experience for the web. It's possible to do it with Ember today. We do have some solutions, and the people is working on improving them. And it can get better. So as I was saying, fast boot and engines still
25:42
need some work together. And there's also a lot of stuff that we can do to improve this. And as I showed, most of the job here has been done by the community. So anyone can help. Even if it's just using this technology, so we make sure all browsers feel like they have to support it. So we need your help for this.
26:01
Thank you.