EmberConf 2018: Opening Keynote by Yehuda Katz by Tom Dale

[Music] yes welcome to ember top 20 team this is our fifth anniversary and we could not be more excited to be here with all of you today we have a lot to cover so let's just dive right into it I'm very happy to announce that Melanie Sumner is joining the core team melanie has done great work modernizing the amber website to make it more accessible and generally making accessibility of fun ants and our concern across the entire project as a JP Morgan Chase employee JP Morgan Chase she has also served as a tireless representative of the many Android developers working inside of large enterprises and so I'm very excited to have her join the team anniversary of ember Cawthon there is an ember camp before that but ember itself is seven years old in April and we've always described ember as being a framework for creating ambitious web applications it's even the first thing you see on our home page but there's maybe an even better way to say it I think for me ember is really for ambitious developers ember is not really the code which has changed radically over the last seven years instead I think the defining feature of ember has always been our community if you're an ember developer it's because you value productivity over endless tinkering you value shipping features over rewrites and you believe that we can solve problems better by solving them together as a group because your app is not a special snowflake and you also know the value of our community moving together as one to us those ideas seem like common sense we've always thought that they were they we always thought of them but they run counter to a lot of the conventional wisdom of what the JavaScript community thinks today over embers seven years our community has come together to build a cohesive set of tools that are designed to last there's nothing else like it in JavaScript honestly and one of the benefits of being an ember user is feeling confident that even as the web changes your tools are kept up-to-date and tested to work together and it goes beyond the framework itself we have this huge ecosystem of add-ons that extend Ember while preserving that same belief in stability and productivity so the truth is that we really love Ember we're proud of ember and so when it came time to think about what our focus should be for the future it was obvious we don't want to change - we just want to build a better ember so that's what the focus of the 3.0 series is going to be together we're going to build a better ember fundamentally there are three broad themes that we've heard people say they want us to focus on including most recently in the survey that you should check out so the three themes are first of all we want to reduce the number of concepts that people have to learn to start feeling productive in ember second of all we want to take advantage of new features in JavaScript as they start to land in browsers and third we want to give people tools to be even more successful our API should help people fall into the pit of success but we can't do it ourselves if we want to make this happen we really need to rally everybody energy of everybody in this room the whole community to make this work so today I want to share with you our vision for what using ember in 2019 could be like by knowing where we want to go together we can figure out the best way to get there so the first thing that we want to see is clear more conventional file system layout that replaces both the default file system layout and what a lot of people are using the experimental pods layout as a community that prides itself on conventions and shared solutions it's time to roll the learnings from the pods experiment into the default ember experience in the current default file system layout components in their corresponding templates live in two different directories as you know the process of switching from one to the other in your editor can be tedious and error-prone and as your app gets even bigger this can lead to a lot of annoying scrolling just to switch from a component class to its template so in the new layout heavily inspired by pods we want to keep related files next to each other not only does this make switching back and forth easier it makes the structure of the entire application clearer and best of all thanks to ember strong conventions we could build tools to painlessly migrate existing apps to the modernized layout I really really love code mods and I love that both the JavaScript immunity and the ember community has gotten gotten interested in them so speaking of modernization let's talk about jQuery mber 1.0 supported IE 7 and actually the test suite passed in 96 to on accident and and those were popular browsers at the time in that era we needed to work around the large number of cross browser quirks and jquery was the best tool to do that however more and more people are building ember apps that are using just the native Dom API for example this component doesn't use jQuery at all and instead it uses the native query selector method to first find child iframe element and then use the post message API to send a message to it and in fact ever since we moved to the glimmer vm rendering engine ember itself has it used jQuery at all in the view layer and we're big fans of jQuery we think it's the right choice for many apps but at the same time we want to be as approachable to new developers as possible and we really don't want people to think that they have to learn jQuery just to be able to use Ember and it may surprise you to learn that jQuery is one of the largest contributors to embers default file size so jQuery is over 30 K but it's over 30 K even after minification and gzip so if we could make jQuery optional the out-of-the-box file size of an ember app would drop by 1/5 so testing to write software that last you have to have tests that give you the confidence to make changes Ember every new ember app comes with integrated end-to-end testing infrastructure and our community has a fantastic testing culture I really love testing a number it's really great but we can make tests even better by taking advantage of new JavaScript features like async functions and we can make it even easier for people who want to use testing libraries like just Rimowa instead of queue unit the first thing we can do is actually relate it to jQuery in my own app we don't use jQuery that much in our components but I still very common in our tests and this is true about a lot of apps that I've seen it would take in many cases more time to migrate test to stop using jQuery than app code so step one is to transform all the places that we use jQuery and our tests to use new helpers that use native Dom api's and step two is cleaning up our tests to use async functions often in tests you want to write code that relies on asynchronous tasks finishing and this code can be difficult to read and write in JavaScript so our existing test helpers are asynchronous by default and we introduced the and then helper to wait for asynchronous code to finish before moving on to the next part of the test however now that JavaScript has async functions we have a built-in way to tell a function to pause until if some asynchronous task has finished so if we make all of our test helpers use return promises they would work seamlessly with async functions so in this example we turned the tests on top into an async function and because the test helpers in this example return promises we can use a weight to wait for rendering to finish before continuing with the test and that means that we handle asynchrony the same in our tests and in our application and best of all I love code mods we can help the community move to this better way of doing things by using a code mod which can update a lot of tests automatically to use async functions and migrate tests using jQuery to the new testing helpers and and finally in the testing topic while we're on testing topic although we personally are big fans of qunit ember is a big tent and we want to work with whatever testing frameworks people prefer and so by simplifying the API we can make integration with other testing frameworks like mocha and more reliable and first-class so ember was an early adopter of JavaScript modules in fact Yehuda helped to drive their design through T's 39 and ember CLI has used the module syntax since before ember CLI 1.0 so this is what a typical file looks like in an ember 2 app each file is a module and then ember itself is exposed as this single module with everything on it and this works but the beauty of JavaScript modules is that they let you import just the things that you actually need in that one file and we want ember users to be able to import just the parts of the framework they need so in this small example it maybe doesn't seem like much of a difference to use a JavaScript module API but in more complicated files the monolithic global hides the fact that ember is made up of a bunch of different bunch of separated packages under the foot so this leads people to feel like ember is overwhelming to learn it's doing too much and your API is how people think about your library so this overwhelming API leads to documentation that has also felt overwhelming so even though you only in practice need a handful of concepts day-to-day to write an ember app this overwhelming list was the first people it was the first thing people would see when they went to get help so this is typical reaction to the API Docs one of the best benefits in my opinion of JavaScript modules is that it allows you to orient your API documentation around these different packages that we're already using internally and they're naturally grouped by functionality this makes finding documentation easier as well as giving people a much better intuition about what your framework actually does so we can replace this big old list of classes with these does that tell you exactly what they do now you might imagine that going through every file in your app and refactoring it to use the module API would be tedious and time-consuming and I agree so you had to do it by hand you would be right but again the best part about this feature might be that we can fully automate this process in fact going forward any time ember changes something that requires these kind of sweeping changes we should really create a codemod to help you migrate in addition to the learning benefits modules also unlock the ability to produce better optimized apps we can detect when you use debugging utilities and we can strip them automatically from production builds and we can also use tree-shaking analyze the module graph and include just the parts of the framework that you actually use in the compiled output one thing that we really want to see in next year is great integration with editors getting feedback as you type reinforces good patterns and makes learning faster for example if you moved your app to the new J's module API that we just talked about it would be easy to fall back into old habits and use the old API but if we offer great editor integration out-of-the-box we can catch this right away and give you a warning right there in your editor and we can also take advantage of the fact that handlebars is a first-class programming language and build first-class tools on top of it for in this example our editor is able to automatically discover and suggest the name of the component as I'm typing it because it understands embers file system layout ember is made up of many individual packages but pulling all these pieces into a single integrated editor experience what gives users something even greater than the sum of its parts members object model is the heart of the framework everything else builds on top of this foundation so improvements that we make to the object model oftentimes can unlock many downstream improvements in other API X so let's first look at computed properties which are perhaps the most popular feature in embers object model so es5 added a syntax for computed properties but when ember first came out es5 hard as it may be to believe was not available in many of our supported browsers and if you think about how many computer properties you use in your apps I think you'll agree that it's hard to imagine this not just not having this feature so we had to create our own computed properties using the features that were available to us in es3 that said we noticed that forgetting to use dot get trips up people as they learn ember it feels really frustrating every time you forget until you kind of develop the muscle memory to use it everywhere so what if we could stop requiring the use of dot get this would make ember so much easier to learn for people who already know JavaScript it would also mean that embers computed properties work with a new language syntax like the structuring because they would just be normal JavaScript properties so another feature that exists in JavaScript today that didn't exist when we first started ember is classes es6 added a new class in text of JavaScript this is a simple example of a person class that has a first name and last name property and a method called say hello which is the example as required by law so let's try to take an ember that object subclass and rewrite it using native class syntax so first we're going to move everything in the init method on the left side into the constructor on the right side now classes don't support any s6 classes don't support initializing properties directly so we will need to set the title property inside the constructor on the right side and next we're going to move the dinosaur element method which is a pretty straightforward transplant from the left to the right side and finally we are going to move the tab count computed property but wait wait oh no so so what's the problem here the problem is that at tc39 we intentionally shipped a maximally minimal class syntax in es6 to get started and it's missing important features needed to migrate the Richer Ember class model to standard classes there's no way for us to express things like computed properties directly inside of the class body but good news tc39 did not stop with max-min classes and we have been busy adding important features based on developer feedback so decorators are a proposed new feature that allows developers to implement features like computed properties inside of class bodies and let's take a look at how we would finish this port using decorators so in this example we have a computed decorator and with the computer decorator we can say that this getter is now a computed property and tell ember what its dependant keys are while we're at it let's get rid of the unnecessary get from the tab count implementation and finally now that we have decorators we can move the service declaration from the left side to the right side I think it looks pretty nice so isn't this isn't this slide beautiful I personally been waiting a long time for classes to get to the point where we can put this slide on the screen and I'm happy that tc39 has finally almost gotten all the features together to make this possible [Applause] but decorators aren't the only improvement coming to classes in the previous example we had to move initializing the title property out of this nice declarative syntax on the Emer version into the constructor which is something something that the first iteration classes don't they don't allow you to declare class fields in the body I'm sorry the class body however at tc39 the class fields proposal gives us the ability to declare and initialize properties with a convenient syntax that is quite similar to the Ember syntax and all these features together add up to a really nice experience for ember developers who want to use typescript JavaScript classes if we had them would make it much easier to adopt typescript in your app with class fields we can tell we have now a place where we can tell typescript the names or sorry the types of our current user and tabs properties we think that people in general should be able to get a great ember experience using typescript but as always we will always design the Ember API as JavaScript first and we would never make types of mandatory or make any part of the Ember runtime rely on typescript support and actually a lot of people who like typescript really appreciate that this is that we have this philosophy one of the things I really love about typescript is the detailed autocomplete it brings to your editor especially if I'm writing code that relies on another file it's really helpful to be reminded what properties and methods are available as I type so if I'm writing a method in my component and I need to get some data from another service I don't have to switch file to see what this property is called typescript shows me right there as I type and actually if you're thinking oh I don't use typescript so what do I benefit from this JavaScript users benefit when ember uses type scrim more because editors can use typescript information to provide autocomplete and inline documentation even in JavaScript files that don't use typescript so both demo Papa never go back only forward mm-hm so so that was all the object model components are one of the most fundamental API is in ember so because of how important components are making components better yields a huge payoff so let's continue with the theme of simplifying ember to talk about what people call fragments one property that you're probably used to from ember components is that they add a wrapping Dom element around the component template this element can interfere with CSS rules or just make them more the Dom more complex for a little benefit and one thing that I should mention is that power users were always able to disable this behavior so probably a lot of people in this room know that there's a trick that if you set tag name to empty string it removes the wrapping elements but it really sucks that having having to create an empty component class just to do this and it really breaks the flow of learning Ember at a particularly early point in the process so to make this more discoverable we really want components without a class implementation to not get their template wrapped in an extra Dom element and what this change does is it makes creating reusable snippets of HTML feel incredibly lightweight and it's more intuitive because templates become what you see is what you get in the DOM it's also annoying that you have to create a component class just to customize the wrapping element if I want to replace the default div with a fieldset element for example ember developers have to create a new component class and learn a new JavaScript API for changing the tag name or binding an attribute and this isn't ideal because these are both things that people intuitively already know how to do in a template so with fragment components we can delete this component class and just put the fieldset element in the template where it belongs so we talked about no longer requiring people to type this not get everywhere but you are probably wondering well what about this thought set for Amber to be able to keep the Dom up-to-date for you it has to be able to see when your component changes when you change a property on it and currently we do that by asking you to call this that set but if we had class fields and if we had the track decorator we could tell ember about the property once and then set the property like normal everywhere else so in the class on the right I tell ember that the title property is tracked and then when I am mutate it in the update method I don't do work alling this not set it already knows what to do so how to track properties relate to computed properties you might be thinking well we've just renamed to compute it to tracked and it would behave the same as before and if you've used glimmer j/s you know that this works in fact it's what Limor does the merge is does but what if we could do better than that with tracked properties we could automatically infer its dependencies on other track properties just by you accessing them right there in the function imagine never having to think about writing dependent keys again or keeping them in sync with the implementation this would be this would be such a massive productivity boon and it would eliminate a common source of bugs that bite even me track properties would make auto tracking dependencies like this possible what you get for experimental switch control my joy contents died so that's really awesome I'm really excited about that one issue that people have with the component API is that it's hard to tell whether properties are coming from the component itself or passed into arguments I think everyone in this room has written a lot of components that look like this can you tell by looking at this code whether it's show comments is passed as an argument to the component or whether it's a property on the whether it's meant to be a State on the component well actually neither neither can we the only way to know for sure is to search the code for all the places where the component is used to see if anyone passed in a show show comments argument and I've done that a lot of times so to make things clear what would be better is if components get their arguments off of this that args in JavaScript and by using special syntax at name syntax and their templates so here's the same component updated to be more explicit it's much easier to see that post is an argument while by line and show comments from come from the component and this also bakes in and finalizes the data down actions up pattern right into the API by making the past and data immutable so if we put all these improvements together the code for the component gets much simpler and cleaner here's an example from the app that you build in the getting started tutorial called super rentals so component stay is more obvious because we mark it as tracked component arguments are more obvious because they come from the arts property async code is cleaned up with async functions and we have moved the class name from JavaScript into the template now everything Dom related is in the template where it should be so that was quite a whirlwind tour and each of these features alone might seem small but having used many of them in glimmer they really do add up to something great so this is our vision for mber in 2019 new features that simplify clarify and help you be even more productive but do we really have to wait until next year's ember coffee if you look under your chair you'll see we've printed out it downloaded now I'm just gonna do everything that we just talked about as being our vision for the future of ember is already here everything that you saw is a feature that is already on stable beta or Canaria releases of ember today and many of the people who are here in this room have helped to make that happen so if you are as excited as we are for this vision that we just presented we really need your help to get everything into a stable release if you haven't contributed to ember before now is a great time to start you've you've all already done such amazing work to get us to this point but we have even more that we want to get done our lawyer Robert Jackson insisted that we add this primer the things we were about to show you are not finalized yet so everything here is subject to change so we've already covered a number of features that came from glimmer jeaious and have already landed in ember one thing glimmer jeaious users have told us is that they really love the so called angle bracket syntax people who use this feature in glimmer JS said they were really surprised at how much clearer it made their templates so here's what using a component looks like today in an ember application and here's what the same component looks like using angle bracket syntax for me and for other people who have used Wimmer j/s it really helps to distinguish between control flow structures and components in applications and the icing on the cake is that you can finally use single word component name [Applause] keen observers might have noticed that the accent tax and the component invocation is the same as the absent tax in the templates that we showed before and that is an accident when using angle bracket syntax the names on the outside line up with the names on the inside in other words the app is how you talk about arguments both on the caller side and inside of the components template so since ember 2.3 you have been able to yield components to a components block people have really taken to this feature implementing all kinds of cool patterns once thing that we've seen a lot is to use this feature to basically allow users to pass more than one block into a component and one of the principles of the Ember community is that we make sure that these common patterns that are we make sure that these common patterns are available to everyone not just the power users who figure out the pattern so we're working a way to bake this this pattern right into ember so RFC number 226 introduced the concept of named blocks these allow you to pass in more than one block to a component so in this accordion component for example in addition to passing in an array of items as an argument we are also passing in two named blocks one called header and the other one called details and the best part of this feature is how easy it is to define components that use named blocks if you have written one that uses the current API you know that it really is a power tool so at the top we have our component template that invokes the blocks that were just passed in and in this RFC they are just they're just arguments just like add items is so these two features have not landed in Canary yet but they are already RFC's the name blocks RFC has already been merged and the angle bracket component RC is still active please check it out and help us get it merged so we can start moving it into Canary and there were even more RFC's that I wanted to talk about today but I was told we only had three hours Tom made me add that so overall it really feels like we've found a rhythm for shipping code while keeping the pipeline of ideas full really excited about what we're building together really excited about we're building together so last year speaking of we announced bloomer Jas and we started by taking this small core of functionality that we had extracted from ember and we built out this streamlined tool chain for building lightweight web applications now we already talked about some of the great ergonomic improvements that were inspired by climber Jas that we that are making their way back to ember but of course Limor is also about performance so I spent some of last year using glimmer on an exciting performance related project at LinkedIn you may have read the blog post so the feed you see when you log in is powered by ember but for this experiment we rebuilt this page with initial load time as the only constraint but instead of rebuilding it once we did it twice how crazy is he gonna get a small team of engineers rebuilt the feed in both glimmer Jas and react which we called the two different flavors and we used pre-act because at three kilobytes we considered it to be the gold standard for building lightweight pages and also for how easy it is to hand tune to achieve optimal performance it also helped that we had one of the main theatres react on the team definitely swayed the decision a little bit both flavors rendered their initial HTML on the server server-side rendering and then they would rehydrate the application in the browser now we ran these two flavors in production for a week to see how they compared and to measure how fast the page loaded there were two numbers really that we looked at the first one is first meaningful paint the first was a person you paint and and the second is rehydration time so first meaningful paint measures when the primary content becomes visible and the page is ready to read you can scroll and you can start tapping links and then rehydration is when the JavaScript app has finished loading it's up and running in the browser it reconnects to the Dom and in fact this is when the app is fully interactive including in our case things like the share button and the like button so how did we do well both flavors performed extremely well delivering first meaningful paint in both cases under three seconds and both implementations also finished rehydrating around the same time so both libraries are a great way to build fast lightweight pages for the modern web we were very happy to see glimmer performs so well that it could keep up with libraries like this that are built for speed yeah go to work tom so as tom was working on the application inside of LinkedIn I was helping the cause by optimizing the glimmer VM and there are really a few features that we worked on that contributed to Tom's great results first of all compiling templates into binary data reduces the time spent parsing JavaScript server-side rendering allows users to see meaningful content before the app has finished loading and finally incremental rehydration allows apps to start up without causing jank so first of all we improve performance by compiling our templates into a new binary format gbx not only does this allow us to do more work ahead of time it also allows us to reduce the size of glimmer and speed up the execution of the templates themselves and this feature is already in the glimmer VM and is already available to glimmer j/s users the second contributor to glimmers performance is async rendering which means that the rendering work can be split into chunks and spread out over multiple frames allowing the users to see content more quickly when the device while the device remains responsive this is especially important on mobile devices where the CPU can be overwhelmed by the demands of the modern web I could describe the details of how it works by all you probably you need to see is a comparison of a glimmer app running on a low-end phone one with async rendering and one without we're gonna be here a while it's like many Wikipedia pages is the demo yeah good work async rendering to hit our very ambitious performance goals we assumed that we would need to use server-side rendering now limors vm architecture already decouples the rendering pipeline from the dom so all you who didn't needed to do was reimplementation use the existing nodes instead of creating new ones now there has been some debate in the wider JavaScript community about whether server-side rendering is really worth it so as a result we also ran both of the glimmer and pre-act flavors using server-side rendering and client-side rendering so as you can see we managed to deliver content to the user a full 1.5 seconds earlier when rendering on the server first meaningful paint is measuring when the user can read content click links right it's such a meaningful it's such a me phone mile some of the hit during the load of the page and rehydration is great but if the user has already started scrolling or interacting with the page we can't afford to lock the browser for a few seconds to do the rehydration so what's really cool about how we do rehydration is that the same async rendering engine that you just saw the powers incremental rendering also allows bloomers to perform rehydration without drinking the scroll if the user starts growing on their device now one problem that people have run into is server-side rendering is that small differences between the server and the client can lead to surprising performance problems and it's really impossible to produce identical renders on the server and client due to even small things like small differences in things like internationalization differences across browsers so in our implementation rather than assume that these kind of differences are bugs for app developers to fix we wanted to be able to repair differences between the server and client automatically and I think that was a great improvement of our implementation and not only has this change made it back to glimmer J's it is actually already available in ember canary in fact this year's ember comp scheduling app is an ember app using rehydration so - Emily try it out on your phone and see how fast it feels yeah thank you - 201 created who created this happen you the real MVP see so those are some of the really great performance advancements that we've been working on in glimmer Jas and we're looking forward to bringing them to all Emer developers soon so today we've shared with you just some of the awesome new stuff that's coming to ember we've talked about ergonomics improvements talked about performance improvements I feel a renewed sense of momentum in our community and I have never been more excited to be an ember developer but there is one more thing glimmer is our laboratory for audacious experiments where we can take advantage of the most cutting-edge web technologies the web is always evolving but every once in a while a technology comes along that feels like a sea change and there's something I've been working on for the past few months that I am really excited to talk about with you today if you aren't familiar with what webassembly is it's a way to run code and native speeds and all modern web browsers while JavaScript can sometimes achieve close to native speed with careful attention and hand tuning and believe me I know it is hard for even the best JavaScript programmers to get good performance predictably and we've managed to build a very fast VM using javascript but maintaining good performance in the face of ever changing JavaScript engine optimizations across four different browsers and then some has been extremely challenging so needless to say the promise of webassembly got us very excited but the first question is is it even possible to adopt web assembly assembly in a library architected years ago for javascript so last year as web assembly began shipping in all browsers we got interested in exploring whether we could take advantage of this new capability due to its nature glimmer has always been written in a low-level style the style that we had to do to hand-tuned to make things fast in JavaScript and we looked at it we were excited with how well aligned with web assembly glimmer looked at Glantz so we looked at glimmers architecture and we noticed that the core virtual machine was a hot path that was written in very hand - in JavaScript as a result much of it didn't actually rely much on the features of JavaScript that aren't yet available in web assembly surprisingly so our plan was to migrate some of this internal code to web assembly and after a few months of work we've successfully migrated much of the low-level code and glimmer to web assembly as well as a good number of the op codes in in the VM so so how did it go well as you recall from earlier in the keynote having a path tool and any experiment in ember is priority number one which is why I am happy to report that the Wasden branch of glimmer is up-to-date with master and passing the entire test suite [Applause] so far we have been mostly focused on compatibility so we've been keeping the test suite green as we go also as you know glimmer is the rendering engine for emerges so keeping a green also means it works with ember in fact we were able to get the ember observer app running by just swapping in our branch with no changes in the code and the scheduling app is not only running with rehydration it is also running with webassembly turned on unfortunately we cannot make this the real scheduling app because iOS broke webassembly temporarily due to a specter snafu which will be fixed in the next few months we learned this this week but nevertheless this act does work in all browsers web assembly so to achieve its web assembly is a very cool programming language if you want to call it that we didn't want to sacrifice the productivity of JavaScript and write low-level unmaintainable assembly code and thankfully we're not the only ones who are very excited about web assembly the Russ project it is designed to help you write generally low-level code in a productive high-level way and the Russ project is also very excited about making low-level code accessible to JavaScript developers through the web assembly target so the russ community has built out a lot of infrastructure that is needed to build web assembly applications and in fact we have been building the web assembly branch of glimmer in rust so we wouldn't want to hand tune it yeah [Applause] I don't have time today to get into the code but here's a small example to show you that even though it's producing very low level output the app code itself looks a very high level and unlike JavaScript the high level nature of the code doesn't come at the cost of unpredictable performance what you see is what you get so what is the plan going forward now the Ember apps can run a web assembly the next step is to land a branch behind a feature flag we won't enable it until there are strong performance benefits and we have also verified there are none known issues no unknown issues with browser compatibility and debug ability as you can see we wrote that sentence before we learned that iOS didn't work but we need to make sure that it actually works interestingly you might be asking like what about I 11 which is still supported browser there's actually a wasm to azzam J's back-end that it work exists and works and that we're planning on using to target I 11 so we don't need to wait to drop by 11 to add this support because we've been so focused on maintaining compatibility we're currently doing some things in the code that are preventing us from taking advantage of the performance benefits for example to work with our existing test infrastructure we're currently encoding the webassembly binary as a base 64 string in JavaScript yes the people who laugh realize how bad that is this prevents us from getting an accurate assessment of the performance profile so the next steps are in the coder to clean up the known inefficiencies so we can get a better sense of it the numbers that we got so far are decent but not but nothing to call home for a co home about but it is because of these in efficiencies that we need to clean up so both of us really value the fact that our community is focused on finding ways to take advantage of cutting-edge web technologies but without losing sight of what really matters which is building great apps that our users love over the long haul despite being seven years old ember has never been more technically advanced than it is right now and our community has never been more energized we've already landed so much cool stuff and only a fraction Oh fracture that we've had time to share with you today but we need your help to make sure that ember remains the most productive ways to build for the web so I want to ask really quickly anyone who is in the audience who has participated in a sub team whether it's ember CLI ember data Learning Team could you stand up if you've been part of a strike team that has worked on the keynotes can everyone okay thank you you guys you guys do awesome work I want to say thank you stay standing I want to say thank you to these folks you pour your heart and your soul into building tools for other ambitious developers thank you thank you so much for all of your hard work if you are excited about any of the things that you saw today these are the people to talk to at the conference they would be more than happy to help you get started making your first contribution thank you guys very much so whether this is your fifth ember Kampf or your first you are part of something special this community is special oh my god sorry I was tearing up this community is special we have a really great lineup of talks for you this year but this conference is really about the connections that you make with other people in the community we are very very excited just thinking about all the cool stuff that we're going to build together this year thank you and enjoy the show [Applause] [Music] [Music]

Channel: Ember Videos

Views: 2,141

Keywords: ember, emberjs, ember.js, javascript, tomster

Id: NhtpXs0ZtUc

Length: 43min 56sec (2636 seconds)

Published: Fri Apr 06 2018