 Hello there. So I'm a software engineer at Mendeley and what do we have to do this one last time? Oh yeah, turn it on. That helps. So for a living I work on a desktop app. It's called Mendeley. It's a little bit like iTunes or Evernote, but instead of dealing with music or notes, it deals with research papers. It's a cross-platform app, so we built it for Mac. It runs on Linux and it runs on Windows as well. And it has a lot of things that you traditionally couldn't do very easily on the web. So it has to be offline. We have people who take this app when they're out on field trips in God knows where in Africa and internet connections are not great out there. It has to manage a lot of data and it's also there are some parts of it that are fairly performance sensitive. It's built using traditional desktop-y frameworks, so Qt, Coca, Windows. Of course, we started building it some years ago and the web moved on a long way since then. And if you end up using these technologies and you build an app across three platforms, you effectively end up building a lot of what you would have found in a browser. You end up doing a lot of work that duplicates what you would find in a browser engine anyway. So the question is, now fast forward to 2015, can we build something like this for the web? Well, this app is a fairly big thing, 250,000 lines of code, so it's a bit difficult to go and rewrite it in a few days. So I figured let's try it on a hobby project, something that has some of the same requirements, needs offline, needs to be able to sync with the web, needs to have some performance sensitive parts and so on. So I figured find a problem to solve. I imagine a number of you will have something like this as well. You have everything these days requires an account. At the last collection I have over 200 online services I have an account on. Some of these I could use social logins for but unfortunately a lot of them, internal services and so on I can't. And as Miguel said, you want to get stuff across every platform. So Linux, Windows, iOS, Android and I'm playing around in virtual machines and Chromebooks you name it. And the only platform that's on all of those is the web. So this is not a new thing. There's plenty of tools out there. This is one of my favorites, just not available for my Linux laptop and many of the other browsers I use. So I figured let's take this app and using 2015 technologies, build it for the web. And the first time anyone who's used traditional app frameworks comes to the web, they have all this choice. Do I go for Ember? Do I go for Angular? Do I go for React? One thing we know for sure is that just trying to do it with HTML is going to be rather difficult. So using these frameworks kind of gives us a chance to have a look at what's it like to build an app with Ember, Angular or React and how does that compare to say building it with a traditional framework like Cocoa or Google? Cute. And Ember in particular is modelled off Cocoa so I would have hoped in a way a fairly similar experience. So that was about a year ago since then I've been busy and the question is what have I learned of how it compares after a year? So there's a number of areas of differences but I think what it all boils down to is that the heritage of the two. So the web was started off as a platform for showing documents, then a platform of showing documents and running some scripts and that was good enough that people could build apps with it. But an actual evolution into an app platform is something that's really only happened incredibly recently as in sort of mid-2013. Whereas the app frameworks on the other hand, they've always been about apps and that has a couple of impacts on how you build things. The first is the one I'm going to talk about is essentially how your app is structured and what the fundamental building blocks are. In a document platform you're dealing with things like links, images, etc. fairly small things and you're generating markup for it. So in Ember for example the way essentially you're working is you've got your templating thing which effectively is a markup generator. It generates a string and shoves that into the DOM which when you're busy generating a document is fine. On the other hand in an app framework the fundamental unit block is a bigger thing, a more complicated thing. It's the widget. All the view, they have different terminologies and that has a couple of important concerns. Well that has a couple of important impacts. The first is that the tools you're building on top of, they have that built in concept of the widget, this higher level component. In browsers on the other hand they're still very much dealing with the lower level elements, the divs, the apps and so on. You can get tools like React, the React tools which understand the framework and they will understand the components on top but it's not yet a native thing in browsers. The other thing is when you come to debug everything happens at the widget level whereas in the browsers you can have the framework to build the app but when you come to debug it you're usually still working at the lower level. The second thing and this leads on from Miguel's talk is about control and performance. With documents when you've got limited interactivity generating a markup string, throwing it at some browser engine and ultimately that builds a set of nodes, a set of state, that works fine. Perhaps on the other hand the components you're dealing with are much more complicated. I'll go back into that in a sec. I'll go forward a couple of slides. Just to give you an idea of how complicated these components are, I took a look at how much code there is in typical things that you find on your mobile, your Android device or your iPhone. A text view on Android is over 9,000 lines of code and I was surprised to learn that a text view is actually used as the base class for buttons. If you have a button on screen there's over 9,000 lines of code powering that. So when someone describes something as feeling native, little details, that's a lot of details. A lot of performance optimizations, a lot of tuning going on and inside those 9,000 lines of code something that app frameworks will give us is a lot of control over verifying and get drain control over the painting, the event processing, the layout, the timing, concurrency. If for example we have a viewer that needs to do some expensive computation, maybe for example a PDF viewer, then if it needs to go and do some work in a background thread it can do that without the rest of the application having to care. And you have all this complexity is nicely, usually nicely isolated from the rest of the application and you can go down as many levels as you need to. Until recently this wasn't really possible on the web. You had these building blocks of a certain sort of level in the stack, the attributes, your links, your divs and so on. But if you needed to do something down at the fine-grain level you couldn't really do it. And this is where in mid-2013 browser vendors looked at this and they figured that well you can build these higher level features when people ask for them but the problem is the native frameworks will always be a step ahead. So back in 2013 one of the complaints people had is I want iOS style scrolling. And there were a number of details you needed to have. There was a lot that you had to do to get that. Fast forward to mid-2014 and now the next problem that can't be difficult to implement in native, in web frameworks will be the Android lollipop style scrolling. And you couldn't go and add each of these as a feature. So the plan instead was to add these layers to the web, to take existing high level features like CSS and HTML and to provide instead lower level features which explain them. Who here has heard of the extensible web? So the concept instead is that rather than in browsers spending your time building the higher level features, what they figured is that the development community at large as they've shown with JavaScript is pretty good. If they've got the tools they can build these high level features. Most of the JavaScript code we've seen this evening is using ES6 but no shipping browser supports it fully. Even things like say classes, they're still being built in the native browser but we can use them today because we can polyfill them. So the plan is to take that idea that has been applied to JavaScript and apply it to the rest of the web as well. So you can read about this at the extensiblewebmanifesto.org and two of the signatories are Yehuda Katz and Tom Dale. So the core Ember team and also noticeable signatories from Mozilla, Google, the W3C and so on. And the key thing about this is whereas a lot of what goes on in the browser at the moment, for example, exactly what goes on when you specify or flex a certain of a CSS layout is sort of effectively magic. You can you can futz around and try and get what you want but if it doesn't quite behave the way you want whereas in a native framework you could always go to the next level down and implement it. In CSS you couldn't really do that. And that's something that's likely to change over the next year or so. So there's a bunch of examples of where existing features on the left that we have are being taken and a lower level feature is actually being created below them that sort of explains how it works. So Miguel talks about service worker. The app cache was what was actually built first of all. And the idea is using service worker you could have built something like app cache. But rather than run into the problem of app cache where they built it, then the work people tried to use it and found that it didn't do what they wanted. Instead you would build something like service worker first of all. Then the development community would experiment at large. They would find out what kind of high level APIs work well. And then those perhaps can be standardized in the browser. So for CSS something that's only very started to be kicked off is something called the CSS Houdini project which is where things that are a part of CSS are like the box model. Fairly fundamental things for which you don't really have a JavaScript API. You will have a proper API for that. Web components has been a long story now. There are blog posts on HTML5 rocks that go back I think to 2013. And so, yeah, advertise it as if you can use it right now. But fast forward and, yeah, if you consider Chrome the web you can use it, but otherwise not so much. And JavaScript, actually just by virtue of being really just by virtue of making engines faster, you can polyfill a lot of things. So for example, one of the things I needed in the project I was working on was high speed pipe really performing cryptography. And I was surprised to discover that if I took JavaScript and wrote JavaScript like it was C code and used some ASM.js style JavaScript that I could polyfill web crypto even though no browser ships it at the moment. And language features, so some of the six language features, you can polyfill them in ES5 at a performance cost, but it's low enough that it's not a problem. So the question is if we have this low level control, does that get us to a point where we can implement components like as good that are as good as an Android list view or let's say UI table view or something like that in our apps. And the problem is, back to this again, there's a lot of code in these components. So even if we did have all the controls necessary to implement it. And not only is this a lot of code, but it's also continually evolving code. So we'd have to spend a lot of time trying to emulate it. There's a lot of ascetic and behavioral details. There's lots of magic constants about exactly how fast something moves when you flick it on the screen. There's lots of subtle performance optimizations. It changes every release of the native framework. And this is something that Qt tried to do for a long time on our desktop framework, they were sort of able to get away with it because platforms like Windows and Linux were pretty slow moving and Mac relatively as well. Fast forward to mobile and there's a new major version of iOS and Android every year or even faster than that. And that's not really going to work. So the question is, if we can't duplicate these components, is there what else could we do to provide a really rich experience? One option is go and build another UI framework on top or UI platforms, so to speak, but one that can work on the web and work on iOS and work on Android. And this is effectively what Google and Microsoft have done. So in Google's case with material design, and in Microsoft's case with modern UI or Microsoft design, they've changed the name a few times because people got upset with it. The difficulty with this part of course is even if so with material design, you have a really detailed spec or a pretty detailed spec which tells you a lot about how it's supposed to look. It also tells you what it is about the essences that make a component feel like it's a material design component. Because often if you're going to build a custom thing, that won't be covered in the spec. But at least it tells you things like if you're going to do an animation, here are the sort of the attributes the animation has to have to feel like it fits in with other components. But still, when you get a concrete implementation of a material design component, it's still going to be a complicated beast. So on the web, Google have built at least two implementations of material design, polymer and angular material. They've also built them for iOS and Android. And if you're a designer or you give it to a designer in these implementations, they don't have to spend too long before they notice distinct differences between them. Almost to the point where if you took the iOS version of material design and you gave it to an Android user, they might feel that something's slightly off. And on the web, we have, there's an angular version of it, there's a react version of it, ember. And they're all complete to different levels. They all work on mobile and desktop to different levels of fidelity. So I think it's a good approach. But there's still the bottom line that a component takes a lot of time to mature. And there's a lot of work that's gone into the native ones. So if we can't beat them, can we join them? Can we take our web frameworks? And is there a way that we could leverage those native components? And this, I think, is a much more interesting development in web frameworks that's happened very recently. So the idea is in ember, ultimately, you have a template compiler that will take a string and ultimately what gets spat out, at least until very recently, was HTML. But could we abstract that? So instead of generating HTML, we generate kind of a virtual UI or a data structure. And then we can map that to the native framework. So the first use which got everyone excited about React was being able to generate a string on the server, which could be rendered directly, and being able to generate HTML markup, so being able to generate DOM nodes in the browser. That's the thought that talk's about. But it's really just the tip of a much bigger idea. So the idea is instead of generating the markup directly, as say, Handlebars will do today, what our app instead generates is almost like a conceptual UI. Something like what a designer might sketch out. If someone says, what should this UI look like? One of the first things you'll get might be a low fidelity markup. That essentially is what your app would generate. The framework in the middle is then responsible for turning that into iOS and Android views, HTML markup, DOM nodes, et cetera. And then when you interact with these, the native events flow back into the framework and get converted into synthetic events that go come back to your app. So there's a couple of, there's a few implementations of this idea that I know of. I'll come onto that in a second. So the idea is you wouldn't necessarily just have, it's not right once or right once run anywhere because an iOS app doesn't look like the same, it doesn't work the same way as an Android app from a design point of view. They have different behaviors and different usage, different UX patterns. So you're still going to need to do that work, but the advantage you can have as an app developer is that you could use the same style and approach to build an app for all of these platforms. And whereas with a web app it might be pretty obvious that it's not a native experience, parts of it wouldn't feel right, you could have the end result feel native from a user's point of view that they would have all the details that are embedded in those 9,000 lines of code. But from an app developer's point of view, someone could someone who wasn't that familiar with, say, Java or Objective-C could at least take the code and they could work on it. So it's not right once run anywhere, it's at least learn the concepts once, whereas today you'd have to learn Ember, Cocoa, et cetera. And there's a very high cost of building for each of these platforms in a way that's half decent. This is an interesting approach, I think, that you might have the frameworks that you might be able to reuse web frameworks like Ember or Angular to deliver. So implementations of this idea, in cute on the desktop, when they first came to port it to mobile platforms, they figured that the approach they'd been using for the longest time, which was to have generic buttons or text use or list use and just skin it for the platform, wasn't going to work because mobile platforms were so different amongst each other. So they came up with something called QML. And the idea there is that you specified a tree structure in what looked like a JSON object. And that would actually be, you could write it in the same style using the same tools for different platforms. But actually on the platforms themselves, they would be mapped into native components. And then more recently on the web, this is the fundamental idea behind the way React works, is that instead of generating an HTML string or DOM nodes, instead it generates this virtual UI data structure, which has the advantage of being very lightweight. And then there's a DOM implementation in the browser. There's React Native, which was announced recently. And if you want a demo, install Facebook groups on your phone, that's using it. And Flipboard announced yesterday React Canvas, which is where they wanted to bring Flipboard to the web. And the problem is every time they tried to touch the DOM, they found it ate too much into their frame budget. If you're trying to run at 60 frames a second, you've only got 60 milliseconds in which to do your work. So they figured, could they build themselves almost like a lightweight DOM as such, or just enough for what they needed? And they introduced React Canvas, which is where they use a Canvas for all their rendering. But they had the convenience, almost as if they were programming through the DOM, by rendering. So they would build this virtual UI on the left. And then that would be rendered into nodes on a Canvas. But you could imagine also WebGL other outputs. So those are a couple of implementations. And React is the one that everyone's interested in. But what about Ember? And this is where Ember, very recently, in this introduction of HTML files, could possibly be an avenue into this approach. So previously, handle files was essentially a string generator. Put a template in, replace the tags in the mustache, generate DOM output. The interesting thing about handle bar HTML bars is it does at least, it generates actual DOM nodes. So potentially, there is room into replacing this block down here for something else. So I'm not sure about whether that's an avenue that you wouldn't be able to talk about exploring that. But maybe it's a possibility for the future. But the interesting thing, I think, is it opens a nice new avenue up for a hybrid app. So just a summary of the things I've been learning on this little journey. So apps are all about components. And in particular, in native frameworks, components are complicated beasts. And there are two things happening, or three things going on in the web world, which will help you get closer to being able to build those applications to the web. One is the extensible web project, or manifesto, which will give us the tools necessary to implement these complicated components in the browser without having to go through a whole standardization process. So those are the lower level components that build, the rich you want to polyfill on top of them, and then the rich you want to succeed, but they can be standardized. Another is cross-platform design, which is not a technology thing, but at least if you're building for the web now, you could go and build, for example, something using material design, and then the user could use that app. And even though it's not the native framework on a phone or platform, it could feel familiar to them, because they would have used Google properties. They would have used Microsoft tools. So that, to some extent, mitigates the problem that it would feel out of place. And lastly, another interesting avenue of getting hold of this functionality that's still being able to use web frameworks to write your apps is by extracting away the way your app builds the UI from ultimately what gets rendered on-screen and how the user interacts with it. Questions on points? So, when it sees it at 9,000 lines of code, do you have a sense for the complexity that that's trying to address the user's composition of that, the complexity is there? I would say, so some of it, some of that complexity would be stuff that you would get free in the browser. But I would say it's spread over all of the areas. The main thing is there's a lot to a text queue. You've got, say, it looks in a fairly simple widget on screen, but you have the layout going on, the rendering, individual lines of text, breaking them up, and so on. And in some, I would expect as well as that as well. If you look at simply the sheer size of the API, that could give you some idea. So I think it's simply, to some extent, because there's a lot of functionality being packed into these widgets. You could argue that actually a better thing to do would be to break up those widgets into sort of smaller chunks. So there is, to some extent, it's too simple, because there's a lot of stuff packed into one thing. But I think the really important thing from a point of view of someone using the API framework is that when someone's building an app using a native, using, say, expert or something, they will just plumb the UI to be able to be different in their storyboard, and probably they get all that functionality. They might not necessarily need all of it. But there's some more sorts of little behaviors that they capture. So for example, what happens when you've got the press, and you use them all up, the speed of animations, there will be things in the details about how the layout works, and so on. So it will be spread amongst a lot of different facets. But it's simply with the swirking for interactions, perhaps they're used to interacting with apps, which bundle will their functionality with those being in normal? Sure. One quick question, which is, it feels like a lot of thinking, which is understandable right now, is how can I use web technologies to emulate a native-like experience? But if we were to move forward in a period of time, and be, instead of emulating a set of the Android experience, iOS experience, then whatever you just said was just create the HTML, CSS, JavaScript experience, for mobile devices. Does that change things at all? I mean, when you lose the old baggage associated with emulation, and trying to be minute, and rather just create it, because I think there's one of the big strengths of the web community is its scale, its size, and there's this huge appetite from a business entrepreneurial standpoint to adoption, and it allows them to deploy instance to platform. So it is the whole VHS data that's waiting to happen. I think that's very much the thinking behind something like material design. It's not as effective as thinking that it's not just a technology problem. So the extensible web is an important thing that will need to happen, and it is happening. When you get that, you would be able to build the performance and the response of missing the offline functionality that people will need, and at that point, building a mobile app and using it as long as you can build something that feels familiar, then, yes, I think it does become a much more practical option. I would suggest, however, there is always the thing that, of course, new models, new work, the Android and iOS frameworks are not standing alert. New functionality is being introduced at all the time, new behaviors, and people would, and a new native app will continue to be developed very often at all the time. So there is to some of it, the extensible list that we would like to catch up, but having this cross-platform language and having enough people adopt it, that will, I think, help to the largest extent. So if you use something like React Native, you're obviously not programming in the native APIs of the platform, and you're not using those EUs that are native to those platforms. You think it's a reasonable trade-off. You think you gain enough by sharing the code across the different platforms that you are happy to not so much go to the fuller. So one thing you absolutely need, and from the use of placing the code to the other side, if you're going to have a stick, you should have a design. If you're going to copy a particular platform, and you're going to sort of, the amount of resources you could dedicate to that particular platform is limited, the best place to put it is the design app. So our design, we recently, we're going to launch our Android app at work very soon, and our designer for that, someone who's lived his entire life, his entire recent life, on Macs and iPhones, ditched his iPhone and spent a year just using an Android device to learn how to do Android design. So you need, I think, that kind of commitment to make stuff through. In terms of the trade-off, there is a trade-off the whole way along the spectrum. And if you're building fully native, you have a set of trade-offs to make. If you're building fully web, there's a set of trade-offs to make. And the useful thing about the virtual UI is it simply adds another point to that spectrum, so that, which one which, something that's already worked out, which is the same thing, I was in my job, that's being able to be able to share lots of, there are a number of ways to share a code, so Google, Microsoft, etc. have found lots of ways to share the core code that they're at. And then they will build the entire UI. You usually have maybe even a 17-inch platform. So this adds kind of intermediate on that front. But there's a middle of a magic solution. I'll just mention what is going on in the end-of-space. So Miguel talks about fastboots. And that's rendering strings on the server. And part of the work that's going to that is a react-like virtual DOM implementation. And I know that a couple of years ago, one of the core teams had a go with getting embodies to interface with Titanium to generate IOS views. So it's something that's been experimented with before. And I imagine they'll look at it again, or somebody in the community will look at it again. OK, that's it.