End to End Apps with Polymer (Polymer Summit 2017)

Key Takeaways

[Music] all right my name is Kevin I'm a developer on the core polymer library and today we're going to talk about apps so as you probably all know by now web components are great for building highly reusable user interface components like the ones on the screen here and that's not really surprising because that's kind of a core use case that web components the specs were designed to try and solve but on the polymer team we've also shown that web components are great for building applications as well and in a lot of cases can be the only component model that you need to build an application however that's not to say that web components are all that you need to build really robust awesome apps using the platform and we get a lot of questions on the team about what that actually looks like what's the end end experience look like building applications with polymer and web components so that's why I'm going to focus on today so imagine this scenario right some Monday morning you're sitting in your office minding your own business your boss comes barging in a boss kind of a jerky boss maybe like Matt he comes running any like hey I know I've got a great idea I know how we're all going to get rich I need you to build us a real estate listing app okay now stay with me it's going to be awesome it's going to have a really slick cool user interface really modern users can search for whatever they want is going to come up in a nice list you'll have sorting and filtering in the list you can switch a map view with pins flying around showing you where all the houses that meet your criteria or you can go to detail view maybe a mortgage calculator up in the up in the corner all that data is going to be pulled out of a server and kept in sync as it's changing the users can log in bookmark their favorite homes of course we're going to have a responsive layout so that there's one app works on all the different form factors we need to target it's got a load superfast on 3G it's got to have amazing SEO you know so users can find all these houses using our site of course it's got to be accessible and international to reach the most number of users we can and you have two weeks to get it done right so this is the question do you feel like you have all of the tools and patterns that you need to get up and started quickly to build out features quickly and iteratively to deliver a great user experience with maintainable code that's going to scale well into the future because that jerky boss is probably going to want to want you to keep adding features after you get this this first proof of concept done so if we walk through this scenario from start to finish there's actually a lot of things that we as web developers kind of have to learn and master and know where to start right so we need to make sure that we we know how we're going to structure our application to deliver great performance to our users we want to scaffold out our app from a good starting point so we don't have to reinvent the wheel with every app that we're doing we want to make sure we're following good patterns for factoring the UI so it's maintainable and reusable we want to make sure it's internationalized and accessible we want to make sure that we're following good layout patterns for responsive layout we want to make sure that we have really solid and repeatable patterns for managing state in our application and making sure the application is easy to reason about we want good developer workflows for serving and debugging and linting and testing during development we want to optimize our build for deployment we want to make sure that we're efficiently serving the application for deployment it's a ton of stuff that we have to master to get an awesome user experience out and it can get kind of blurry right trying to figure out where where to start but the good news is there's help so the polymer app toolbox we launched at i/o last year actually provides answers for a lot of these these topics so the polymer CLI the anit command there will scaffold out our application from a good good template a good starting point we have the app localized behavior which helps us format strings in our polymer templates and browsers actually now have good cross-platform support for formatting numbers and dates to the internationalization API the paper elements that are elements team produces have always had a really strong focus on accessibility our app layout elements provide components for common layout idioms responsive layout idioms the serve command in the CLI gives us a nice development server to use while we're developing chrome dev tools actually has built-in support for web components which is really awesome shadow Dom a custom element and we're committed to helping the the chrome team improve the development experience using web components polymer lint provides a static analysis during development web component tester gives us a framework for continuous integration and the polymer build gives us you know performs a lot of the common optimizations that we need for unification translation that sort of thing but as you can see there are a few places of the story that you know if I actually sat down and built this application that I talked about for this for this talk and there are a few places of the story that I realized that we probably deserve a little more focus than we've given them in the past so these are what I'm going to talk about today talking about how we're going to structure the application to hit the best performance how we're going to factor the UI we're going to manage state in application a complex application like this and how we're going to serve it for deployment so there's a reason that I put performance first on this list and that's because like the number one way you can make sure that your application performance is going to be horrible used to think about it at the very end of the app development get it all done and then go home I wonder how fast this thing loads right so you owe it to your users to make performance the number one concern for how you're structuring your application and a lot of the front-end web development world is enamored with this concept of server-side renderings as a means to good performance where they'll send down server rendered static HTML first to get something painted to the screen while we're waiting on the rest of the JavaScript to load but when you think about it unless your application is just a kind of a shell around passive static content what the user actually wants to do is interact with your application right they want to select a departure date or sign up for a newsletter or buy a product or bookmark a house in our real estate application and server-side rendering really helps with none of this it just gives them something to look at until the code loads so they can actually do what it is they came to your app to do so if you still have to send a huge bundle of JavaScript down to your users to transform that initial rendering into an interactive application your users are still going to hate you and if you don't believe me what I'm going to up here are two actual real-life server-side rendered applications so I give this going so as you can see they actually render to the screen really fast and they give you this impression that you can start using the application it's there I've got this throttle down to 3G so this is running in chrome dev tools on kind of mobile mobile type settings and as you can see it results in this horrible inter experience for the user they have to sit there wondering when the thing is actually going to become interactive and this is not to say that server-side rendering is wrong or bad a bad technique to have in your arsenal for good performance in fact tracer guard is here to give a talk tomorrow about some really awesome work he's been doing on being able to server-side web components on the server but rather it just says that there's just really no shortcuts to delivering a good user experience we just have to be focusing on the right metrics and for a lot of applications the right metrics is probably not the time to first paint but the time to interactive the time until the user can actually do something on your site and the best way to ensure a good time to interactive is this don't make the user wait for anything they didn't ask for so that means only send down with the route requires in a few round trips as possible sending as little duplicate information as possible between routes right and that sounds easy enough but historically it's been you know fairly difficult to achieve and this is why on the polymer team we've been working really hard to kind of promote and get people thinking about the purple purple pattern and this gives us a straightforward pattern for for factoring applications for optimal delivery so in short we'd start by factoring our application around decoupled routes that can all fit back together into an interactive experience and then we're going to push down only the code that's needed for the initial route with as few round trips as possible so only what the user asked for in their first URL that's the only thing we should be burdening them with first right and then from there we're going to render and get that initial route interactive as quickly as possible and then while the user is enjoying the route that they asked for we can the super Worker cream boot-up and in the background we can be pre-caching the rest of the application so the code needed for all the other routes in the background so that when the user is ready to move on to other parts of the application we can then lazily import the code that's needed for the remaining routes right out of the cache and get those rendered quickly as well so we summarized this as purple push render pre cache and lazy load lazy import and it gives us a nice pattern to ensure that we're giving the user exactly what they want and no more all right but that's not good enough just to follow the pattern we actually have to be measuring we have to measure the metric that makes sense for app and we recommend using webpagetest for this so they've recently added an easy mode so you can just go to webpagetest.org slash easy and it'll open up the site pre-configured for testing on mobile devices so you just want to check the lighthouse checkbox there drop in your URL hit start test and then it will run a performance test of your of your application using real mobile devices and real real throttled networks once it's done testing you'll get a result page something like this if you click into the lighthouse score you can scroll down just a little bit and in there will be the time to interactive so this is the you know a really good metric to be focusing on when you're building your app to judge how good your experience is going to be and then to ensure a good experience we recommend you know setting a budget for yourself and we like to target around three and a half seconds on these mobile 3G networks and on these settings the first bite from the server actually doesn't get down to the client until two seconds that's because SSL negotiation requires a lot of round trips to the to the server so that eats up a huge amount of your budget right so that only leaves you a second and a half to get something interactive you know the thing that the user wanted to do on your app get that interactive on the screen and we we found that this one and a half seconds a budget if that's what we're budgeting translates into about 50 kilobytes of code all right that doesn't sound like a ton but with new polymer 2.0 that starts at around 12 K so that leaves you about 40 K left for your budget as you heard in our last talk we're doing a lot of work coming up in the future to make sure our element sets are highly optimized so that they can help you fit into the end of this budget and we found that the best way anytime we're putting a recommendation out we want people to file is to give it a name right because names are powerful as soon as you have a name you can talk about it with other developers and that sort of thing so we're calling this one purple 50 all right so this means apply the purple pattern and budget yourself to 50 kilobytes that's a good rule of thumb to ensure that you're hitting good performance okay so let's see what applying the purple 50 pattern looks like in our real estate app here so we're gonna start with an application shell that's responsible for handling the route on the client loading the top-level components for the route and then we'll think about breaking the application down into meaningful routes so for this application we might have a home route and in explore route and a detailed route so we'll start with those features and then we can add more later on as the bus comes in and asus2 and then for each of those rats we're going to build a custom element that encapsulates the view needed for each of those routes right so here we'd have a home page is for page detail use something like that and then following the purple 50 pattern we're just going to try and keep an eye out on the code that we're putting into each route and try and stay within our 50 kilobyte budget so this is the general idea how we're going to approach you know meeting all of our performance requirements and ensuring we have a good good structure for the app okay so we've got the structure down now let's move into how we're going to start building out our user user interface so this is usually about taking UI mocks that you know designer - ketchup and then factoring those drawing boxes around them breaking them down into individual components some of those we can get off the shelf and others are going to be our application specific components and then we use composition to build those all back up into our final application so we're going to want to leverage reusable components wherever possible right because the best line of code is the one that you didn't have to write right and just like NPM is kind of our go-to source for JavaScript libraries web components that org is our go-to source for a reusable web components so we can go there and see what in the catalog might fit our needs and any given application where we're trying to build so for a lot of our app UI we can just stand on the shoulders of others in the community and not really in them reinvent the wheel where we don't have to so if we look at our mocks we can get elements out of the catalogue maybe tabs for the navigation here maybe some icon icon buttons even the Google map right there are components for things like maps in the in the catalog as well but again using custom elements for a reasonable or using custom elements are not just for our useable components we can use those to build our applications specific components - and this has a lot of benefits over using a non-standard component model some other library - to do your application so among these so we can achieve a smaller payload because we're using the component model that's built into the browser we don't have to download code to get that whenever we're scaling an app to a large team and capsulation is really important to help with that coordination problem when developers aren't all working really closely together and we get encapsulation for free with web components built into the browser like I mentioned before chrome has really awesome dev tools support for custom elements and shadow DOM and most importantly our components aren't locked in to any given framework silo I want to pause here because that's a really important point I don't just mean that you're just locked into a different silo that's not the point right the point is that as long as you're using custom elements as your component model and properties and events as your as your interface for the component and shadow Dom to encapsulate the rendering really how you transform the inputs to the component into whatever the component does is purely an implementation detail of the component we have a really nice abstraction between the interface and the actual implementation so we can actually extend from whatever base class we want without losing interoperability with other elements in our in our application so if we were building an application we could build the whole thing by extending polymer element our base class that we showed with polymer 2.0 but that's just one choice down the line we could switch some of our components over to using the simple element base class that Steve just talked about building and those can totally work side by side in your application with polymer elements we could try sketches trays here and we you might sell you on sketch ASU could try that out in your application without switching the whole application over and someone is bound to make some new better web component based class in the future that we all might want to shift over to and we can do that incrementally over time without throwing our application away each time right so think about that if you wanted to change from popular framework one to popular framework two today that's a total rewrite you throw out your application when we start building our applications out of web components it gives us this ability to incremental change over time without without having to throw everything away and without losing kind of the ability to innovate okay so back to our real estate app right so let's take a look at how we'd factor our application views down into components so let's just focus on this this one route this explore page element and then we can use reusable elements front from the catalog so the Google map and the paper icon button we can even use native selects here sound a little especially right and then we might want to factor some of some of the rest of the view down into other application specific components that we're just going to compose together so we're just going to keep kind of breaking down and composing back up until we've got the final view for our route and then at the top level of our application will be our App shells and this component is responsible for the top level layout of the application so the real estate app is our app shell inside of there we might have app tool bar paper tabs so it's doing the layout and the navigational components and then the apps all is also going to have the code for the router and then the knowledge of how to lazily import the components needed needed for each route so if I go to the explore route the app shell will be responsible for loading that explore route element or Explorer page element and getting it rendered and interactive user changes to a detail route later it would load and and get that element rendered so to get started with an app shell template kind of set up for this this sort of factoring you can check out the polymer starter kit template in the CLI to get to get going test ok so we talked about structure for performance factoring the UI next we need to bring our application to life by loading it with data and managing state changes in the application so application state management is kind of one of these areas that the web platform has really had the least to say about and so it's an area that we get a lot of questions about it's probably our biggest area of confusion and questions and that sort of thing and in request for guidance so two years ago at the first Palmer Simon and Esther name I gave a talk called thinking in polymer and it put forth the concept of a mediator pattern for how we think about composing and coordinating state changes between components so just a really quick recap and short a mediator owns a scope of other components so it owns them and it's responsible for propagating data down to the components listening for events from the components to handle user interactions that sort of thing and then based on those events perhaps mutating some data and propagating that those changes back down to the components add ons as well as up and out via events so the mediator pattern is really useful for creating reusable standalone components that can handle their own complex state changes internally while still communicating then changes up and out and that's because it encapsulates the statements management so it's portable so these are the kind of things you're going to find in web components org things that you get off the shelf you don't have to they don't have to tell you how to do your state management it kind of comes along with it and using this pattern we've shown that you can actually just kind of keep composing mediators into mediators and as you keep building that up you end up with a final top-level mediator that's mediating other components and you can build your application out of that so it's kind of the turtles all the way down mediator concept however the community has also shown that there can be benefits having less granular and even global mediators of state so there's kind of a trade-off space in a spectrum here and particularly as components become more and more app specific and are largely used to compose kind of more generic components together with application specific logic having one mediator for all application data can can make the application more easy to reason about and it opens up nice developer workflows that we'll see in a minute so these global mediator patterns is so flux is one really popular example popular in the react community they kind of formalize this concept of having one central place to put all the application state that flows down to components and one place to dispatch events that cause application data to be mutated and passed down and so we can just think about you know these kind of global mediator patterns as the mediator buys innocence or the media varnish is set at a global level right now there are lots of choices out there to implement the global mediator pattern kind of too many to go to in this talk but a lot of times developers just come to us and say just tell me wanted to use just tell me anything you know is good and I'll do it and if you're if you're looking for that kind of answer we actually think Redux is a really good choice it mates really well to web components and we know that people have had success for it so it's Redux is really simple it really has very little magic in it it implements a really simple mediator pattern and there's a really strong ecosystem that Redux has built the library actually starts really simple very easy to understand concepts and as the needs of your application become more complex there tend to be ecosystem based answers to handle that complexity so a lot of times you take the form of you know kind of add-ons that help you manage async flows of data in and out of the server for example or kind of complex flows through the application of that the user is going to take that sort of thing okay so let's just take a look at what applying Redux to this application would look like so first let's introduce some terms so in redux the global mediator they call that the store and so for passing data down kind of into the application from the store there's a subscribe callback that elements can can call to be notified of any changes to state kind of the global state in the store and then actions can be dispatched it kind of in place of events actions are dispatched to the store to tell the store to kind of change the current state of application and those are done using what they call reducers so these are functions that we write and give to the store that tell how to change the state based on actions that happen so like I mentioned there's a bit of a trade-off going from localized state management where it's all self-contained to global state management where you put it all in one spot but one of the key benefits is that it opens up really nice developer workflows like the dev tools that ship in redux so this is a screenshot of the dev tools that you can install into into chrome and they just sit there in your in your dev tools and we can on the next screen I'll show what this looks like but it basically because we're centralizing where all the actions that can possibly mutate the state go it's able to log everything that's happening in the app that led to a state change and then because all the state is sitting in one spot as well it lets us see all of the states altogether so that kind of helps helps make it a lot easier to reason about as you're building an application so here's an example kind of using the application in the dev tools and as you can see for every user interaction that happens in application in the action log there we get an action that's logged so we can kind of have a log of every event that's leading to a state change and actually see the state change changing over time in the application so for each user user action get action state changes and then what's really neat is it introduces this concept of time shop time travel debugging which you might have heard about so to let it lets you scroll back up into the action log and because the dev tools are snapshotting that global state objects at every action you can actually play back you can go back in time kind of look for for example if you had a bug like maybe this little pop-up got screwed up there I can actually jump back in time find the action that caused the state to do change in a way that caused a bug and makes it a lot easier to kind of debug your app and find find what's going on okay so there are lots of ways to connect custom elements to redux and it's fairly simple to do so so I'm just going to show one way there's lots lots to do it but one way is to build your your elements as generic views that just accept properties and fire changes out and don't mutate any state themselves and then what you can do is then subclass that element so that the the generic element you could use in in you know any application in your lineup that sort of thing but then you can subclass it and connect it to the store of a given application and then in the subclass to connect it to the store we would just have the have the element called the SUBSCRIBE callback - Redux to get the in any state changes and set those into properties and then we can add event listeners just normal Dom event listeners that listen for events and dispatch actions to the story that are going to change the data and one other kind of pro tip i want to point out is that if you're if you're kind of moving and looking into global state management techniques most of them you know don't come out of the box with a way to kind of separate all of the state management code they kind of lead you towards having a big blob of all of your application its global state management so you put it all in one spot and this kind of runs afoul of our --purple --purple concept right we only want to load the code that the user actually needs for the route that they edit so that's something we want to pay attention to that well we'll see here so just very briefly so pretend that explore page is the element that we created the view just takes properties in and events out and we're going to subclass it in the constructor we're going to call Redux to the SUBSCRIBE method we get a new state object and then we simply dereference any state that's needed in this particular component out of the store and set those into properties and here I'm using polymer 2.0 to set properties API which allows us to set a batch of property so an element once really efficiently and then on the other side we want to dispatch actions and event listeners so for any events that happen that should call it state to change we just add an event listener and then call Redux is dispatch method to send an action to the store and here I'm using what Redux calls action creators which are just functions that we write that take up parameters and return an action object so I'm creating an action and dispatching it to the store based on the event so we're going to do that for any events that our application fires that needs to mutate state and then last we want to make sure that we're lazily loading any of the state management code along with our element and not putting it kind of centrally in the application and the way I've done this here is Redux has a lot of extensibility hooks so I wrote a very simple enhancement to Redux that allows me to add an API to the store to lazily install the reducers the things that kind of manage state changes into the store as more and more elements to mend they're lazily adding the state management code to the application so here the listings reducer is responsible for handling any changes to the listings I load that along with this component which again via the purple pattern is being lazily loaded just for that route and installed into the the store and then likewise any action creators in any kind of action based logic you want to make sure that you're importing that along with the component as well so we will continue experimenting with patterns for state management and how they can fit into web component based apps and I wanted to also call out a community library called polymer Redux which takes the declarative approach to binding polymer elements to redux so that's something you can also check out and like I said before there's a ton of innovation happening in the community and redux just one of those most of those can also be happily paired with with web components so we explore it encourage you to share ideas share how you're building applications share them with us share them with other people at the at the conference today alright so we're done managing state finally we have to actually serve our application to our users so we'll need to host and serve it to to our clients and although a lot can be accomplished by statically serving our client application we feel that there are a few kind of key minimal features that are required to be implemented on your server to actually get the best user experience so these include serving the app shell for all routes so based on any route in your application making sure that you're serving the app shell which has been responsible for lazily loading the components you need using HTTP to push when possible to reduce round trips and to serve granular components when that makes sense to improve the efficiency of your caching and when HTTP to is not possible then alternatively serving bundled assets but that are bundled per route we want to make sure that we're sending the optimal code down for the capabilities of the browser so for browsers that implement es6 for example we might want to take advantage of native custom element sub classing by sending non-trans file code for example and then finally we want to make sure that we're serving SEO compatible output for for any BOTS that might visit our site so we've been doing a lot of work on a reference server that does all of these good things that were calling --purple --purple server node and that's designed to work hand-in-hand with the outputs that come out of the polymer build system so it's a node based server that's set up for client-side routing and then it has a lot of extra features to do these kind of smart things when I was doing to run through a couple days ago Chris awesome developer on our team was like you're kind of short selling purple server node by using that kind of lame database clipart there can't you jazz it up a little bit because the server is actually pretty awesome so I put some sparkles on there if that made Chris happy but basically it has some presets in there that allow us to that that can automatically detect the capabilities of the browser and serve the optimal code for each so for browsers that have es6 for example it can serve raw es6 code so that we can take advantage of the native es6 subclassing of custom elements in the browser it can also differ and then for browsers that don't have es6 we can serve the trans pilot code as well it can also differentiate between browsers that have pushed so we can serve a granular component to reduce round trips impossible and serve bundles for non pushed compatible browsers and then it will kind of do the permutation of things and serve the right you know set for the capabilities of the browser and then last kind of under this heading or calling BOTS so these are things like Google being search crawlers that sort of thing as well as social snippet generators that kind of create the cards that show up in social networks we're actually integrating purple server node with another project that we're working on on the polymer team aimed at tackling this SEO problem with with web components and that will actually serve rendered HTML fully rendered HTML that's compatible with SEO and social snippet generators and I'm just going to tease that today because we have a whole talk on that tomorrow do you guys should stick around for and check out all right so you can check out the beta of purple server node here give us feedback so this is kind of set up for you to deploy onto a hosting site like App Engine something like that sit behind a CDN and get really good serving efficiency okay so with purple node server we kind of fill in the last big gap in our story about how we're actually going to deliver these awesome experiences using the platform and hopefully you feel more confident now that you have all the tools you need to build robust real world apps like this real estate app right and at the beginning I said that we had like two weeks that was our setup we had two weeks to build this so to be honest I didn't have a whole lot of time I to kind of put this talk together but I really wanted to build an app and actually was able to build this out in two days you know this much it's a proof of concept I still need to do a little more work to get the demo ready but of that two days like a full half of it like a whole day was just generating a bunch of fake real estate JSON so that I didn't get sued by people by showing their house in my my talk so hopefully you know from this proof-of-concept I mean I feel that I'm way more confident now that I've got a really well factored UI with components I can reuse across other applications I've got easy to debug state management that'll scale well to adding more routes adding more features I know I'm going to be set up well for performance I've got a I've got a structure that scales well for performance with the purple 50 pattern and I've got a great serving environment with purple server nodes so hopefully you feel like you can be this productive with the web platform too so we're going to continue working to take all of these kind of best practices that we come across as we kind of tackle more and more challenges on the web platform and provide guidance and provide features and provide products to help help move this along thank you very much [Applause] [Music] you [Music]