 One of the things that we really want to start off with is actually just talking about the future of JavaScript and talking about the way that the web and the environment is evolving. So one of the first questions I wanted to start with was when it comes to ECMAScript TC39, things seem to be moving at sort of an unprecedented pace recently and it'd be interesting to hear from you. Do you think that the focus that they've had, do you think that the things they're focusing on now, do you think that's the right area, do you think there are things that you should be doing more of or less of in this particular area? I mean Doug, do you want to start with that? My perspective, it's actually kind of slow that the sixth edition came out almost three years later than was intended and that was because the process kept adding more and more new stuff and that slowed everything down. The consequence of that was that some of the good stuff that's in ES6 like proper tail calls and the ellipsis operator, that stuff has been held up and I really want that and that got delayed for other things which I think are much less desirable. The plan is that going forward they're going to stop doing that and instead try to stick to a schedule and any features that are not sound by the time they reach the publication date that stuff doesn't get published rather than delaying everything and then inviting more stuff to come in and fill the delay time. And you think that's broadly the right approach too? It's a better approach. Yeah, I would largely agree. I think it's true. I actually joined TC39 probably after the first time TC39 thought that we would ship ES6 and probably three years or something before we actually ship ES6. So I completely agree. I think interestingly the group of people that joined after I joined basically spent the next three years saying can we stop doing this crazy process? And I think the new members all were very eager to get on the new process. I think one thing that's important to note about the new process which I think Doug basically got right here is that the new process doesn't just say there's this binary idea of the feature is ready and we put our stamp on it and now it's done. And I think if you look at ES6 there's tons of features that are done but actually aren't in any browser. And that's actually really scary because maybe when the browser starts implementing them it will turn out that we got it wrong. So the way the new process works is that with features come out they basically get approved that's sort of interesting. So that's stage zero. Committee thinks it's a good idea. Stage one basically means something like there's a valid transpiler for it. Users are using it. There are good promising signs that this is a good idea. We have actual spec text for it. And then stage two is browser actually really implementing this. It's for real but it's still behind a flag in a browser. And then stage three is maybe browsers are starting to take it out behind the flag and stage four is okay now that all the browsers have taken it out from behind a flag it looks good. We can say that it's two browsers have implemented it and we know it's good. And only once a feature has actually reached stage four we'll get into the next version of the vacuum script. But again it doesn't mean that there's nothing happening between them. There's Babel transpiler or polyfill step. There's a step of the browser actually shipping it behind the flag. There's a step of browser shipping it not behind the flag. And I think historically we just haven't had we've had this like big binary thing and it mostly has existed in the land of thought. And I think getting things into the land of practice is good. Yeah that's a great point. So I mean in terms of the ES 2016 this sort of next version that they're looking at here there are a number of things that being considered. There are any particular highlights for you? Are there things that people should be sort of keeping in line? I think do you think they're really going to have an impact? I mean I think the bad news is ES 2016 is going to be a small release. And really ES 2016 is the first release of the new process and so what that means is that there's this weird ES 2016 is a bunch of stuff. So we'll have I think we'll get like the exponentiation operator and there may be some things like the ellipsis operator for objects. So you can do a dot dot dot in a in parameter position or arrays but Facebook pioneered this in reactant and pushed it on the committee. And I think it's simple enough that it might make it into ES 2016 is the ability to basically say here's a bunch of defaults to smash into this object. So there's going to be a few things like that but I think broadly because the new rules are no longer where ES 2015 was okay anything that made it in before the deadline no matter whether it exists in the real world is done but ES 2016 is you have to actually have shipped it into browsers. Obviously that means that there's a you know the first release is going to be relatively thin. But I think that's a good thing it's basically kickstarting the process of actually being honest about what's happening instead of pretending like all we have to do at STC39 is put a rubber stamp on it and it's done. There's anything that sticks out for you Doug? That should be good that comes to I mean thinking things like a lot of people are quite excited about sort of async away about some about dealing with some of the asynchronicity issues in JavaScript a little differently. I see a lot of really fuzzy thinking about asynchronicity. Asynchronicity is wonderful and important it's in fact how the universe works and it's also how programs should work and the thing that I don't like about await and some of the other tricks is that they're trying to hide asynchronicity so that you don't have to change the way you think about programming in order to live in a world that's asynchronicity and I I think that's probably not good that you need to understand and embrace and respect asynchronicity because that's one of the most important fundamental concepts going forward. Yeah so I don't agree but not but I agree with Doug's premise actually. I agree that one of the best things that JavaScript has going for it up that make it better than a lot of other languages I've written concurrent code in is that JavaScript is honest about the fact that two things that you can't just block randomly. You can't accept a node as Doug pointed out yesterday. You can't just say you know stop the world and then I'll move on to do something else later. You have to be honest about about asynchronicity and the idea so async away it actually may make it although there's been some as usual things have come up recently to make it not obvious but I think the the key thing to understand about await is just that await is not await is not saying pretend this is synchronous. Await is saying this is an opportunity that that you have to go on and do something else so unlike if you wrote like a Ruby program and in a Ruby program you said like read from this from this file let's say and that that happened to be synchronous there would not be any asynchronous there would not be any clue in your program so you would say you know file.read and that might take five seconds and there wouldn't be any clue in your program that that might take five seconds and that's I think indeed a very bad thing and something that Doug is right for saying is bad but await is the way of you saying okay I know that this operation may take time and I'm going to allow you to go on and do something else in the meantime and you're still sure that if you didn't write the word await nothing can actually stop so it's a way of actually of hinting to yourself and to future readers that this is a place where something else can happen in between and the nice thing about it is that in no other place can something happen in between so even if you write await a lot of times maybe you wrote await in a program of a thousand lines 50 times that's still 950 lines that can't have anything happening in between something is a Christian earlier you talked a little bit about and react and flux and this idea of sort of brings a functional programming into the client into JavaScript and it seems that again in the same way that there's been a lot of change in JavaScript in the last couple of years the idea of sort of functional programming has really again from my perspective anyway from maybe it's my ignorance has really started to find to find a lot of love from a lot of people and they had for a very long time but in the JavaScript community in particular is that something that you found sort of useful in your own day today it is I think it's it's very useful patterns like functional composition you know of objects in react are pretty easy to reason about they're straightforward they're not generally hidden inside a an engine level implementation detail they're very well exposed but it's not it's not an either or thing I and that's the interesting thing JavaScript has always been a multi-paradigm language there've always been people trying to use it to do traditional classical object oriented things there've always been people trying to use it to do more functional kinds of things whether they meant to or not and now increasingly the node community is is expanding the concerns a great deal and causing people to bring a lot more sophistication to the question I think the important thing to me is we spend a lot of our time talking to CIOs and CTOs and other people who run large engineering organizations those people clearly like and have comfort with strengthening both paradigms some of them think that tell calls are the bomb not many of them seem to think it's going to change the way they work tomorrow whereas a lot of people I'm not a huge fan of the new hard classes harder classes but people in large organizations love them because it's familiar it's comfortable it tells them that this is a language to be reckoned with because it has the features that I expect from the other languages that I think are serious and legitimate and so we're growing growing our language and growing our community at from all sides and in particular in how respectable it is to you know the big guys to the enterprises sure so I mean on that point should we take a couple of questions from the audience if you want to put your hand up as Amit mentioned someone will come to you with a mic but please wait for the mic to get to you so we can make sure that we can have it on the recording when you ask a question so first person ask a question one guys anyone at all so what we can do is then we can quickly go on to something else I mean one thing that's kind of interesting at the moment is the amount of focus that browser vendors are putting on to performance in terms of creating the web as an a sort of a level playing field deployment platform with things like web assembly with the idea of being able to stack up JavaScript and stack up the web runtime to be to be comparable with other runtimes like with gaming in it for example with like with ASM and putting Unreal Engine into WebGL I mean do you think that that is that's a that's a useful time that's a useful thing for browser vendors to be spending a lot of investment you talked a little bit yesterday about let's take a step back and say actually we need to rethink this obvious of course not I mean how many of you have customers or management who want you to be putting games into your applications I'm guessing anybody who needs game technology in in your applications so it's a distraction right when instead of doing things that the web really needs we're going to be chasing video games which is fun and I used to be in the video game business and it really is fun and being able to write video games in JavaScript would be fun too but I don't think it does the web any good at all I don't I don't really think web assembly is about I mean it hasn't my side effect of letting you port video games and maybe that's somebody's motivation but I don't think that's how we should think about it I think the goals that people who are you who want to use web assembly and previously ASM.js to advance the web are mostly about remove there's sort of a last frontier on the web about things that require native performance so things that require native performance are not just games but they're things like really common things like on gzipping files so if you want to let's say you want to implement a an htp client in the platform let's say the platform let's say you're building Doug's new thing you're building Doug's new thing you want to build some some fast some fast protocol you you really do want the ability to run code at close to native speeds and while JavaScript might be fast it is very fast and I think and I I had it on the slide right JavaScript isn't slow anymore JavaScript speed is unpredictable and I think I don't see I think there's anything wrong with wanting to basically say we're not going to be we're not going to tie the platform necessarily at the lowest levels to an unpredictable performance if somebody wants to go and do something really crazy maybe that's going to mean something like Doug's proposal but maybe it will mean something like porting Haskell to JavaScript maybe it means something like I meant to the web or porting Ruby to the web those things are are not really about games it's more about making the lower the lowest levels of the platform have less overhead and I think that that's okay I think that it's it's really easy to it's really I mean JavaScript is great I like JavaScript but I think if you want ironically I think if you really want big changes if you want to try really big things you really want you want access to the lowest levels that the this community has a has a way of trying things on for size and finding out whether they add any value or not I think some of the stuff we're talking about falls into that category some of it might be a glorious experiment that fails but we'll definitely learn something interesting from it I know that we are seeing I think we're seeing the first signs of as things push forward people's expectations keep rising and rising and rising you know what's the next wave for something like Google Maps well it's the ability to do free exploration in a map which means that you need to be able to render it as a full virtual environment not just a series of tiles that you zoom in and out on and you know there's a tile around you you could do that in quick time 3d in like the 90s so I think that there are actual contexts where things that we think of right now currently as gaming technology the ability to virtualize environments there is there is a clear emergent business case for those the question is just how do you do it which one of these things actually makes that possible and whether the browser is the best place to do it but right now I think the browser is clearly the best place to do it it's how we put something like Google Maps in front of the greatest number of people the most quickly and let anybody show up on any given day and engage with this amazing little piece of content that we created that teaches them something about the world so we are hitting certain limits being in a purely text-based world or a purely small vectors-based world is a is a limit and we are bumping up against some of that when we try to do interesting things absolutely I mean one of the things I'd also like to talk to you guys about is this idea of frameworks have become a huge part of the way people build web applications and by angular or earlier react whatever they may be what's really interesting is that some of the ideas some of you say really existed previously was sort of plumbing reasons right like the idea of the the event loop in angular and the idea that you couldn't actually bind objects in state and now with object observed that becomes slightly unnecessary with web components and building components so based on that kind of idea of sort of the things that have classically been the home in the home of these frameworks moving further and further down the stack you think that the context for frameworks is going to change the things they're going to do is it going to be purely around the idea of convention you talked about earlier for actually helping people build applications quickly helping them structure them or do you think that it's there's always going to be a place when that context is going to change a little bit I mean does Doug want to start okay I'm happy so yeah I I think a lot of that stuff will end up ultimately a lot of the stuff that you talked about will end up ultimately feeling wrong in a few years I object that observers already probably going to take a much slower path than perhaps some people had thought web components are also taking a slower path there are pieces of like HTML imports that are just not probably I mean Mozilla has said they don't want to implement it I think there was a there was a sort of an attempt by Google since since around since around 2011 actually to try to bring frame to make the browser have a framework and I think what what perhaps people learned was that there's a lot of hubris and assuming that the sort of the the the the foundation the platform that we stand on is stable enough to actually put a framework into the into the platform I think react is a pretty good example of something that shook things up but even even if you discount react basically every framework did things a little bit differently and if you go one of the things that I like to do is I like to go meet with other frameworks so pretty much everybody has been doing this recently and we had a meeting recently we meet pretty much all the time to react now that they're on tc39 but I've also met with angular and pretty much every time we have these meetings we talk about web components and we say basically no framework wants to use web components as the base because there's just some way in which we have drifted away from what someone in 2011 decided a web component would be and maybe I'm the first person saying that out loud on stage but I think it is definitely the case that trying to build something very high-level framework in the platform is really risky and the platform is better I wrote the extensive web manifesto a few years ago got a lot of signatures people like it I think and the principle the idea behind that was that instead of trying to put frameworks in the browser we should try to build primitives in the browser that enable framework to do more stuff and I think I think we're very unlikely to reach a point where like we are with jQuery right jQuery is stable you could imagine putting something like jQuery in the browser but it's hard to imagine putting either ember or angular or react component model in the browser the guide there's a lot of things I'm trying to digest dollar digest them all the I think you know on the one hand we have this vision of the of the future in which you know there might be another web a web 2.0 which is exciting the web 1.0 that we have now we're doing great innovative things in and I think as Yehuda said the low level the primitives the fundamentals are really where we've got the most traction where people can agree and where that allows us to make the most progress so the the question I heard is well what does that mean next for frameworks does that mean frameworks adopt web components or does it mean they do something else and the trend I see lately is of frameworks instead of creating their own abstractions frameworks and other tools frameworks bundle up constructive workflows based on smaller lower level tools so right now react lacks a framework right somebody somewhere is going to do something that bundles up react and a bunch of other great little node tools into something that they're not replacing those things they're not creating necessarily any new glue code for them they're just saying this is the this is the easiest possible way to build cool stuff fast and effectively out of these tools so yeoman is a great example of this yeoman just takes existing stuff that was already there on the web grunt all these individual little node modules and builds a great virtuous workflow out of and abstracts that away from you not by creating new weird leaky abstractions but just by putting them together and saying here you go so there it's the OEM model of software development you know take a bunch of other people's components push them out somebody recently took yeoman to the next level if anybody can remember the name tell me and they sort of wrapped a yeoman style workflow into I don't know if it's a binary or what but they hide all of the complexity of needing to use npm and bower and all of this other stuff you get the same output but and it's based on those same components that we know and love that are really well written that are small that are simple that are the unix philosophy but they make it simpler to interact with they make it a bit more of a black box and so the more we get into the node ecosystem in particular the more we bring that into the browser the easier it gets to take all of this great stuff that people have already done and simply bundle it up OEM it into solutions rather than creating new abstractions that that there's sort of trouble there's sort of a related trend here so I talked about the web as a compiled medium and that's sort of similar to what you're talking about I think one of the interesting things about about web components and even things like JavaScript is that increasingly people aren't waiting for for the web to bring things in pretty much every I guess angular we'll still have templates that get parsed on the client side but both ember and react to template parsing and compilation on the server side react wants to call it a template or not it's still a template yeah but there's an increasing amount of the workflow that actually exists outside the browser with the idea that maybe if we maybe we could do more work ahead of time we could save some work that doesn't have to be done on the client and this is of course the way that pretty much every native platform works every native platform has some kind of compilation step which takes some work that you might have to do every time you boot the app and pushes it to the time when you deploy the application and I think that that trend is actually a big part of what makes these things it makes web components work less well in the platform because if react and ember are basically pre-compiling or doing a lot of work that they dump the HTML parser would do in the client it's really hard to see how it's not even clear that there's a meeting point for all these things right because we're not even the H interestingly the HTML the HTML is no longer the meeting point the meeting point is actually dumb right the meeting point is is the an element or an attribute and and so it's it's I think we're going to see like we're going to see a ton of innovation over the the next some number of years in the framework level but I think it's I think the more like the more the browsers have done a really amazing job of just exposing low level stuff and I think we're in a in a digesting period right now a dollar digest digesting period where we're trying to see you know what the user land things that we can do with those instructions are I think we may have one question yay so in my previous job we were working on porting a legacy c++ system to the JavaScript using mscripten so what is your take on mscripten and do you think we should work on porting legacy systems or do you think we should start from scratch was the c++ system really good or was a crap because I've seen both kinds of c++ most of it's crap and so if your idea is just to take the crap and automatically put it into a browser I think that's probably not a good idea it's a it's a cat software author disk seems hard I think I might have answered your question um I mean if you stay here because it's what comes back to the point you made earlier about transpiling about this idea of the web as a sort of a transpiled target for a lot of things um I mean is that something that um you see as valuable is that something that you see um looking forward much more in the future yeah so I think the web has a really hard constraint that people don't talk about a lot but is really important which is that when you click on a link on google and go to a website you expect that website to load fast and maybe it's a game you could tolerate you know a few seconds but even if it's a game you can't tolerate 30 seconds or a minute on a website um and what that hard constraint means is that people are forced to do clever and cleverer things to make boot time fast so some of that has to do with loading things asynchronously or loading things on demand as you encounter some area uh but some of it has to do with doing more work ahead of time doing more work on the server um and one thing that's kind of interesting is that a lot of the time you can actually get better performance across the board actually by precompiling html or precompiling javascript um because you can confuse when you sort of throw it at the browser you're sort of it's at the browser's whim is exactly how they're going to process the thing that you gave it and maybe some browsers you may even get into a situation where you know one browser says you have to do it exactly this way to get the right performance and some other browser says you have to do the exact opposite thing to get the right performance uh and this is a real phenomenon that exists that happens when you build a javascript or or dom stuff and so that sounds terrible it's it's terrible someone should do something about that web azim is awesome uh no so what's i mean what's terrible is that make javascript is is fast but the performance of a language like javascript comes with unpredictability browse uh engines have to make harder and harder bets about about things that are likely to be fast and if their bets are wrong you you fall down a crazy cliff so it could be that v8 says you know we're gonna bet on you uh so this turns out to be something all browse all engines do but you v8 says you have to instantiate all your properties inside the constructor of a function uh you have to you know instantiate the if you make a new object you have to uh add all the properties in a particular order and maybe you know firefox will say you have to use class syntax it's actually the opposite is more likely um v8 was really looking at class syntax to make things faster and maybe someone else will say no we really want to use constructors and and that's that's just because uh when you're you're looking at javascript javascript doesn't tell you what you're doing they're sort of trying to guess they're making their best guess effort and making your best guess effort means that if you're wrong you it can be really expensive you're making really expensive bets basically so anyway the the point that i'm making is um sometimes you can get better performance by taking some by effectively taking some something that you have on the server side and saying okay we're gonna emit code that we know has the right performance characteristics today or we're gonna and we're gonna you know carefully step around these minefields that you might step on if you were uh if you were just a regular programmer and you can often do that without changing the programming model much uh just by sort of knowing what the engines are doing the thing about translation in that particular context um is the web isn't just javascript and an app isn't just data munging code it's not just computation if uh all you were doing was translating from c++ to javascript some um algorithms for doing vector computation um on the back end then sure why not i guess you're probably as likely to succeed with that as as anything else where you get into a lot of trouble is when people are like well i got a bunch of c++ programmers around they can make websites sure in fact really awesome websites in fact i know we'll do CAD apps on the web starting from c++ how about that that's a terrible idea that's really that and and not because c++ programmers aren't super smart not because languages don't have certain primitive fundamentals that that can be mapped on to each other but because the web is a domain is a really unique domain interface is a domain and what doesn't map directly from c++ in particular to javascript in particular is the DOM is css is how do you create great user experiences and make something that is usable and performant within the particular characteristics of this render context and nothing that you can do in uh transpiler is going to account for all of that complexity you can account for some of it in a very simple way and we've all seen those apps and most of us don't use them very much yeah i sort of talked about this in my talk this morning right like flex did this flex basically said you're not going to you're going to start from scratch you're going to we're going to give you a drawing context you're going to draw on it and it's going to be the same everywhere and then you're you know you get your select box i was just checking in full of thons of this morning and they had their select boxes to flex select box and it's like the the scroll wheel doesn't work and it's like i'm like just give me the native select box i want the one from my my browser and i think that's the that's sort of the point that you're making is that you if you if you just take if you take c++ which just has a drawing context and just splat some stuff on the screen yeah it will probably look on the screen the same way that it looked before but it will it won't feel native it won't feel like it's it belongs i mean even if you look at like any any like photoshop any any tool like that they spent a lot of time making it feel correct for the you know small number of platforms they support and so if you just take photoshop like imagine you take photoshop for windows and put it on the web and then you try to use that on os 10 it's gonna feel terrible right there's a great phrase about desktop java anybody ever heard that that phrase before and the thing about java is supposed to be right once run anywhere and the the the the slogan for desktop java is right once feel wrong everywhere not because java is not a good language but because when you're talking about user interface user interface is this unique domain and it has its own concerns and you need to address those concerns so there are people doing some interesting things like react native and you're trying to take javascript which is an interface focused language and you have people who are specialized in the realities of that and of how you make good interfaces for real human beings and converting that into a relatively similar environment that's also designed to build interfaces for human beings the concerns match up the domains match up and I think you have a much better shot at particularly when you're building a dedicated framework for that so if there was somebody who was building a dedicated framework for translating c++ based interfaces to good javascript based interfaces and that was a world-class framework because they understood that domain at both ends then great but that's that's the mistake that I see people make is they try to reuse something from somewhere else that just doesn't get the web doesn't get interface doesn't get the realities of this context um and it's it's a short term win in a long term and with react native you're still building an iOS app or you're building an android app they don't they actually tell you like you're gonna get you're gonna get a lot of sharing in terms of the the learning like your knowledge of the right framework but you're gonna write an iOS app and you're gonna write an android app and you're you don't want to I've used the apps that people write using phone gap where you're like on android and you suddenly have an iOS back button you're like that is completely not how this works at all right right and I think that to react native's credit they realize this and they're not trying to do uh we'll just have some c++ code and make it look the same everywhere that is indeed terrible so we have another question uh yeah so my question might take a little longer to us so it's basically um I've I mean for the last two days uh it has been a lot of knowledge and uh from different sessions so now I'm seeing you all of you together so I am uh kind of recapping what happened so Douglas uh focused you know more about the security on the web you know upgrading that and proposing a new system where the protocol is can be you know web call in uh Joe was uh you know he introduced about uh web gl and 3js so he was talking about these you know one of the possibilities uh web can enter to you know virtual reality gaming and all and uh Yehuda today morning um he was talking about you know uh the key to uh scale is the isolation so like putting these all things together so can we have you know from the browser uh developers so can we have a system like you know dedicated implementation for game like web column one of the url another url could be media column another url could be you know something like separating the concerns and this way browser will be you know okay to scale as per the use case as per the technology will this kind of idea do any good for the web you know we're trying to do everything with a platform that wasn't designed to do virtually all of the things we're asking it to do and we're frustrated with it with the web stack is so efficient in so many ways that's putting a lot of pressure on the standards to try to to fix it in order to turn into something that that's usable but the problem with that is that standards are not where innovation should happen and whenever we put innovation into a standards we see w3c doing this all the time ekma does it too often you end up with bat standards and then that increases the complexity without adding much value and ultimately makes the problem worse the best place to do innovation is in the libraries and in the frameworks that the um the good thing about the web is that it's programmable mainly in javascript and most of what is seriously wrong with the web we've been able to repair there and i think that's going to be the way forward so that we should be demonstrating as much as we can at the library level and when we have proved it there and when we've got consensus that we've figured it out then it is appropriate to start thinking about how do we turn that into a standard yeah i i totally agree with that um i think i basically could have no disagreement with that position at all um i think it's really easy for i think google does this a lot actually where it's like okay we have this problem a lot of people have this problem we have come up with a solution and we want to put it on the web so everyone could have access to it but the problem is that those that the google solution is really not any doesn't have any more likelihood to be the right solution than a solution that comes out of facebook or you know a community solution like the ones i work on and so the the better thing for standards to work on and this is this has been actually the entire debate really about web components has been uh the web component stories started out with like really high level stuff actually the original web components had a thing called mdv model driven views in it which was a a data binding system sort of like angular one and they eventually were like wow that is too but we can't we don't we're not going to do that but that was really where it started out and eventually slowly over time we've been able to get web components down to more and more primitive stuff but that that shouldn't be how it works right the way it should work is that you say okay what is the what is the reason that this is not repairable in java script or repairable using libraries um a good csp is a good example of something that you just can't do in libraries a csp the content security policy allows you to ask the browser as a programmer to give you a subset of the platform that's saner and you can do a lot of stuff you can say like no third party scripts you can say no inline scripts you can say no inline css these are all really good things to want to do as a person writing application um and so uh but those are things you can't do as a you can't do that programmatically so um we needed to add something to the platform and that that was a somewhat appropriate use of of standards effort to sort of pare down the platform to something sane um and and there's a lot I think every single time uh someone comes up with a big idea a great idea for how we can make everything better if only everybody did this big thing the the smart thing to do is to pare it down to something primitive into something small that people in the in framework land can use to try to repair the problem instead of trying to say let's spend the next you know five years web components are like going on five years now or something like this we we shouldn't spend five years trying to push through this really high level thing um we could easily have shipped as Doug said about yes we could easily have shipped smaller bits of web components years ago if we hadn't tried to do something so massive we have a questionnaire sure hi so um so as uh like um Zuckaberg said that all the like most of the facebook users like around 80 percent users on facebook are from mobile app and like recently in india one of the biggest online store called mincar.com they shut down their desktop app and they went mobile only and same is going to go happen for flipkart as the rumor said so you know since all of these like consumer apps are going mobile or maybe mobile only and like in the last two days we have just talked about you know doing the spot analysis of the frameworks but what kind of apps to be envisioned will will actually become norm of the web as in which will be developed for the browsers if we are not making video games and uh i know facebook uh and gmail and and linkedin these uh they they already had a browser app and then they went mobile right if if there's a new app that will come in future they might not even build it for the browser so uh um i know that with the with the existence of react native and node js and mongo db i have a reason to live but what kind of apps we are building for the future people are going to go where customers are um and and so a lot of this you know move to an app only um kind of thing just has to do with particular markets with particular user bases at a particular point in time and so i work in countries where signing up for new telecom service is uh 70 people using desktop and laptop browsers and there are we've got other countries we operate in where people signing up for telecom services 70 mobile only um and that reflects the different demographics and preferences of of those countries and sometimes where they are in their development so i don't think there is any one global overall answer to that question the interesting thing is that a lot of mobile apps truly are still being built with web technology even some very large companies are using a lot of web technology even stuff that we call a mobile app or sorry a native app is actually a very good percentage of um html and light javascript because rendering content in html is a lot easier and more flexible than doing it in 100 native constructs so even when we say that a given company that you know takes a lot of traffic has moved to an app um sometimes we still mean the web we still mean web technology web skills um it's just now in this you know on this different device that people think is really neat right now and you know 30 years ago people thought digital watches were really neat and how many of us in the room are actually wearing watches instead of looking at our cell phones um so it's abbing and flowing we we see a lot of it's country by country it's market by market um and there will be certain kinds of relationships like uber people don't call uber um or a taxi service all that often from their desktop because so often when you're doing it you're on the move you're out shopping you're eating dinner you know it's it's it's life you need to do it with you um then there are other things that you just inherently like to do with a larger screen and a full keyboard and stuff like that and it's going to continue you know separating you're going to have a little of each some experiences are going to be desktop focused so again some are going to be app focused i don't see any there's no apocalypse there's no web apocalypse just around the corner so on the flip side of the uber example when i send a i think people underestimate the the sharing aspect of the web um and in particular URLs every single time i see like this happens now like at least once a year some big company announces app linking initiative for the mobile platform so it's like facebook and google and whatever it's like how do you deep link inside of a mobile app um and at the end of the day people don't want to deep link inside of a mobile app they want to use URLs they in particular want to use URLs that work reliably across all devices so they they don't want a URL that works they if you send an email out with a link to twitter on it you don't want to send out a you know a twitter um protocol handler URL that only works in ios you want to send out a URL that works in android and i actually really like the fact that on android um the way that that apps work is that they capture regular URLs so if you you know if you have the app on the regular URL that you got with via email or any other text plays you know content works and if you don't have the application then you just go to your your mobile web browser and that will work also and i think uh so i think that's a way better model than the ios model like you you either go to a web browser or you have a protocol handler and those two never the twain shall meet i think that basically doesn't work at all um but i but i think if you look at for example when when i want to send my wife on uber uh a link to where i am that actually gives you a web URL that goes to a web uh website a desktop website actually that shows you on a map where i physically am as i'm going as i'm driving and i think again i think with all people all the doom and gloom about about web applications um whether on mobile or on desktop people totally miss the fact that the web is still the way that you can share in a ubiquitous way and uh you see there's all there's all this talk about like the web is so far behind native the web is never going to catch up to native and i every single time i see one of these like uh what app linking deep app linking initiatives i want to say like when is native going to catch up to the web right and that doesn't mean that doesn't mean that the native is worse than the web or the web is worse than native it means that web and native have their strengths and we spend so much time we the web people like to beat ourselves up we spend so much time complaining about the things that are not good at the web about the web and then we don't spend a lot of time thinking about the fact that even uh even digital magazines that are designed for the web designed for uh for tablets right so there was uh there was the daily which was a digital magazine that was tablet only if you wanted to share something what did you do you didn't share a link to the tablet app you shared a link to a special website that they built and its entire purpose was to allow you to share the content because you think they knew that they weren't going to get away with saying you have to have an iPad if you want to be on the receiving end of sharing this content so in this in this way uh people saw that example as a as a really good example of native winning look how native has won but but then when they actually went to build the experience that they needed to build native was simply wasn't up to the task they needed to use the web as a sharing vector and people just forget this every you know pretty much any application that is web that is mobile only that involves sharing of any kind ends up sharing a url that points you at a website and i think people just people uh again we like to beat ourselves up yeah i don't think it's either or and i think a lot of the companies that go app only will as they grow and get bigger and stronger they'll realize that they're missing out on some things and and they'll they'll have a web presence as well yep um i i think it's it's a good way to conserve cash it's a good way to direct your talent um focus them on just you know delivering one experience um makes perfect sense from a business perspective but once you've one made a lot of money doing that you're probably going to want the people who you can reach better uh through through the web there's a question we have time for one more question um actually we have a question from one of our attendees on live stream oh that's cool hi i'm him and uh i wanted to elaborate more on this uh topic which is going on um it's been a good conference and i've learned a lot of interesting stuff and the thing is that in this part of the world it's a mobile first world right how do you see javascript evolving specifically in the mobile first world and do you think that there's a lot of scope for javascript compared to native apps javascript is a programming language you know and it it's a general purpose language it can run in any environment and it can do pretty much everything as long as you don't push it too hard so um i don't see that javascript needs to change if you're talking about making the web more effective in mobile applications and the web needs to change a lot it needs to get uh much more efficient much of the performance issues that people have with javascript is really not javascript at all it's with the way the browser works and the way the network works and misusing of that stuff and making javascript infinitely fast is not going to change the character of most applications so it it's a much more complicated thing than that i'm hoping that the web continues to get better at managing its own performance but when you see us pushing on javascript performance and ignoring the rest of the web then that indicates that we're not addressing the problem correctly and we're not going to make progress yeah i totally agree that i i think that that was maybe one of like the perhaps shouldn't have been a surprise but was anyway of react was basically that javascript had gotten so fast compared to the platform that doing like ludicrous things in javascript were and and in order to save minor amounts of work in the DOM ended up being massive performance wins and i think react people sometimes think that the solution is i guess i guess what i would say is there's a lot of room to improve the DOM and there's a lot and there's a lot of room for alternative alternative models better primitives but i i totally agree that the things that are slow like javascript is sufficiently fast except if you hit a cliff javascript is sufficiently fast that if you if you're trying to figure out how to make the web run faster on mobile making javascript twice as fast is not really the story that whenever you like i think react and and ember when i so when i actually first started working on glimmer which is the the rendering engine that ended up being like you know it's like 50 times faster or something which is like a ludicrous thing to be able to say but if you looked at react and ember a year ago you would see that react was like many act 10x faster than ember and one of the when we started people would say people said to me look at the profile if you look at the profile it's like all these things happening in javascript that are spate that are taking so much time and what we need to do is we need to make the things that we're doing in javascript take less time and i said no i actually what you need to do is do less things and i think and that's sort of the i think the the idea is that you want to you don't if you're trying to make things run faster the idea is not well what if we can make javascript 50% faster or even 5x faster you're not going to get as much mileage out of doing versus doing like 100 times fewer things which is and that maybe sounds pie in the sky crazy but it is indeed what react did and what ember copied and there's there's room for more more where that came from i think there's a really a big unexplored frontier around css someone yesterday talked about the css triggers thing css triggers thing is like perhaps the the next big foot gun frontier of things that make the web slow for not any good reason and wait there's a lot of people thinking about ways to try to make that less of a foot gun and you could easily imagine sort of in the same way as csp opting into a model that doesn't let you blow your foot off as much and so i agree i agree that what we really need if we want to make the web faster is to i think we could put our foot off the gas and making javascript faster and spend a little more time on interactions in in dom interactions in css interactions in painting that make things really slow in mobile in particular i think some of the things that we're talking about to the extent that we can say that the equivalent the exact same code rendered on a desktop versus the exact same code rendered uh computed um on a mobile device is slower and is noticeably slower that's a temporary phenomena um morse law applies to mobiles the same way it does to everything else morse law no longer applies to desktop but it does apply to mobile well right which means that more like here's desktop and mobile it's just a matter of time before mobile hits the morse law limit also right um so there it's still catching up stuff that we take for granted today on desktop was prohibitive performance wise uh not that long ago there were times when gmail wow it's kind of kind of pokey kind of slow i don't know if i want to do my this whole web this whole email on the web thing that's kind of crazy isn't that you know that's never going to take off right who's ever going to use that um and so i i think some of these differences are short term and a little bit temporary um and there are people like uh the firefox firefox os um that are still trying to do an entire os or at least the userland parts of it in javascript the whole thing um so yeah javascript isn't going anywhere it's not getting smaller it's just getting bigger and people where's our node bots team where are they they're guys creating robots with um who wish they had the processor of a of a high end uh smartphone and they made a low end smartphone or even a low end smartphone and they made a robot with it that runs entirely on javascript and it's running around taking pictures of people um so yeah yeah i mean so tz39 actually recently decommissioned there was used to be a compact profile and every so often we get a big company coming and saying hey so you like you last you last released a compact profile like 10 years ago what's going on with that and every single time it would come up we would say well you know this research team or that research team um has been able to run the whole javascript in you know 200k or something so it seems like we don't need we don't need a special compact profile just to run it on on small devices and and and that's true right you can see very very low end devices now running javascript so i i don't think i don't think it makes the problem with the compact profile is that compact profiles mean that when you're going in to use javascript like there's a java compact profile when you go to use the java compact profile you have to learn a whole new language effectively um and a lot of libraries that you might want to use don't work anymore and and i think the nice thing about javascript is that even with all the bells and whistles pretty much it still can be run in a relatively compact yeah so we have a final question from the livestream yes so the question is that we are talking about compilation on the server side uh with jsps and psps have been doing it for a long time why are we trying to rediscover complex so we're talking about like isomorphic javascript um where some of uh your your dumb you know some of your html is pre-compiled and then the rest of it is passed down to us so we are talking about compilation of the templates on the server side right yeah it's becoming trendy now but jsps and php have been doing it for quite long why would we like to rediscover that and i will i'll take it uh yeah so people ask this question this the rails community has people that ask this question but i think it's fundamentally missing to me a pretty obvious point which is that um the reason people are running templating engines on the client uh and templating engines these days are are really are actually quite secure and much more secure than trying to to munish strings together either on the client or the server um they're pretty advanced the reason people are doing that is that as net as networks have become more and more ubiquitous so as more and more people have access billions of people now have access to networks it's not that doesn't mean that billions of people have access to fast stable and reliable networks what what has happened is that as networking has gotten more uh ubiquitous it's actually gotten less reliable so what's happened is you know uh there's a great blog post someone wrote called the prod cafe effect um and the the idea is you might be sitting in a cafe in some city and and trying to access something and if every single time you might want to make a little interaction you want to click on something or you want to navigate to new page or you hit the back button every single time you do that you have to go back to the server and ask it to give you a megabyte or even a few hundred k uh that that is really really slow it's not it's not a little bit slow it's basically unacceptably slow for for many applications and so the reason people are moving to client side is actually not because the client side is trendy and and I would definitely say if someone is using a javascript framework because they think it's cool or because they want to tell their friends that they're using a javascript framework definitely do not do that because they're it's it adds complexity to what it is that you're doing but the trade-off for the cost is that you're running everything as close as possible to the user right so what's the fastest cache you could possibly have is not a cdn the fastest cache is actually running things in the browser so that even if you have no network at all and an example that I I gave a few years ago and I haven't given recently is um if you use a native app let's say you're looking at twitter and you go look at it you have a list of tweets you click on a tweet and then you you know you walk to the wrong side of your house and you don't have wifi anymore you go under a tunnel or something and you hit the back button or native apps pretty much all the time you get back to the thing you were looking at before you see the list that you're looking at and pretty much you know a large majority of web apps when you hit the back button you see if you if that happens you see a spinner you see a white screen and you have to wait maybe forever maybe you end up timing out and the thing that client side web applications give you is they give you the ability to do stuff locally that doesn't require server interactivity so it allows you to decouple the things that really require server interactivity which is things like getting a whole bunch of new data that you don't want to download all at once or saving changes to the server those things require server connectivity but just showing the same piece of data in a different way or showing something you already saw before again those things don't require server connectivity and really the only the only way to do that is by downloading things now you could imagine a much more aggressive caching system where you know you just cached the html you saw before but caching html if you cached imagine you you're going to wikipedia and you cached the html of every wikipedia page that would be you know orders of magnitude more expensive than caching the raw source and creating the wikipedia page on demand as you navigate it around so client side web applications people aren't doing it for kicks they're not doing it because i mean some people are doing this is cool but most people are doing it because it gives you a genuine a real a real performance advantage over what they were doing before and and that's real and so the the case for why people are doing javascript applications is is clear it's huge you can just move faster do more things it's cool so why are they doing isomorphic javascript on the server is is that the question to me it just boils down to two relatively narrow concerns some of which may be a matter of time first page render and search engines and what you present two bots so first page render is partially something that is is being improved or that is limited by the the very same limiting factors that Doug was talking about deficiencies in how quickly we can retrieve data whether we have to do that serially or in parallel those things are getting fixed they're improving that'll make the first page render issue partially go away the other part of the first page render issue is just human nature people want it fast if you make them wait three quarters of a second instead of one quarter of a second some of them bail out we don't know why it seems to be a glitch in the human software it's a bug and so we're we're working around that bug in wetwear with this you know first page rendering on on the server side and that's something that's getting half dealt with by better technology and half maybe we'll have to do it forever I think we'll go forever probably we may do it forever and if we do though it's not a repudiation of it's not that well jsp was just as good a way of doing things it's that 95 percent of what we're doing with client side applications is the right answer if we can only just address this this need that the user has for instant gratification on that that first page render and then the search engine side of it I don't know I think that's evolving I think that they're getting the ability to crawl our javascript pages and come up with the same results we may have a long term need to be able to control what they see because the browser the search engines may not crawl our javascript apps the way we want them to crawl our javascript apps they may have different concerns and so but that's a that's that's a that's a very specific very narrow concern right once you've gotten the 95 percent of the value out of a javascript apps that you get from rapid implementation quick deployment everyone in the world can use it in the browser then you worry about the other 10 percent and this is a it's a it's a the other 10 percent issue so I think that's about all the time we have for this panel unfortunately and I want to thank Christian, Yehuda and Doug for their time I know got some great questions and I'm sure the people watching live streaming as well took a lot of value from this I also want to take this opportunity to thank the organizers of the conference I think it's been really fantastic I think they did a great job again this year and hopefully next year again it'll be just as good thank you thank you Joe thanks a lot guys thank you everybody can we have a big round of applause for