The Future Of JavaScript Frameworks

the web benefits from a healthy relationship between browser vendors and web developers and framework authors and their users are often at the forefront of trying to find a healthy balance between DX and UX so today we thought we'd bring along a few folks from frameworks libraries and their users to have a chat about what the better future could look like so joining us on the stage we first of all have Andrew Clark from reacts Android next up we've got Jason Miller from reacts we have Steve Orville from the polymer team Rob Wormald from angular Tracy Lee from this JavaScript and rxjs chatty tala from glimmer and ember Shawn Larkin representing PJs and web pack [Music] malte Google the tech lead of apps and finally Alex Russell from the chrome team lover of frameworks all right sit down so thank you to everyone that managed to get their questions in today we have a very special prize for the best question courtesy of Alex the very best question today gets a very average Moto G for phone that's gonna stay over here for now awesome so let's let's get into it very first question that came in was which features if any would make your life as a framework author or user easier if they were added to the JavaScript language or web platform more broadly Jason you want to start us off sure is there's been some stuff going around recently about a proposal called Dom change list and I think one of the end games of this spec is basically a way to serialize a set of mutations to the Dom one of the end results of this would be we can start to run more application code in a web worker web workers have existed for a really long time and are strangely underused in our community so it's a primitive that whether it's polyfills are implemented in browsers once we've got some of these things in place we can start to offload a lot of work off of the main thread and reduce jank on mobile so that's like a huge thing that I'm hopeful for what do you think it is about web workers that have like stopped them from getting as much traction as they could they're scary also you know by default when you construct a worker you have to give it a URL and it's it's pretty easy like get a blob URL for an inline string but it's not like the default behavior so for where there's like a task lit API that might be proposed to solve that that would be another huge feature so that a framework shipping could instantiate a worker with some code in it and that wouldn't be a weird thing right that would be expected so ok so web workers Rob on the angular side did you have any opinions about that I know that angular is Stora Cleavon trying to invest in web workers yeah I would second the the DOM angellist api would be amazing for us look I think we could put it in tomorrow and it would be it would be ready to go so that'd be a big one and then observables would be the other big one that we'd like to see angular developers using a ton of that they seem to really enjoy it it would be nice to not have to ship that code and not pay for those bytes and I think it opens up a lot of interesting things on API is like intersection observer and you tation observer I look at those and go those are kind of perfect for the sort of thing we're talking about so those would be the big two for me is there something specific other than having to ship it like solve this problem in user lands that stripping observables in a browser what would bring I could probably talk for like an hour about that I think for me that to me it's kind of the same thing that we went through from callbacks to promises when we got a type and you get a thing you can pass around and treat like a real thing I feel like we need the same thing for events right and that's more or less than observable is for me is that get a handle on the thing be able to pass around tree like an object and it really changes how you think about doing complex event things drag-and-drop all these really highfalutin animation stuff we all want to do this interaction stuff I think it becomes much easier when you have a primitive for handling really what's delivering you shadows guy was curious what from the the glimmer and Ember side do you feel is missing so again the changeless stuff we actually have like a straw man like implementation of this in the glimmer VM a lot of the work that we're doing on the glimmer side is instead of compiling like a template like how vast majority of these frameworks authors you know projects do what we are trying to do is compile templates directly into like a bytecode format and so the changeless proposal is more kind of a line with that because the whole idea is that you would build up all the operations that you need to like manipulate the Dom that's a typed array you can transfer that across you know different workers and everything like that and then apply it on the main thread so yeah I think that change lists or something like the change list would be I think great okay so we've got change list consensus and we just ship that now I think yeah you do change this Plus worker dumb there you go change little worker dumb Alex do any opinions on changeless no it's very straight fake bugger for its terrible down that you want them Tracy we so observables were mentioned I know that in the rxjs community observables are a big thing there as well do you need takes on you know our art our observable something browser vendors for seriously you taking a look at baking in I totally think so I mean I know there's a tc39 observable spec happening and hopefully that moves somewhere and just earlier rob was talking about hopefully how are you guys gonna champion a door I think we may it well we're looking at it so hopefully that land soon observables in the browser but I think if we're able to sort of start getting those types of things to happen that are sort of more native than what's gonna happen is I think hopefully the ability for people to use our XJS and the learning curve is a little bit less daunting yep awesome Malta so I was I was curious from the amp side other other capabilities you feel or missing so what I would like to say because ever mentioned workers for like what browser windows could do is and hear us like we all talk about workers the developer experience and dev tools isn't great yet so if you could invest in the future and say like maybe in the air people actually use workers but then have the dev tools already be good that would be amazing I also have like something am doesn't really need it but I think everyone kind of wants this which is just really good week maps so they launched a feature called week nib that's not actually what you usually would consider this so just having like a cash they can put stuff in and maybe it's still there but you know not considered by a college collection like if you build something like relay or you know even Redux I think everyone kind of wants this and it's not you know pin coming and that's really sad okay so it's really creating at this uh so Steve that's curious did you feel like there any capabilities missing from the platform that would benefit folks that are writing you know applications using web components or polymer yeah I mean I think I definitely a second the JavaScript API is that are mentioned I mean we think a little bit more about the Dom here and just say like you don't there's tons of cool stuff that we run into when during that I think would be nice to add to the platform specifically stuff like you know a lot of the stuff that native elements can do that we can't do in custom element land there's cool stuff that like the dialogue element can do that we can't do render stuff on top of other things in input element of course a new infinity stuff be awesome to deconstruct that and really add that to our tool kit you know so that we can use that as developers and anything from the react side yeah things that the browser can do that frameworks can do API is that expose that I think we're always exciting to us our favorite our current favorite API browser API is request idle callback that is we use it at that everywhere that's kind of core to how we're thinking about basically what our goal is with react right now is did everyone enjoy that image async feature that y'all talked about what if you can make any component async and just make any of your components stop blocking the main thread so scheduling primitives like request out a callback there's a really cool proposal I think the what WG I was get the different things confused but there's a really cool proposal proposal called async append which i think is a very interesting problem space this basically lets you build up this tree of Dom whether you using react or whatever you could mainly create this and asynchronously append it into the Dom you get a promise that says once all of the layout and everything has been done by the browser and then once the promise resolves you can decide when you want to actually commit that change or actually flush the changes it's really cool reading that document cuz it's kind of just a description of what we're trying to do with react as well but that's the type of thing that react can't do or a framework can't do is all unless we implement layout which maybe we well but realistically for now we can't do that so that those are the kinds of guys that we get really excited about so we thought we saw some convergence on Dom change list is async append something that any other famous we see lots of nodding and fingers and alex is also happy yeah that's great okay we've got we've got some convergence on this that's great let's let's move on to another questions so folks are wondering what criteria should you use if you're trying to select the JavaScript library or framework to build a new app today and given that he's just written a blog post about performance budget so I was curious on Alex's take on this and then everybody else's you might get a different answer depending on who you ask today I work in chrome I used to work on frameworks and working on a browser means you represent the user and so I wind up representing the users interest in a lot of these conversations and the way I see people constructing the applications today is incredibly well-suited to the computers and networks that we were building and using about five years ago six years ago right networked computers that were had reasonable and good stable latency fast pipes copious CPU relatively small screens compared to the amount that you've had to paint so that's not the world we live in today mobile is much much much much much much much much much much harder than any of that ever was the latency on the networks is terrible the types are smaller and variable and so you know we've been working with lots of partners for a lot of years and our I think the way I would think about this is frameworks take some amount of your headroom how much headroom do you have is the next obvious question and I think you have if you're gonna be building a framework based site you've got about a hundred and thirty kilobytes on the wire cheez-it so when you're selecting a framework I think one of your primary questions should be how much of that hundred and thirty K that you need to stuff all of your Styles all of your critical java scripts all of your data all of your markup templates application logic everything has to go in the 130 kilobytes how much of that is your framework taking is a question you should ask so one thing I was curious Andrea about this you're staring at us now next to me one thing I was curious about from the react side so we obviously see like a lot of applications being started today that are targeting mobile using reacts and and you know they're making a bunch of ecosystem choices about you know using Redux etc do you think that folks understand the costs of the ecosystem pieces they're using when it comes to trying to target mobile is this the scenario that need do I think people understand this problem um probably depends who you talk to one like downside I guess of the react ecosystem historically relative to the way maybe Emperor view I think for you does a good job with this is that we have like resisted the frameworks like I know you put frameworks and libraries in the title we've resisted like the frameworks label for a long time because react was designed to kind of fit into the architecture of Facebook like from four years ago five years ago so in the beginning like we never built like react apps as like single page applications we were building like little little tiny views all over a larger server rendered app so the first people that built like server rendered at applications were like way out ahead of us so we never like provide our own router we never provide our own solution for data fetching so I think what to the extent that people don't care about this enough and there may be in the reacting system I think that's kind of a consequence of that and the future I think with things like create react app and really cool projects like next j/s gatsby that are starting to give a more framework a holistic approach to how you're supposed to do service workers or server-side rendering which is I think is really exciting untapped area still or data fetching or whatever I think that's going to be a really exciting important area in the next year or so one thing that you touched on was things like next Jas being a good place to maybe so you see that as being a good place for us to try defining perhaps well it paths for people that are trying to you know deliver applications on mobile how do you what was the word you said well let well it pass okay I don't know what that is an opinionated path for fix well it's a little bit okay yes like a cowpath okay I respond to animal metaphors okay yeah I think that think we have resisted track taking like super strong opinions on things especially because the infrastructure use at Facebook is not we don't really use webpack even though we think web pack is really great so we've resisted giving too many opinions but I can see us like shifting more in that direction there are a lot of things like server-side rendering streaming service at rendering data fetching the data management code delivery like Sam was talking about earlier there's a lot of these things that are really the same problem space or overlapping the problem space that we don't have a great way of like pushing our solution or our vision of what that should be because we don't control like a framework II framework so that's why next and stuff really excites me in the reactor space because they are offering a little bit more of this and I think we will maybe start to dip our toe even further than creative react up in the future that's awesome Jason so pre axis is in a similar spot with respect to you know technically being a library what is your take on this yes I'd say if you're if you're making a technology decision about how you are going to structure your applications if you're picking something important like your view renderer but what you want to know is when I'm finish this and I ship my version one how large is it gonna be if you're picking a library you probably need to look at what the what the rest of the options you have are in that library space so if you're going with react you need to say okay how how large is a common router do I have a decent selection there you know for the various CLI tools or server-side rendering tools like next what is the end result of those kind of ecosystem you know approaches because at the end of the day if you end up going with next the size of react may not even have that much of an effect on your bundle it's more the size of next that you want to be concerned with and so it like even if you're not doing server-side rendering or next or Gatsby or whatever look at the common CLI tool look at the boilerplate you're gonna use and see if there's like a metric you can derive from that not just the library cool let's uh let's switch up topics let's talk about Interop so framework Interop web component Interop there's been an interesting hot topic in the community thanks for a while Tracy I was curious what's your take on this there spec to you like is is it important for frameworks to interrupt together if you've got teams that are working in you know react and view in practice cetera is is that important as a thing for friend developers I think you look at a lot of large companies who just do JavaScript so a lot of companies try to say okay I'm just gonna go the Ember road I'm just gonna go to the reactor I'm just gonna go this route but then you have a lot of people who just have sort of disparate teams who try to say okay I have this angular app what's the you know what's this what's the library I'm gonna build with all these components and do I stick react in angular or or what do i do there so I guess it would be nice I mean I think it'd be nicer for some developers and I think that there are a lot of solutions especially in the corporate world that people have sort of stuck together it'd be nice that those were sort of more forward or maybe maybe you guys can come up with a solutions to do that or maybe a web tech can solve all the problems since Tracy put you on the spot shop what is what is web packs but what is your take on on framework Interop you know I think one is the biggest so okay I'll speak from experience what we do at Microsoft so we have over 98 products that ship in production that use webpack but no single one is the same and one of the biggest initiatives that is taking a significant amount of time is trying to unify some sort of component library or system I think some of the biggest debt that companies struggle with and even one like Microsoft is that we have to be able to move fast add features but then as platforms change or features are added or new frameworks you know crop up we want to be able to take advantage of these technologies but in a way that can still be agnostic and provide interrupts between teams so like I have my own opinions and you know I think view is really gonna blaze the trail in terms of how we might see kind of a generic statically analyzed kind of Rosetta Stone for lots of different frameworks to consume components and you know Jason I have worked on it a couple times yeah so you know he's already has a his a loader power bi web pack that's already taking a view component and importing it into a project and it works so I mean I there's a huge amount of you know opportunities for lots of people to explore so Jason I was actually curious you've you from the pre-act side of viewpoint of you've you've kind of been interested in web component support I think that pre acts been been doing a decent job of looking at Interop you've also been again working with Shawn on ideas around you know how can we take inspiration from things like the HTML imports approach that you know libraries that polymer have heavily been using and bringing to other frameworks could you talk a little bit about your opinions on what the future direction of that might look like sure so for me a part of the hip part of the win here is we essentially have a compiler model right that the web is obviously a target we write code for but it's also a target we compile code for not just with web assembly and these types of things but even just compiling to JavaScript but if we if we take a look at the way that we're using these compilers and we try to model our input after existing specifications like if you have a compiler that takes in something that is essentially a serialized web component right an HTML file with JavaScript CSS and a template in it that's an understandable independent layer you don't need to know how whatever the framework that renders it at you know after compilation works you could just sort of know how web components works and if the framework adequately implements slots then you know if you know how well it slot works then you know how this file works I think that Shawn had mentioned Rosetta Stone I think that's a good analogy for this if we can start to converge at least a little bit on what a component looks like right across all these different technologies what is the substrate that they're all built on then we can start to kind of you know cross compile between them you know you could write a user interface components library with you know beautiful CSS and encapsulation and some behaviors and then compile it to whatever framework you're currently using and it won't matter you know ten years from now you could compile it something else mm-hmm Steve I'm curious about your take on this there's there's the cross compilation idea and then there's you know just having everything work magically at runtime what does we take on the shape this brochure I mean as you guys probably know web cubes are web components are kind of designed to solve this problem so a little bit makes me slightly sad that you know it's everybody is not just gravitating towards towards it on the other hand I think you know the is evolving it's taken a long time and I think it's getting there and hopefully we will evolve it still and make it a satisfying answer to this issue I think one of the places that polymer has seen a lot of adoption actually is in you know big corporations where they just have this polyglot of different stuff and they just need a technology that works without you know wherever the Dom is gonna work and this is really where something like that web account is shine and I think this is something where like as now that this is kind of the year of the web components specs being implemented what widely you know I hope there will be more interest among the other frameworks here and I think there's there's I want to give a shout out Taylor didn't talk earlier to you to the custom elements everywhere that Rob Dodson has done which is I think that we took a little bit for granted the fact that hey we're the platform you know everybody's just gonna work with us and I think you know it's like to a lot of you know different approaches this is sort of a scary concept that now an element in the platform can be anything it can be whatever and I think this is partly incredibly powerful because it's sort of this democratic process of the cream of the crop can rise and and you know but at the same time it's also like but that thing could do anything it's kind of scary do I really want to use that and this is where I think the approach between custom elements everywhere is really interesting because it kind of is this idea that you know this the framework authors and the community of developers making these melons really have to meet in the middle you know and establish best practices such that you know it makes sense do these use these things all together and we can all benefit so hopefully that happens Rob so angular has been investing in trying to improve their Interop with custom elements mmm components in general for the last Wow what's what's your take on this so I kind of feel like the Rosetta Stone that that Sean was talking about I think that's what a custom element is I think that that that is and I don't think this group of people would agree on many things right completely I guess the group but I do think that we've all more or less landed on this idea that there are events and there are props or property whatever gonna call them right we all kind of an API that if you squint it's more or less the same so to maybe make your ear a bit better today a little bit better like I can I can say that our team has decided that you know we've we've always consumed web components that day one designs decision in angular I talked to enough big companies I'm sure you know companies that the Palmer in that have these very disparity because systems have a dozen different frameworks I think it's very sad as a web developer that everybody has to rewrite the date picker and every framework that exists right if I do one thing as I webbed up like somebody who works on the web now we can just write one date picker that's awesome and then everywhere I'll just quit right so so from our perspective right angular is a is a framework II framework as you said right we do try to solve a lot of these problems and so for us it's you know I think our bread and butter is these big applications every likes to build but for me would be great if angular components could be spit out as web components right it's it's a thing you look at it and it's a no-brainer and so six weeks ago we started really looking into this I've been complaining about it for eighteen months I said Alex Russell when I joined Google that we're gonna make this happen and finally it's happening so you'll be able to write an angular component and spit it out as a custom element and I think that the most important thing about that the the kind of crux to all this custom element stuff is that nobody has to know anything about how the component was implemented to make it work because everybody in this room already knows how the Dom works right and if that becomes the common API well talk to it doesn't really matter what happens inside of the component right we can all have this rosetta stone we can all talk and we can write one datepicker and everybody can be happy right on that note it sounds like there's there some some interesting convergence on the rosetta stone I don't idea I'm curious from the react perspective what's what's react to take on web components yes we have a slightly different take web components are really cool I think they definitely solve they solved the encapsulation problem and they solve the consumption problem where you should be able to consume a component have to learn 15 different ways to consume a component and surely you can wrap any react up and a web component it's not not that hard the question is whether or not we should replace like react components as a primitive for building your application with just writing a bunch of web components and on that note we're not as convinced because we use I could be wrong but I think another selling point for web components is that perhaps it obviates the need for a virtual Dom or for us to have to manage your own like like parallel and memory representations of your view and on that on that part web components don't solve that for us so cuz we use our internal instances not just for encapsulation but we use it for memorization we use it for you know computing changes we use it for scheduling that's the big one I don't know if you all have heard of this research effort we had to rewrite react but we're moving in a direction with react 16 and going forward where we're going to have a sync by default rendering and what this means is we need to be able to do we're gonna do all of our rendering work inside of requests idle callback basically and in order to do that you need like this double pass kind of rendering system where you have two phases you only ever async render phase where you do most of your expensive work it's all in request auto call back or maybe in the future it's on a web worker or whatever and then you have a synchronization phase where once you can compute all of your mutations into a dom changeless maybe you can sing synchronously flush all of them all at once and that's the type of architecture which we're really excited about there's a lot of cool features that you can build on top of this but it's not really possible without implementing your own data structures so we're like thumbs up on web components but we don't think it replaces the need to have our own data structures alex ribbony takes on this yeah I mean so um full disclosure Dimitri glazkov Alex komoroske and I started the project at Google that sort of started the web components effort um we're sorry pologize you know catch me later buy you beer I don't think web components actually have any bearing on whether or not you should have a virtual Dom right this virtual DOM becomes an implementation detail about how your component decides to handle getters setters attributes setting and all the stuff web components as an implementation give you a surface area that everybody knows as well so you can just reuse the day picker from wherever and then how you want to handle that question about how state gets handled inside of your component is now up to you it doesn't do any global coordination so I think this is one of these places where web components disaggregate a bunch of things that frameworks used to do frameworks have traditionally taken a bunch of different different responsibilities between ensuring compatibility across the Dom giving you a component model in the first place making sure that those component updates are coordinated in various places doing data distribution and event handling and web component sort of disentangle a couple of those and leave you with a few of those problems they don't solve everything so a few of those still have to happen um and it's interesting to see how the various frameworks are sort of reorienting themselves now the web components are kind of the same so yeah I think you know I think I've seen lots of people you know sketchy asses doing this great work with are using virtual Dom inside of custom elements which is super cool there may be using pre-act internally which is you know not removing a virtual Dom but it does leave that global coordination question open cool and uh sorry I just gonna say it just a sentence on the on the interrupt thing just to go back a little bit um I just want to I'm gonna sound like a broken record but one of the thing that we've found that it's interesting about interrupts is is this coordination problem at Facebook we use react everywhere but the other framework that we use is server-side rendering and if you think about it both of we have this system called big pipe the thing about both of these are asynchronous systems and it becomes a really interesting problem how to coordinate to incres asynchronous render so that things are popping in on the screen at different times okay and circling back to malta amp is one of the largest consumers of custom elements I'm kind of curious on your take about his Rob's so I I just had this conversation with a product manager saying hey we didn't they take her an amp and I'm like oh my god not again and what we ended up doing was taking the Airbnb react date picker using its pre act so it's not actually like 60 kilobytes and putting into custom element and because and it works fine like empties everything the date picker and and that is like I'm worried or worried about the people put all these massive frameworks and these little encapsulated things I think we need to understand that just because something is great than the interrupt level and we don't have to make a new date picker doesn't mean you don't even application framework no on the other hand like amp right now it doesn't actually allow you to write code in any other framework um so interrupt is a bit awkward but I think what our goal is is in the long term that you could just use you know react to render this stuff that you want to change and document it runtime like I think the current state is not where we want this to be that's just you know the thing we could implement in fall of 2015 switching gears up that we we are running a little bit over that's gonna take one or two final questions what impact is webassembly going to have if any on JavaScript frameworks and libraries Chad do you have any takes on those so I think webassembly is kind of interesting there's certain things I really like to talk today basically it's not a replacement for JavaScript if there's in places where you need the performance I think it will play a larger part of you know maybe not you know every day developers writing it but framework authors may you opt into writing in a little bit of C code to maybe eke out a little bit of more performance this is like some things that were experimenting with with glimmers in very high critical performance scenarios we want try to eke out as much as possible you got enough performance as possible awesome Jason did you have any other takes on web assembly I just something that came up I'm like a total web assembly new but something came up over lunch you laughs yeah I know the API it's about it also I wouldn't trust myself to write native code no so but one one interesting area that got touched on was for something like a polyfill for a really performance critical feature having the ability to write at least parts of the polyfill and web assembly could be really compelling we were talking about Dom change list if there's you know difficult Asians or something that needs to happen in there or the creation of that that array buffer if that's better done in see and webassembly is available why wouldn't you do it seems like it'd be powerful there so our final question is is not strictly going to do with api's but we had a question around you know what can we as a group do to improve diversity in open source which i think is a really important topic and something that i personally love to see us make some traction on Tracy I was interested in your take on this and you know I think there's there's a lot of really great programs out like as I'm a Google developer group organizer and there's a woman tech makers initiative that happens and it's a really great way to sort of you know bring woman developers together and give them a safe space to learn I think if you talk to women across women and just everybody in general but I got one cuz I'm a female if you talk to a woman in general you know everybody has varying ideas of acceptance and inclusion and what it should be and what it shouldn't be so I think you know not really forcing your opinions on women but just giving them a way for you know them to contribute the way they want to I think which is also encouragement in general I think in our industry you know we have this diversity problem and a lot of companies are looking for these senior developers where when you actually look at our industry you see a lot of junior female developers coming in and what we need to do is sort of somehow figure out a way that we're able to encourage these unit developers so that we can build senior developers and I think that's the biggest problem right now that's the biggest disconnect we have I agree with that Shawn you also this is a problem that you you have some thoughts on yeah I mean like if it wasn't for open source I wouldn't be here I'd still be like in tech support or you know like just say oh you know doing whatever and so it's like and thanks to you know a little bit of my privilege what why does this have to be a unique story for for just you know myself like we should be able to not only elevate the opportunities for every single person to be able to receive the same blessings many of us have just by being involved and passionate about something and so one of the things that were you know that we've seen is that we have specific outreaches for webpack not only that span gender or race but even just countries like we have initiative called webpack Africa that we're starting and a gentleman named prosper if you haven't met him where's you raise their hand maybe he's at he's back there somewhere he's helping lead that organization and their goal was we need to prepare people for the web for the next billion people and so it's like that means that we could have the opportunity to elevate somebody to a whole new life opportunity for the next million contributions or developers and so like we want to find as many ways possible to essentially elevate or provide more opportunity so that these success stories don't have to be unique they don't have to be rare on that note we are out of time please join me in giving a hand to all of our panelists you're very kind enough to take time out to come here today [Music]

Channel: Coding Tech

Views: 25,194

Keywords: reactjs, react, angular, angularjs, vue, vuejs, webpack

Id: CM2pK0PE6Zg

Length: 35min 51sec (2151 seconds)

Published: Tue Nov 28 2017