 Just okay hold on a second. I've always wanted to do this That's so cool All right, sorry this this stage is amazing as many as amazing To start off I I want to thank Mike and Jameson like it's a real privilege to be able to have all you guys's attention Thank you I Really appreciate you guys and I appreciate the opportunity to be here so today, I'm going to talk about the Frankenstein framework and Where I see kind of a potential future of the web and some changes in the ecosystem that are Really interesting But first we have to talk about the history of the web For my purposes today. I've broken up the web into three separate arrows the document web the hybrid web and the application web With the document web era things were primarily rendered on the server So you made a request to a server it grabbed some sort of static file it rendered that static file Or if the server was particularly smart You made a request to the server it did some dynamic stuff. It sends you back a response Libraries in this era augmented the platform using non-standard monkey patching. So I'm talking Mootools prototype They had really excellent API's but if anyone remembers trying to use like Mootools and jQuery on the same site It was a real nightmare like jQuery added this bougie no-conflict thing where you could like call no conflict and get back a variable But for the most part they didn't they didn't play nice together Libraries in this era leverage plug-in libraries to share code so If you wanted to write jQuery code You had to go to jQuery.com and go to their plug-in library and they had like a Star rating system and 99 out of a hundred times the plug-in was dead I do you guys remember like having to install these really ghetto plug-ins. It was awful It's anything with Mootools you go to Mootools.net and their plug-in system came like way late in the game. You were You were installing these plugins from this weird PHP plug-in repo. It was At the time it was really hot, but but looking back it was a step and Globals were used as a code sharing mechanism people used to at job interviews Test if you understood the immediately invoke function expression like that was really important to understand scoping right So we had no module systems. No way of sharing code We had globals and people talked over globals. There was a lot of clever ways to talk over globals Then the web had sort of an awkward teenage phase at least I call it an awkward teenage phase Sort of the puberty of the web if you will There was the hybrid web things were a single-page app. There was still server-side rendered and they came down with a ton of JavaScript and We called this progressive enhancement We took the document web and we tried to bring it forward into the application web But we couldn't really do it because we were supporting these old browsers, right? So you wanted to use this cool new engaging in experience But you couldn't because you were falling back to an older browser So we called this progressive enhancement. We were sending down gobs of JavaScript and We were bringing the page to the future if you will People were starting to get more serious about JavaScript This is when Ajax started to get popular you could make requests back to the server and grab data It was like this amazing thing and then you could render it into the client-side templates Then the web grew up to the application web and this is kind of where we are today Though I'm going to argue that we're a little bit further ahead than the application web Applications are rendered completely on the client. There are still some remnants of the document web For example, isn't it kind of weird that we send down an HTML document and then build up the whole thing with JavaScript? Like that's sort of a historical artifact more than anything else Applications or JavaScript frameworks in this era provided application architecture So we're talking like backbone ember angular etc. And we were augmenting application structure What are the frustrations of doing a polyglot framework based on this history? There's no good code sharing story So no one can agree on a module system like the module system warfare has been a nightmare If you remember backbone had like AMD support for like two days and then they took it out and some people support common JS and some people are like let's do UMD which is like Just I mean it works, but it's it's a it's a horrific hack There's just no good code sharing story Frameworks require utmost buy-in So my point here is that if you wrote angular code You were writing to and yours module system and if you wrote ember code You were writing to ember and if you wrote backbone code you were writing to backbone So you were coupled to the framework itself. You weren't writing just vanilla JavaScript You were writing code for that particular framework the code publishing story Was pretty bougie if you if you remember we had like this weird these weird plug-and-repose And the issue tracking was like if you want to pile a bug for moutos You go to like this lighthouse issue tracker. There was no standardized issue tracking But things are brewing. I think a polyglot framework is possible today The code sharing story is solved the days of common JS versus AMD versus UMD versus embers weird thing versus sprout cores weird thing Etc. They're gone. We can now depend on the ES6 module format. So we have a common format to share code across these different applications and different libraries The platform itself has changed We now have evergreen browsers so historically we had to augment the web in a serious way We had to like bring the web forward to the future Which is still true, but we now have a different story to do that We no longer abstract the web behind a library or framework We polyfill the web to bring it forward into the future the benefit of polyfills is that if somebody polyfills a promise Multiple libraries can consume that polyfill browser rather than all having to write to jQuery's promises or cues promises The ecosystem itself has changed People take this for granted, but we haven't agreed upon code publishing story which is significant github Fundamentally changed our industry which which people don't consider very often. They just take it This like let's use github, but but we now have a blessed issue tracker We have a blessed way of knowing whether projects that are alive and forking a project NPM officially opens their doors to the browser. This gives us proper versioning semantics for using vendor code We don't have to go download some library put it into like a bougie script tag or worse like some grunt task That's going to concatenate them. We have package manager and Frameworks are compositions of smaller libraries. I don't know how many of you follow Existing like like frameworks probably most of you follow all of them, but The future of these JavaScript frameworks are all compositions of smaller libraries like ember is a composition of smaller libraries Angular 2 is a composition of smaller libraries react itself as a library backbones a library So this means we can start to polyglot the best parts of these frameworks together if if we so choose Which brings me to the Frankenstein the Frankenstein is one attempt at Polyglotting all of these different frameworks into one thing But first we have to bring the past We have to bring the future to the past with our mad developer lab Which brings me to my tooling which today we're going to be using webpack with webpack we have a custom a a Feature called custom loaders and you can think of custom loaders as sort of like a pipe like you take Mario You put him through the pipe and on the other side. He's a different Mario. It's like a bigger Mario, right? He eats that mushroom and he's like, you know, I love games. Sorry Anyways, you guys are you guys okay? All right. All right, like it's like tense out there. Geez stressing me out what a Anyways, you take these your code you take the code from the future if you will ES6 code you put it through this pipe You have the code of today. It's really rad So let's do a quick example of setting up webpack Unfortunately, you guys don't have github But I do if any of you want to follow along. It's just on my github repeat repo We I have this whole tutorial that we're going to go through today So the first thing you do is you install webpack server? Yeah, well, so you make a configuration file. This is what webpack looks for great Great great fetching start So you have this entry This is where webpack is going to go look for your code and then the file that it's going to build is this file called Frankenstein So we got to go make that source Frankenstein file and for now. I'm just going to console log. It's alive So there's this really cool feature with webpack dev server That brings it forward to the application web completely and it'll actually generate a HTML document for you you don't have to like make a stub HTML doc and put your script tag in there So we're now running through webpack. We're console logging. It's alive. We've got our build tool set up This isn't a webpack talk. I think there is a webpack talk though And I highly recommend going to it because webpack is an amazing tool yesterday nice Sorry, I I've been so busy With a certain with another comrades So let's bring to my next tool Babel JS, which gives us ES6 that module format I was telling you about like this blessed module format We have ES6 tools which what we're focused on today is the module system So this gives us important export syntax. We no longer have to write to common JS or AMD, etc We can write ES6 modules. So let's augment our webpack example really quick We're gonna MPM install the Babel loader augment our configuration What this does is it tells webpack everything that's in source Folder that ends with JS run it through Babel Let's make a new folder. I'm sorry. I keep opening these tabs in the tiny so we can use ES6 class syntax here and We export default Frankenstein. So this is how we're gonna export our classes Or our files and inside our Frankenstein. We're gonna import Frankenstein from monsters Frankenstein And then we'll new up our Frankenstein And we're we're alive from ES6. So now we've got The ability to write ES6 modules today and the great thing about webpack is it's flexible enough It's kind of like JavaScript and that it's flexible enough that we can band-aid the current situation we're in So JavaScript itself is the language is awesome Because it's so flexible that we can do all sorts of crazy things to make it more usable for applications so finally We can get to the interesting part. Let's start compositing these frameworks into a polyglot framework Our subjects today are going to be react because it's a wonderful view layer Angular first dependency injector actually in your to first dependency injector and flat iron for routing because it's a very beautiful agnostic router So let's get started with Angular 2 Unfortunately, the stuff isn't out yet. So you have to install these for now. We have to install these pre-versions We install a particular version of Di Again webpack is such a flexible tool that even though Angular 2 is currently implemented with tracer We can get tracer running with webpack using another loader. So we have to install this imports loader So we're telling webpack here when you encounter the tracer runtime install globally the window object because normally you don't have access to that in these modules So we now have a new DI. Let's go ahead and Have DI and instantiate this guy This is how you make a new jet injector in Angular DI You just import it and instantiate it and then you can ask the injector to Create a new object for you So what's really cool about this is we can now use a dependency injector to stub out our modules at test time I don't know if any of you guys have played with Angular 2's DI But it's actually really neat because it uses the actual classes as tokens So it works based on annotations which they're currently involved with TC 39 and standardizing. So hopefully we can We can get that standardized So we don't have to use JavaScript the way that we have to today for annotations because it's kind of gross but Let's go ahead and make sure this is still constructing I gotta restart webpack. I'm sorry and it's alive So we're no longer creating our objects. We have Angular DI creating our objects The cool thing about Angular DI is we're not particularly coupled to the I framework the code can still be run without DI As you can tell with this Frankenstein class We had nothing to do with DI in there, which historically Historically we had to register it with Angular dependency injector But now we can use the classes self as a token for the injector. We don't have to Register it so what's next? React.js By the way, I this whole building the Frankenstein thing I was super stoked about this so I want you guys to appreciate it Thank you This one's easy we install react No configuration needed We can make a new Frankenstein component So since we're using DI, we're gonna be using these factory functions, which Will allow DI to create pass back a component class For a time's sake I'm gonna copy it and paste it and explain it to you. So we import react We import annotations and inject from DI We import Frankenstein and Then this is how we have to do annotations today as opposed to an annotation syntax We tell it to annotate the Frankenstein components and then we inject a new Frankenstein model So then we're gonna print. I am monster dot name But we need to augment our model to have a name So let's go ahead and crack open source monsters Frankenstein, which is our model Nice nice. I try to use them on these things so it looks smart and stuff, but Never goes well now we have to render We have to render this bad boy. So the cool thing is is we can still use react or Angular DI To create our new component So we import react we ask react to render the app into the document body which web active server super rad and We'll give us a document body and now we're rendering react with any or two dependency injector So we have something to wire our code together that allows us to decouple it properly during test time So we can grab Frankenstein and we can new it up ourselves We can grab our component even and knew it up ourselves without the DI Or we can use DI to instantiate things Which we're now on to see I have to go back to the slides because I really want you to see this We're adding the leg of flat iron Flat iron is an awesome library It has a goal being isomorphic we're working on node and the browser for our purposes today we're going to be using this tool called director which is a Really a framework agnostic router which facilitates a lot of the polyglot behavior So again, we have to install it Let's make a new router file So we import director see the cool thing about webpack is even though directors actually a common JS module We can import it with ES6 syntax We grab annotate and inject from DI We grab react we grab our Frankenstein component This is what our old Frankenstein app used to look like right like that main file We used to be rendering but now we're going to render it from a route So we have our router we create our router and in the home route We call react dot render with that component which was injected by angular DI So it's injected up here and it's named here so we could rename this to something else if we wanted And we render to the document body Then our main we're going to do the same thing here. We're going to import router We're just initialize that router. So we see nothing here because we're not on a home route Once we send it over to a home route. We see our app So now we have a framework agnostic router Which is really kind of one of the keys of a polyglot framework because if we want it in a different route to render with A different view layer. It's very straightforward you can see In our router We're calling react our render on the home route But there's no reason in another route. We couldn't call reactive render or angular bootstrap, etc. We can sort of Separate decouple our routes from our rendering layer Which is what people do on a server side level if you think about it when you make a request to a server You some routes could be mapped to different backends and render different ways And that's one of the real powers of routing. So decoupling your router is very useful in a lot of ways And the final leg of our frigate sign framework is polyfills I talked about no longer having to write to libraries to abstract the browser We can now bring the browser forward and all right to the browser platform itself If you've looked at the fetch polyfill It's essentially a nice API for XML HTTP requests. I hate that it's called XML HTTP requests Except for what I'm talking to people who don't know tech because I feel like super super bad a like Saying excellent. It's just sounds a little smart But yeah, so the way that we import the way that we install polyfills is at the beginning of our app We just import it what WG? Fetch and I didn't solve that we do you fetch insults on mouse What WG fetch is a library from github that basically gives us a nicer promised based API for fetching making a synchronous request And you'll see what that looks like in a little bit So again, we import react we import annotate and the concept called inject lazy what inject lazy does is in Angular 2 It lets us it gives us a factory function that we can call to then create an instance of our model So you'll see we get create monster here as opposed to the actual monster instance Angular 2di is really awesome. I really enjoy it So far it's it's handled every case in terms of creating objects that I've needed If any of you have used react this should look really familiar We have a good initial state which just maintains a loaded and then we're gonna make a call out This is that fetch API. We just installed so we just use it and once the browser's all support fetch We take out our polyfill and we're in business Maybe has some subtle changes because certain things aren't standardized yet and we call that a prolly fill I'm not sure which fetch is do you know that it's a polyfill okay, so We make a request out to github which returns response We then return the json object of that response Responses an object that contains like get tax get htl get json, etc Then we call set state, but we create a monster, which is our model factory if you will and In render if it's loaded if it's loading We've just paint loading if it's loaded we paint the monster, but we need to augment our monster really quick To actually take out that to Leverage that response. I know there's a lot of Weird di language in this angular team is like infamous for using really smart words We have a transient scope, which you can think about it's like sort of a sort of a Short-lived object every time it's created. It doesn't get cashed by the dependency injector it gets created every time So every time there's a Frankenstein that's nude up it gets nude up just for that instance It's like the monogamous object So I think I should be like patented or something else good So when you create a Frankenstein take its response set some properties on the object really straightforward So now we're hitting github with the fetch polyfill you have that really charming photo of myself up there and Some stuff from from the internet right we've augmented the platform But we can make this more interesting really easily With the agnostic router We can go in here. We can add a username in our component. We can just paint This stop props a username We're gonna use ES6 template strings so we can interpolate my name the username Then if we go to somebody else's name We get their github account So we have a full stack here, and if you're using react I do recommend flux etc, but That brings me to my next point Is this approach viable? I've thought about this a lot and I'm not certain this approach is viable for a large team primarily because there's no Documentation there's no like stack overflow, you know for the for the oh crap. What's going on here? You're you're effectively taking ownership of your code in a big way where normally you could pass that off to framework authors So I'm not sure this approach is viable, but it is adaptable We have the ability to render different views with different routes We have the ability to swap out a router if we'd like we have the ability to change out our modeling framework for different views Etc. We can lazily load code on routes, and we're not coupled to any particular framework So I do think it's very interesting in that way My goal today was not to sell you on a particular polyglot But to show you that things are happening in the ecosystem between github browsers Standardization etc that you no longer have to think of yourself as a particular framework author You're not an angular developer. You're not a react developer your web developer thinking in terms of frameworks is going to limit your mindset and Your your personal growth and it's going to hurt the future of the web I I believe that people who decide to think outside of framework boundaries are going to influence the web as standardization in a significant way and we really really need that for the future of Humans that's the beauty of the web is that any of us can contribute to the platform in a significant way and Thinking in terms of a framework limits you significantly So thank you guys so much. It's been a privilege to have your attention and thank you Mike I really appreciate the opportunity Long live the open web. Thank you guys