 This is the title of my talk. I gave this talk last night at the React to London meet-up, which was really really good fun and What happened is I had a really grand plan to build the same app in ember and react at the same time to get a sense for how they differ and I didn't give myself quite enough time and I hit this point with react where I'd read all the API docs, but I didn't know the patterns for moving on I didn't know the best practices for structuring an app So I just got to this point last night at the react meet-up where I ditched my slides and just asked the audience to help me finish You know the part of the react app I was on which worked really really well It sort of saved my bacon and I learned quite a lot doing it and learned quite a lot about the different philosophies At the same time. So I wanted to try and you know communicate a bit of what I learned. So that's me. I Look like that everywhere online. I work for these people I Co-organize this as you know and I co-wrote this So Actually, this fits in quite well with your talk Tom. This is from Creativity Inc. Which is a book about Managing a creative company and I really really recommend it Ed Katmull from Pixar. So I really like this quote and My point is that our hard problem is how to build rich user interfaces for the browser and The many good minds trying to solve it are all these people But I don't have all the time in the world no one does so I thought I would focus on these two and On the surface they're competitors and philosophically different, but there's a lot of crossover. I think perhaps more than ember and angular Ember and react have a kind of I don't know Like it almost a common sense of humor or a common culture to them. So Ryan Florence is a really good example of a kind of a guy who put a lot of Work and creativity and energy into ember and now has transferred some of that to react But taking some of ember's philosophies with him, which is really interesting crossover and he While he's terse and a bit snarky on Twitter in the end. He he winds up saying stuff like this Eric Bryn was on a podcast not so long ago talking about Going to Facebook and working with Pete Hunt and everyone on the react core team and how much he enjoyed it and how much they had to learn from each other and Tom Dale and Pete Hunt trade friendly banter from time to time So they like each other And I I want to use both like it they If the people who like react are so similar in sensibility to the people who like ember Then I think I'd probably like react as well. So I wanted to try it and more than that. I Don't know about all of you people But when I use any technology that the point is not necessarily to Adopt it and then make money from using it and applying it It's more like to take the ideas from it and the mental models and the techniques and take them forward Even if I'm not using the technology just to apply them and everything that comes after So I was hoping that by Building this app in tandem with the two frameworks I'd learn where the gaps in ember are where react can help out advice versa so the app was Something that is on the surface quite simple It's just like a little JS bin clone With some files that you can change on the left an editor in the middle and the results on the right And I've built something a bit like this before in ember last year. It was kind of like a JS bin just for ember and What's quite nice about building This app is in order to implement this iframe effectively In order to you know tear down what's already there and spin it back up again efficiently You have to learn a bit about the build cycle of the framework so Bootstrapping these two apps. Let's just compare that so as rich has shown us To get an ember app going Now these days ember CLI all the way install it new upper new app It's going to make Decisions for you many many decisions. It's going to install libraries for you It's going to tell you where it thinks you should put your files How it thinks you should test how it thinks you should implement CSP all this kind of stuff Which when I presented this to the react audience knowing that react is is more of a kind of library type Ideology where you know react is a sibling to the other libraries you're using The a reactor of her might reaction to this might be to be Disgruntled like I don't want this making all these decisions for me But I think the important thing to remember is that these are all decisions which have come from our community It's not one person deciding it all and it changes like it moves with the best practices when they come along And of course you can just install ember as a sibling dependency alongside other things, but that's just not the way We've gone on masses community react on the other hand I Generate a package that Jason in my projects and still react into it and then I can use browser fight to require that into my into my build workflow whatever that might be and When I set that up I use broccoli browser for I to do it. I was super super impressed I'd not I knew what browser if I wasn't how it works and what the point was But I'd not really had call to use it on anything It's really it's really sweet and the ember CLI team have noticed What a nice experience that is and I think in the not too distant future, you know, you'll be able to just In one of your ember source files a ember app source files You'll be able to import from something that's in your package Jason rather than rather than your power Jason So this is the build setup I put together for broccoli I'm sorry for for react with broccoli. I thought about trying to use gulp. I don't know it and I do know broccoli, so I Wanted power in order to install the ace editor for that code editor in the middle The broccoli browser if I library broccoli CLI broccoli react broccoli react is just a broccoli filter that wraps up React tools, which is the thing that can process JSX files Actually, I should stop here and just show of hands who's used react to any degree Yeah react itself which Yeah, it ships statically, but it ships mostly with npm like that's the advisory They don't advise much about the way you can structure your project But they do advise that you use browser if I in the build and react router, which is Ryan Florence's it's in some ways a port of embers router to react land and I learned something interesting about that notion Last night, which I will reflect on it a bit And in power all I wanted was ace builds because ace builds isn't shipped on npm But if it had been I would use browser fight to bring it in So I wanted my react project to look like my ember CLI project would with an app directory and a public directory and all the bits and bobs, so I extracted it like this and I'll just walk through how the the broccoli build pipeline works. So The simplest type of broccoli tree is just a path to a directory which will be copied over into the output So that's app gets reactified. So the JSX files get turned into JS files gets browser-ified So you give it that app tree which has been Reactified and then it's going to resolve all of the require statements all the way through there and bake it down into one output file Grab the index HTML out grab app CSS out grab Ace out of what I'm actually doing here is grabbing a complete directory of all aces bits and bobs out of Bower components and the reason is because ace editor. I don't know if you've used it But it's got various different modes and syntax highlighters and themes and stuff you can use and they're loaded lazily They're loaded when you switch to that mode and like the syntax highlighting for JavaScript in the linting is done in a web Worker, so you can't really package all of ace up and ship it as one file You need to let it like go and load its different bits and pieces Lazily as it as it runs so grab it stick it in the output directory and the public directory And a common style sheet so that my react and ember app look the same And then mode to all together and the build output looks something like this so my my Point of running through this broccoli build is this is not a million miles away from what ember CLI Is doing ember CLI is doing much more and it's pluggable But it's hiding away that sort of the steps that go through to producing this output directory and There's no ES6 translation in here But you could easily add it using the same principles that are in ember CLI and so to compare that with The ember CLI output build It's the same but with more decisions made for you and this this is kind of my This is sort of the theme of this talk is that ember makes lots of decisions for you and embers Companion tooling makes lots of decisions for you in the community do And you might hate that but you should try it and Similarly you should try the agnostic world of something like react So I want to talk about how the app is bootstrapped in either case like what's what does the top level of the app look like in both cases so For the ember app, I'm going to treat this as like the application template. What what does the overall page look like to begin with so in this case it's one div which is the pane on the left and I'm going to say that I'm just going to load the files in there's like the model for the top level of the apps I'm going to each over them and link to them there and Then an outlet in the middle because that's really all the routes I'm going to go to are going to be the files. I want to edit so that's what I'm going to outlet Then the viewer will be some sort of component that encapsulates the idea of an iframe you shove a load of code into it and it knows how to reload effectively and efficiently and So it doesn't I don't I Have found that using jspin, which is a wonderful tool Using something like ember or anything of significant weight It struggles to reload, you know cleanly every time and it's just not the nicest experience to play around with It's good for demoing like a certain a Certain bit of code and sharing it around but it's not actually that much fun to live coding so My top level react component, which I've just called app.jsx. This is what bootstraps the react app It's kind of similar in in some sense. So I'm going to Get my files from somewhere that populate this app Maybe I'll drag them out of local storage or a gist or something Go through some process to compile Those files than I think that I've been given into the data that gets shoved into the iframe There's no each helper for react But you don't need one because what you can what you can do is take that collection and map it into the DOM elements that you want to go in so using jsx this Stuff here gets trapped transformed into react virtual DOM nodes react virtual DOM components With this data plumbed into them You'll see link to there. Oh, it's actually a link Tag with the capital L that comes from react router. That's not part of react Core and then this is return. This is like the that same template but in react land So the div on the left with the files mapped using that function that generates an ally for each one and Then the pane in the middle and this is the equivalent of outlet in ember So again, that's this isn't an idiomatic react thing This is react react router how it handles the idea of like inserting a a child route into its parent and then Something like that ember viewer a component that encapsulates the idea of give me some code and I will efficiently re-render So Routing so I'm this is where I'm going to bring up what people at the react meets up told me So this is my ember router and really this is the important bit so For all of us here, this is going to feel really really familiar There's a file route in its path is just splat file ID, you know, whatever path you give it So long as it's not forward slash it's going to let the file route take over and do what it needs to do and render what it needs to render and And and this is my file route So I'm taking it as given that the application has all the files. I'm going to grab the one whose ID I've been given If I've managed to find one then that's the model if I haven't then it's a 404 And I'll just go back to the index page and then just a serialized method to make sure the URL knows what to do So in react land What Ryan Florence chose to do with the API for react router is modeled on the idea of embers But it's modeled as a component and he chose to to Just like run with the conventions of you know, something that will work with JSX just fine So this is the definition of the routing of the app, but like done as components and you Rather than rendering my app Component as a top-level thing. I render the router The router doesn't actually doesn't actually present any elements itself Instead it has these these two handlers app and file and they're just classes or there They're my react components and in the file that this is in you'll see them as like VAR app equals something VAR file equals something and Then this is the Technically it's the file component, but for all intents and purposes. It's an it's an analog of my ember file route so I grabbed the file ID from splat in this case I I've had the files passed in so in my In my sort of overall app template At the point at which I render that child route I make sure to pass in the files explicitly It can't reach up and get them. So I've been given them. I find the one that matches the ID I'm going to decide what What mode the editor should be in based on the extension and then I'm going to render a an ace editor component Passing in the the value of the file on the mode. I think it should be in otherwise just a kind of default So let's talk about that ace editor component So that's this bit So ace is just this library that ships and you know, you can it's it's got an API all of its own Which is pretty different from anything in ember or react So I think it's I wanted to just be able to treat it as if it were an input tag or a text area and just kind of plonk it in bind to on change and I Consume it that way from the rest of the app and hide away all the complexity of it. So at this point, right? At this point with the react meets up I wanted to be able to like plow through and show them how how I'd made each component and how I'd You know sent the data up through the app, but I realized with the react app I didn't know quite how to do that. So I'm going to switch to live coding mode If you'll if you'll forgive me Okay, so what I want to do is show you that ace editor component in both frameworks and see what you think about how they compare so React on the left ember on the right is that big enough for everyone. Yeah, cool So app components ace editor components ace editor will ignore Requiring it at the top because it doesn't matter too much I mean, I guess, you know, it's the s6. This is common js style require that browser if I knows how to Resolve So let's just skip to see the parts where we can start to compare like for like Okay, so um So an ember we don't need a render method because we're going to render well an ace editor doesn't really have a template we kind of just need an element to shove it into and Emma's going to do that for us any way by default With react we do we have a render render function, but it just emits a react virtual div and Then you'll see that react as a component did mount hook Which is exactly the same as embers did insert element hook. So this is a moment for you to go Okay, this thing is in the DOM. I can do something with it now and I'm doing Basically exactly the same thing with it in both cases. So Let's just bring those up side by side You know get the element. So in ember it's this dot get element and react. It's this this dot get DOM node Hook ace into both of those I'm just saying like a particular feature of ace that I didn't want and then I'm binding so Ace has its own event system. So I'm Just like I'm encapsulating the idea of binding to that. I want to keep all of knowledge about ace within this one component So in react I can just go editor on change and then this Handle editor change method its scope will have already been bound to this instance I don't have to worry about it losing context Whereas in ember I both need to worry about it losing context and I need to worry about it falling outside of the run loop so you see a run dot bind here and then Just stash away a reference to editor on both sides now on the react side I then call component did update. So the component did update hook What that's telling you is? New data came in right? but because all I'm rendering out of this component is just this div and I'm not binding any of the props that have been given to me to the div react doesn't know to Redraw so it's up to me to do something when new data comes in And that's what this is going to do So update the theme update the mode update the the value and these just wrap around, you know, whatever aces interfaces for doing these things But in essence Ember has these same things like I have these exact same methods in the ember side But in the ember side I'm using observers instead so rather than using a hook and then calling out to these methods Imperatively, I'm sort of just declaring that these are going to listen out for When I've created an editor and set it or when I change the mode or both this hook is going to get run and Assuming that I've got both these things I can set the mode on the editor set the theme on the editor so it's just this difference between What maybe is arguably simpler in react land That you've just got hook and you just like very explicitly say what happens there in ember You could kind of do the same thing if you wanted to but I've chosen to use the the more idiomatic thing of using observers and Annotating these functions that get called at the right time There's a bit of fun with this particular type of component in on both sides of the fence because So I want to update the value of the editor whenever a new value comes in from the outside And Also in the Yeah, basically that so whenever a new value comes in from the outside I want to call this dot set value on the editor and then also When you do set value on ace for some reason it will highlight it all so I just want to kill that off, but When you so you remember at the top I said I was Binding to on change and handling that event so When I call set value it's going to trigger on change and in my ember app at least And in fact on both sides of this So if you can follow the logic here, which I'm sure you can When I call on change it's going to get the value off the editor and set it as my value and that that will propagate out via embers bindings But this is going to get called because this is listening out for value changes as well So it's going to set the value on the editor, which is going to trigger change again Which is going to trigger value again. It's going to end up in a cycle. So I just have to check, you know, have I Are they identical in which case you don't need to set the value on the editor anymore and the same thing would happen in the react side except that at this point, I wasn't quite sure like in ember When I when I use my component so in my file template I've got an ascender and I bind the value to it and that binding says whenever Whenever the value changes from either end they'll remain identical and so ember takes care of like Getting the data out of the component and up into anywhere else that it's used but in react There's there's no such facility and that's on purpose. They The claim is that two-way data bindings become really difficult to conceptualize really quickly And they want this idea that you can you can consider your app as a single function And if you call it with the same set of data, it will always render the same UI Whereas in ember land, you know, you're more thinking about Almost it more of a more as a living system where things contain their own states and you just trust ember to plummet all together So this was where I got to the point of being like well, okay, so in my File component I'm using this editor component And it's a binding as well. It isn't the binding. So this value equals file dot value Isn't going to guarantee for me that the files value to change the file the files value gets changed It's just passing it down. It's up to me to set a handler For this component and then do something when that handler triggers and then probably Propagate it up. So I was kind of at this point where I was like so To the audience, you know It makes sense to me that You know, this this is this is act like an input It's going to trigger a change event. Do I bubble it through the DOM? Do I you know where where how far up the stack of things? Do I send this event in order to handle it and then sort of alert everything else of that change? because that's the idea you kind of let a change bubble up and then Tell go go up as far as you need to and then sort of let the changes propagate back down again and And The bit of advice I was given by a kind audience member was that If you've got various things which rely on a piece of data, you want to go to their closest common ancestor So this is quite simple, you know There's the editor and the viewer or sorry the the file component and the viewer over on the right and they both Need to know about the files value or in fact, then the viewer needs to know about the compiled value of all the files but So the change only needs to go as far up as the app itself so What ended up with with the help of the audience was Let's follow this through So when ace tells us that things have changed We're going to If we've been given a handler for the on change event just call it with the new value of what's in what's in this editor That's going to go up to the file component, which isn't going to mutate any data It's not going to mess with the file that it's been given to work with that's that's not what it's there for It's just going to carry on propagating that change, but with a bit more information. So it's saying The message we want to pass up to the top is this file has changed and this is its new value So I'm I get to sort of Embellish that on change message with something else And then it winds up in in app.js So you'll see that I've got my Effectively my file root also has an on change handler. So you can kind of think if I wasn't using the router. I might be inclined to just do Something like this you get the gist. It's kind of equivalent So that's going to come up I'm going to So this is quite interesting as well. So As I was going through this so in ember we are very quick to mutate objects bindings The promise of blinding bindings is that we're not going to leave a bit of state somewhere unattended like Any change you make is going to propagate correctly and get to all the right places But what the audience that react meter were telling me was Don't mutate state if you want to like pour some new data down into your your into your virtual DOM You want to produce a new set of files with this change? So Effectively I'm doing a kind of like half-assed Data-sharing thing here. So I want to produce a new collection of files if The and I'm going to do that by mapping the old collection to produce a new array If the file I'm on in that map function matches the one, you know I've just received notification about I'm going to return a new mutate like a new version of that file and for the rest of them I'll return the original instance. So if you imagine it's not It's not like copying every single file in the array. It's just creating a new array With references to all the files that haven't changed and one reference to the one that one new file that has changed so this is where with react you could use an immutable data structure for this and Get these really cheap copies of objects and get your undo history and things like that So if I was using Mori or ancient oak or one of those libraries I could probably you know have much to a much to us a way of saying go modify like produce me a new set of files by Modifying this file and it would know just to like share all the memory It you know share all the memory it can and then set state is the point at which things actually get rewent re-rendered So you're saying I Want to change the state of things and my change is that files is now this new files object And that's going to trigger everything to be re-rendered and I don't know I don't really want to talk too much on react virtual DOM and the reconciliation and the way it renders but it's worth looking into it's impressive what they've done in terms of Removing the complication of two-way bindings In that you that the react philosophy is that when you make one of these changes You can treat it almost as if you're refreshing the browser like it's like Rather than worrying about how I have I put this component in this kind of state and this one in the other and when I look It's just like It's as if you're re-rendering the whole thing from scratch But really you're not you're only making the minimal set of changes to the actual living DOM So I was really pleased to get to that point and I'll show you what the app looks like it's it's nothing to write home about but So I've not implemented the viewer yet because actually that was one of the less complicated parts The viewer I've written before and you can just post message just send stuff into the iframe and then interestingly so in in an ember app what you would want to do is discover there's an existing ember app called destroy on it which is actually a very cheap way to just like Stop a running ember app and its tracks and just like turn it off and then you can just dump it get rid of it And it's down to save the new one with react I think it's the case that I Would just it would almost be like I was just getting a function passed in and I would just be able to call this function Well in react what you do is you? You mount a node on a particular point in the DOM so I'd mount it on the body and doing that would not only You know refresh refresh what's it whatever's in the viewer But it would do so cheaply it wouldn't need to worry about the fact that there was already an existing react app there it would just kind of Make the minimal set of changes necessary to get from my previous app to my new app But the point was that you know now I've got an editor where in you know my My cool changes to my file You know they really do affect a file somewhere, but actually and I found this really fascinating the idea that What I've got here if I was using an immutable data structure. I could have an undo history almost for free here because With each change that I add I'm producing a new copy of my Starting collection of files with as much as can be brought over brought over each time You know shared memory So I think that'd be a quite a nice next experiment and then obviously Compiling a react app in the browser from different bits of JSX should be possible. I would have thought I think you can run you'd have to Things you were referring to like react you'd have to make sure they were available Things you're requiring but apart from that I think it shouldn't be too hard and similarly with ember You know you can run the ESX transpiler in browser There's no reason you couldn't you know take all the files in that list and kind of run them through a similar process to ember CLI but in the browser So one final takeaway Related to these different least differing philosophies that are so fascinating between between ember react and ember and react so After the talk I was having a conversation with one of the people who'd helped me out and he said It's really interesting that you used React router and he said that he and his team had tried it But they found it too tight to react and they ended up using something that was completely separate Just a sibling JavaScript library and then the two you know could could interact in any way they wanted And I think that's an interesting difference in philosophy. He kind of said to me He to paraphrase he said would I be right in thinking that you You kind of the ember way of doing things is You look for a library which already plays nicely with ember something that plugs into ember's ecosystem And I said yeah, that's that's pretty true things are nicer if it all kind of Follows the same conventions and he said okay cool. That's interesting in react React is just another little library that you use. It's not it really isn't a framework and in fact I believe at one point there was an experiment to Use react as embers view layer or embers sort of rendering layer and I could see how that could work You could sort react in you could even build like a react component and just pass state into it from a larger ember app so I Want to sort of give this talk again in the future and finish the app on all of that but already I feel like I've learned stuff about react which I can use already in ember apps And I've already started to see ways That I can take my ember predispositions if I were going to do a react app and make use of them Certainly in terms of bindings like how to get change events up to whatever the root data structure is so it can it can travel down again But the other thing I want to say is that the react meetup group was a really really lovely bunch of people You might remember we had Stuart Harris who runs that group come and talk here a couple months ago Which is why I went and talks there, so I'd encourage all of you to come along check it out So that's me any questions I typoed that so many times I figured it would be worse just aliasing it Yeah So luckily because I was at the meetup last night I can answer this question with some intelligence so the guy who spoke after me gave a really good answer to this so react has batching of operations and It's it's pluggable So there are various different ways you can handle it and I'm fairly sure you could handle it with backburner if you wanted to so the default strategy is That anytime you make a modification it will trigger a re-render sort of at that point There's an alternative strategy. You can use I think either out of the box or by using a library called react add-ons Which is you might have heard of this in relation to ohm Where you use request animation frame, so what happens is? It was really really clever to think about so You've got a bunch of changes which could trigger re-renders and rather than doing them kind of Synchronously you kind of queue them up to get done in the next request animation frame So it's like this change has happened. I want to cause a re-render I'm going to therefore request an animation frame and stick it in there You're going to do that as many times as you can before you hit that request animation frame You'll get there after 60 60 milliseconds. It'll flush all those changes into the DOM and then you'll have another 60 millisecond period in which to do to like move data around in JavaScript for for the next flush and because it's request and because it's request animation frame. It's 60 FPS, you know, it should Users shouldn't be able to see it like it'll be as high fidelity as the browser can render Yeah Yeah, I think ace does fire every key press Yeah I probably I would probably be inclined to debounce it so that you know you have to in order to actually send A change event out of that. He said it's a component You've got to be idle for 250 milliseconds or something like that just to give it a chance to to work I'd be very interested to see how react number differ particularly in this application With memory over a long period of time memory such yet because react sort of mindset and what I can gather is that Obviously don't keep too many things around but diffs are fine. Keep them keep them as long as you want replay them Passing around whereas Emma's obviously Mutable and do as little as possible to change and then that'll get resound So for things long lived applications in react I'd be quite interested to see how The performance cost of react mindset Yeah, so the diffs So what once reacts is once you've got the application to a point It just stays still in theory with react. Where's ember? It's kind of alive and breathing. Yeah, but then on certain different situations react is Obviously constantly changing for you imagine something like an analytics platform That's doing everything sort of every minutes It's obviously churning creating a lot of objects Whereas ember would probably be reusing the objects a little bit. Yeah, that's that's a really interesting point So yeah in ember you would so like Gmail for instance It'd be quite an interesting sort of the performance costs of the different mindsets. Yeah, so I think and This is interesting because so I guess my wider point is that ember Ember not only has very strong suggestions about how you should structure an application, but it codifies them It's API's are its best practices whereas with react it makes no such suggestions directly in the API is but you know It's all about removing complexity This is this is like the rhetoric of react team and Part of that is this referential transparency the idea that you can consider your app a function Which given the same in but always produces the same mark up out the end and they they They sort of see the same qualities in the useful data structures so that you know You don't you don't run the risk of having mutated something mutating You're starting set of data in a weird way So there was like a temptation for me in my file component when that change comes up to just go Oh, well, you know, I've got this file object to handle ready. I'll just mutate it in ember You you certainly would do that in fact You do it without thinking because you just bind them up in the template and it things are taken care of and React to the idea is is that that could come back to bite you you could mutate something when you don't mean to better to let the changes bubble up and You know, you wouldn't have to use immutable data structures I could have just performed it in place mutation But as I was typing that in the room last night people were like Don't you take stuff? And I see the point. I think there's there's value in both ways, but interestingly the guy who gave the talk explaining the batching he'd come from a a World of building native applications kind of stuff in cocoa in see an objective see and he He was really curious to see how far this react model will go in terms of performance by the idea of Effectively you're re-rendering everything every time. It's just that you're not actually changing the whole DOM every time because when you when you When you trigger a re-render on your topmost react element every component below it It's render function that's going to get called to If you do expensive stuff in any of those render functions or even if you do cheap stuff But it adds up to expensive you're going to run that every time so it's like in ember you can hamstring yourself by creating way too many complex bindings to make things start to churn and I think in React you run no risk of doing that, but you do run the risk of You know doing too much work in render functions, and they're needing to strategically move it to other places and instruct react You know we sing should really really react to be a lot more obvious because there'll be some whole page pain refresh Yes, whereas with ember it'll be a little flickering yellow thing in the corner red thing You know that oh, it's just this timer that I've got yeah accidentally bound to some div. Yeah Yeah, complexity would creep in surreptitiously with ember and with With yeah, like you say with react. I think the code you end up writing with a reactor is simpler Simpler at first blush if you're familiar with JavaScript It just looks like regular JavaScript whereas ember looks like almost almost like another language So I asked people about flux mainly which is Which is interesting it kind of goes hand-in-hand with react But it's not a framework or a library per say it's a pattern for how you How you handle that kind of thing about the thing outside of the rendering part like how do you Get changes of states flowing nicely through this application. So people spoke about flux But they spoke about it in uncertain terms. They would be people kind of said they weren't totally sold on that yet Some people said they were using react as the rendering engine for backbones basically No one spoke about anything really more than that in terms of MVC patterns I think everyone enrolled their own white white tell people were talking very cheerfully about Taking their react app and rendering on the server, which is very painless You can take your same react virtual DOM and render it to a string and just send it down the wire So that's interesting and I think HTML bars promises to be able to do some of the same It's I Don't know that it's a Guy gave a talk on it and demonstrated some really really nice qualities being able to do that render your You know your rich client app on the server first so you can get they can get markup in people's hands before the actual JavaScripts are started doing its thing, but it sort of feels like a bit of a stopgap You know, it's like a hack to get things rolling while we've got You know high latency internet connections All right, shall we go support?