The mess we've made with JavaScript
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Waliński, Kuba
The world of JavaScript Frameworks is constantly evolving. It seems that almost every month there is a brand new thing that will revolutionise web development. However, having a closer look you don’t really see much revolutionary stuff in those new frameworks - they are usually just a small step forward from the previous thing. At least that’s how I felt in the past few years of doing JavaScript. Until I discovered Meteor, that is. It was enough to complete the getting started tutorial to realise that I’m dealing with a potential game-changer. First imagine that all communications happen via web sockets (way faster than REST API calls over HTTP). Then realise that you have a full blown MongoDB implementation accessible on the client side. Finally, remember that from now on you just need one programming language - JavaScript - to implement the whole application - from the client-side through to the back-end and all the way down to the database. In this talk you will see all this goodness brought together in one great package that is called Meteor.
 Okay, hello. Thanks for coming. I think it's been a great conference. I think you all would agree, hopefully. It's been really nice for the past three days. So this is one of the last talks this year. And actually what we're going to talk about is Meteor. That's the title of the session officially. My unofficial title is a bit of a broader look. And it's the mess we've made with JavaScript and why I think that Meteor may actually be part of a solution that we can find out of this mess instead of just another problem that adds to the pile of issues that we've seen with JavaScript recently. But first a few words about myself. Or maybe first even I would ask if anybody was at my talk on Wednesday here. Okay, a few guys. Thanks for coming back. And so most of you haven't been here. So my name is Kuba Wariński. As you can see here, I can be seen on the internet with two faces, the official one on the left and the unofficial one on the right, used mostly on Twitter because it's not too serious channel, at least in my opinion. So if you want to get in touch to discuss Meteor or other JavaScript related stuff or whatever else, you can email me. You can find me on Twitter. You can have a look at all my source and slides from the talks that I do and some of my projects on GitHub. And you can also have a look at my blog. I would really seriously invite you to get in touch after the presentation if you have some feedback. I would very much appreciate it if you shared because it will obviously allow me to be better next time I deliver a presentation at a conference. And also I need to mention that I'm co-organizing Dev Day this year, which is a conference in Poland in Kraków. It will be a fifth edition of this conference this year. We're expanding to two days and we have really good speakers, some of whom you will see or you have seen already here at NDC as well. So I invite you to check this out and maybe come to Kraków in September if you're so fancy. And the website is DevdayPAL, so I encourage you to have a look. Okay, but on to the topic now. So JavaScript, as I hinted at the title of my session, is a bit of a mess now with JavaScript-thrown-it development. But before I discuss why I think that's the case, let's have a look at the history, how we actually got there. So as most of you probably know, there's this legendary tale of how JavaScript was created, which is actually not really a legend, but it's a fact that Brandon and I created it in 10 days in 95. So as you can expect when you do something in 10 days, especially something serious like a new programming language, you might not be able even to make all the good decisions in that time span. Because 10 days come to think about it's not even enough time to think about what you actually have to do, let alone do it. So there's been a case of that, that JavaScript has some problems, dating back to the infancy that have been with JavaScript since the very beginning. And I would say one of the biggest problems at the beginning was the way we manipulated the DOM. The API that was in the browsers was really a pain, so nobody wanted to have anything to do with this. There's a great talk by Douglas Crockford on this, which is called the Inconvenient API, and I really like the title because it was really inconvenient and a pain to use. And it actually, that's how JavaScript initially, I think, got the really bad reputation that it only managed to lose, I think, in the past few years once people realized that there's more to the language than manipulating the DOM that used to be so painful. But the painful manipulation of the DOM actually is what I think what led to the creation of jQuery. And jQuery was a fantastic tool back in the day, and it still is, obviously, but we have some other tools as well. But back in the day, jQuery was really a savior because it turns out you don't have to deal with the DOM anymore. If you know CSS and you know how selectors work, that's all you need, and you know now, and officially, yeah, JavaScript programmer. You can do anything with JavaScript relating to manipulating a website. And that's how jQuery got really good and rapid adoption, very widespread to this day, obviously, and it's still really useful. Although currently with the language, meaning JavaScript, being developed over and over again over the years, there is even a website that says you might not need jQuery.com, which I recommend that you have a look, because it turns out that we just got used to the jQuery syntax, but it's not really necessary anymore, because much of the stuff that jQuery implements is already natively available in the browser, for example, the query selector. But we're still used to jQuery, so it's easier to just put a dollar sign in there instead of writing document.query selector. But in most of the cases, we don't need jQuery actually today, and we can do everything with native JavaScript code, which you could have actually seen today as well on a talk by Pete Smith, who was showing us how to develop framework with JavaScript. A really good talk, and I recommend it. So, yeah, so that was the old days of JavaScript, and then in 2008, the prophet Douglas came, Douglas Crockford, of course, and he wrote the book JavaScript, The Good Parts. It was more or less like he discovered the language anew, and he pointed out that, yeah, so the DOM manipulation is a bit poor, and there are some other parts of the language which you should really stay away from if you don't want to hit the pain points. But there are really some good parts in the language as well, and you can do fantastic things if you just stick to this happy path and use the good parts. And just for reference, this is an image which shows you the complete JavaScript specification and then also the good parts, so you can compare the volume, although it's obviously just a little joke. It's not that bad as it looks when you compare the books. But from then on, from 2008, from the time where we discovered, sorry, we discovered the good parts in JavaScript, there have been a few very interesting developments. One of them obviously is Node.js, so it turned out that we can not only do JavaScript on the front end, suddenly it turns out that we can write also JavaScript at the back end, and we can do full stack JavaScript applications, which is very interesting. Okay. So JavaScript on the front end, JavaScript on the back end, although in this talk I'm going to focus more on the front end and discuss a bit what the current framework situation is looking like, and it's not looking good to my mind at least. It started out really nice, I would say, at least for me, one of the first frameworks, although knockout is not really a framework, it's just a library that does data binding, but you can use it also to do templating and create something like web components as well. So it was the beginning of a route to the frameworks that we use currently, and it was a really promising beginning in my mind, because it was very simple. It had one actually task, the data binding, and it did extremely well to my mind, and I created a few very good, very interesting applications thanks to knockout, and the learning curve was quite all right. It wasn't really a pain. It was quite a pleasure to develop in. Then I jumped to Angular, and I really liked it at first, because when you go through the tutorial, it seems that, oh, it's awesome. So I can do so much, writing so little code. I don't basically have to do anything. The framework does everything for me, but as you go deeper and deeper, as you probably know, as it sometimes happens with such tools, if you go deeper and deeper and you have some specific requirements, it turns out that you suddenly hit a wall, and there's not much that you can do to work around the framework a lot. I'm just pointing out Angular here, because that's what I have experience in, but I've seen blog posts and Twitter entries from people who are also saying similar things about other frameworks. There's also a very good blog post by Rob Ashton, which is called You Have Ruined JavaScript, where he also quite eloquently, as he usually does. He quite eloquently describes why he dislikes AngularJS, while I might not necessarily agree with all his points. I recommend that you have a look, and then you'll be able to have your own opinion. Also quite interestingly, Rob Ashton is also known as the MS-Built hero, because he got his five minutes of fame on the wire internet when the MS-Built was open sourced, and then he submitted the first PR, which said, okay, so I hate MS-Built, so I'm just going to replace it with make. What do you guys think about that? So it seemed that it was funny, but people took it really seriously. So there was a lot of hate that dropped on Rob later on. But actually why I'm mentioning this is because that led to one of my favorite comments ever that I've seen not only on GitHub, but anywhere else probably, and the comment here. So it says, I think GitHub is not the right place for humor. So you should probably remember that next time. If you want to have some fun on GitHub, don't do that. You just have fun on Twitter or anywhere else, because GitHub is not the right place. Yes, so coming back to this, so, yeah, as I say, Angular, I think right now causes more problems than it solves. Angular 1, that is, because as you know, Angular 1 is going to be deprecated soon. At the timeline, it's a bit about two years after Angular 2 was released. So right now it seems unwise to do something, some new development in Angular 1.3 or 1.4. And there's a bit of a wrestle amongst front-end developers where everyone is trying to figure out what to do next, the people who are invested in Angular so far. Because Angular 2 is also not out yet, so they're left without a viable option. Yeah, so coming back to Rob Ashton again, the guy really has a thing for Angular. He was last year at the conference and he was giving a talk on React and NPM, as you can see, but the closing slide was friends.don't let friends use Angular. So again, if you want to read why, I recommend this blog. So, yeah, so we got Angular, but then JavaScript got really popular, immensely popular right now, as you probably know. It's the most popular language, I mean, language in the world. And with that popularity, we got problems like more frameworks. So currently, I think the most notable ones are React and Angular 2 and Aurelia that are still in development. But there's just so many other that we probably, most of us, didn't even hear of because they didn't gain any significant traction. But there were some blog posts written, people got interested, people tried them, then they got discouraged, and then turned out that they didn't gain any significant adoption. So that was a bit of a pain, especially I think the culmination point I think was sometime last year, at least to my mind. There was a lot of frameworks, and everybody actually complained about that, being included. But then I read this blog post, and it was a bit refreshing actually to read because the author says that, okay, so we have lots and lots of frameworks, but we're actually in a knowledge-based industry, so it shouldn't be a problem for us. That's our job to learn and have a look at what's going on out there. So he's okay with that, we have a lot of frameworks, because the more frameworks we use and the more frameworks we know, the better we are as developers, and we can do better solutions, deliver better solutions for our clients, also get paid more. Which is obviously true as well. Although I would argue that there actually is a limit to how much you can learn in a short amount of time. And I think this limit was actually abused in terms of the JavaScript frameworks that we've seen in the past few years. And one guy that agrees with that point is Jimmy who wrote this blog post about the state of JavaScript in 2015. So that's how I also realized that maybe 2014 was the tip of the iceberg in terms of JavaScript frameworks. So he summed up what happened in 2014 and also came to the conclusion, so man, we have too many frameworks, we don't know how to do front-end development anymore, there's so many alternatives. The choosing of the right one is such a pain. So he foresees that in the future, in 2015 and onwards, people might get discouraged by using any frameworks and they'll just use a little library here, a little library there, try to put them together. So then if something goes wrong with the library, you just can plug it in, plug it off and plug in something else without much pain, certainly with less pain than if you were to replace the whole framework because this is basically usually impossible. If you want to change the framework, you have to write the application from scratch, which obviously takes a lot of time. So with that in mind, that reasoning brought me to have a look at Meteor because I learned that Meteor is actually composed of small independent libraries, that the authors develop independently and you can use them even outside of the Meteor framework. You can theoretically plug in some of your libraries in place of the Meteor ones if they satisfy some criteria. And Meteor, to me, is somewhat similar to Ruby on Rails because it's also a full stack framework and it's actually, I think it's better in a few aspects, better from the point of view obviously of a JavaScript developer and it's better because it's written in JavaScript and the JavaScript is on both ends of your application, so on the backend and on the front end. Whereas in Ruby on Rails, obviously, you have Ruby on the backend and then you have JavaScript or CoffeeScript at the front end. So this is a really big advantage that we might sometimes neglect, I think, the one language because it means that you have a lot less problems when you have to work on some backend code and then switch to the front end code because you still have one language in mind, whereas when you have separate languages, there's some context switching that needs to occur and I actually heard some stories of people working in such environments. For example, with C-Sharp and JavaScript, then when they switch, they just use wrong keywords, et cetera, because those are subtle differences and then you look at your code and you don't see why it's not compiling and suddenly you click and you realize that you're trying to define an int in JavaScript, which it obviously doesn't have, at least the keyword. So this is one of the things that I think could make you super productive when you use Meteor and certainly it made me more productive when I tried and when I developed applications with this framework. One thing that I think makes Meteor really stand out is the fact that it's reactive. And the reactive I know it's a bit of an overloaded term lately, at least in software development with the reactive manifesto, so it can have different meanings, but what actually reactivity means in terms of Meteor, it will be better if I show you during the demo. So I'm going to close that. Okay. So to start off, nice and clean, I will just show you how you create a new application with Meteor. You have a command line that you can install. If you're a Linux or OS 10, you install it through the command line by downloading a script that installs it for you. On Windows, you have an installer provided. Yes, so we're going to do Meteor create new app. And it fetches some basic skeleton for an application for us. And it's been added as a folder here. And I'm going to show you what the basic application looks like. So we have an HTML file. As you can see already, we have some templating engine here. It's based on handlebars, but it's a bit modified for Meteor. And it's called spacebars. So in here, in the body, we'll be inserting a template, which is called hello. That's the syntax that you use with the greater than symbol. And the template is actually defined below with the template tag that's part of the web component specification that's getting really popular in the JavaScript world lately for templating engines. And inside here, you can also see that we have a variable code called counter defined that will be displayed. So if we want to run it, we just write Meteor on the console. But first, as it actually suggests here, first I got to obviously have to go into the folder that was created. Now I type Meteor. Okay. So I still have Meteor running from the preparations on another application. So I had to close that. Now I go to new app. Okay, sorry. New app Meteor. Yeah. So now we're starting the development server. And I can actually, once it's ready, I can go to the browser to localhost 3000. That's the default port. And we have the standard Meteor application that you get out of the box when you want to start developing. It's nothing more than a button that you can click. And it counts how many times you clicked it. So let's have a look at JavaScript that's behind this. And the JavaScript that is behind is actually working on the session as you might imagine. So on the session, we have a variable that's called counter. And whenever the button is clicked, it's incremented. And in this counter variable here, where does it come from? You can have a look here. And you see that for a template that's called hello, we define some helpers. And helpers are shorthand for variables of things that you can actually use in the template to bind to. And counter is actually just getting the counter variable from the session. So that's how it's all joined together. And then you can also, for the hello template, you can also specify events. And you specify them using query selectors. So that's where you say what event you're talking about. And then you specify the selector on which this event is supposed to be triggered. So whenever we click a button, the session counter is incremented. And one more thing that we see in this basic code is we have those meteoris client and meteoris server. And that's quite interesting. Because as I mentioned, meteor is a full stack framework. So your JavaScript runs both on the server and on the client by default. Unless you specify with this if statement or you put your files in a certain director, which I will go to in the next demo. But you can also do it like that. So you can specify that this runs on the client and this runs on the server. Actually, in this case, nothing runs on the server. It's just the client side up because it uses the browser session. So there's no need to contact the server for anything. So now if I go here, I will show you that we can interact with this. We can interact with this application a little bit. Can you see the code in the template here and the console here? Or should I enlarge it? It's okay. Okay. So, yeah, let's have a look at this code and let's have a look how we can play with it. Yeah, so as you can see, we have this counter on the session. And I'm actually going to copy that. And I'm going to try to set it from here, which might seem like a weird idea. But this will demonstrate and I'll enlarge that. So as you can see, I've run the code, session set counter 13, and it got automatically updated on the website. And this is the first time that you see the reactivity that I was talking about. So this code in the console was a simulation of any external thing that could happen to the application. Whenever something changes in the session, session is one of the reactive data sources. So whenever it changes, it notifies everyone who wants to read the session that it changed. So in this case, I changed the counter to 13. The session noticed the new value and it notified the HTML template that, hey, there's a new value. So, and you asked for it before. So now you, here is the new value, you probably want to do something about it. And the HTML template rendered the template again. What's interesting as well for Meteor and for this development environment is that it has a life reload as you'd imagine. So when I change something in the code, it reloads automatically, but it's also quite smart because I have a look now. So I have this, you've pressed button 13 times. I'm going to press F5 and the state is obviously reset. The session is reset for this application and we start from scratch and I can do all this again. And then run the code and set it to 13. So now I'm going to set it side by side with the code editor. And let's say I'm going to go here and change something in the template or in the JavaScript, doesn't matter. I saved it. It's now reloading here. And you can see it changed the header to welcome to NDC, but also it didn't reset the counter. And that's quite interesting because it allows you to do a life reload. But while preserving the state, the session and all the other state of the application, it's quite smart because what it does is when it receives a notification from the server or from anywhere else that some new data came in or even there might be some new JavaScript code, you could actually send a patch to an application that you already have in production and people are using it right this very moment. They're logged in and they're doing something and you have a new version coming in, some new code that you have to deliver. So the client side of your application then receives this information that there's something new that has to be released. Saves all the local state and session, et cetera, in the browser, in local storage, yeah, I was missing the word, in local storage, so in some stores that you have in the browser that you can use. So it saves that, reloads the application and loads back the state. So that makes the deployment, as you can imagine, pretty easy and certainly easier than it was before and you might even have zero downtime deployments which is pretty cool. Okay, so that's what you get from the standard template that you get with each media application that you create, but I also have a bit of a more complex example. So I'm going to switch to this one now, close the media server that's running here. I'm going to go into the ndc folder where I have the application prepared. I'm going to run it. Okay, the application started and the application is a simple case of an update that lists some notes that I took while attending ndc this year. So I learned so far that web development in 2020 is going to be pretty cool and that I learned on Steve Sanderson's session, which I really, really, really recommend if you haven't seen it. I also learned, as I mentioned, from Pete Smith's session that you might not need a framework because you can write it on your own in the vanilla JavaScript. And I also learned throughout the conference that I probably should start using Docker. Yeah, so just a few notes that I took and let's see how the code looks like. So I have some really basic HTML as you saw with some template in here to actually iterate through the notes collection. So for each note, I'm just displaying the text of the note in the list, so pretty basic stuff. So let's see how, what else we've got here. I'm going to zoom in because you probably can't see that here. It's the organization of my source code that's quite interesting because I mentioned that you can use the media or its client and media or its server in your code to figure out what's going to run on the client and on the server. But you can also use some pre-fined directories in here. So everything that goes into the client directory will be run on the client. Everything in the server directory, obviously, will be run at server. There is also a special lib directory for libraries. And you have a guarantee that everything that's in the lib directory will be run first. So you load there all the dependencies that you need to have accessible. For your own code. So, yeah. So in this, in the client, I have defined a notes helper for the template. And this is the notes here that are iterated over to display the text. So I say that notes is just a notes collection. And I'll show you where the collection is defined in the moment. And it's a MongoDB collection. And there's a finds method on it that you can use to just bring the whole collection to the client side. And the notes collection is defined here in the lib directory. So it's available everywhere. And it's loaded as one of the first things with your application. And as I mentioned, media uses Mongo. And it uses Mongo, interestingly, both on the server, which is not surprising, but it also has a Mongo implementation that you can use on the client. And those two Mongo instances keep themselves in sync automatically for you. So when you add something to the client, it's automatically synced to the server. And then it can even be automatically synced to other instances of your application that are running out there. And to populate this, this notes collection in the server folder. So on the server side, I've added just this basic code to insert those three notes that you have seen on the website when I started it. So now I'm going to use the console again to insert something else. And we'll see how that works. So I just have notes insert and enter the text. Media is cool. Run that. And obviously, it got added to the collection as you see and displayed on the website. But that's something we've already seen. So there's nothing really dramatic going on here, but I'll now run it in two browsers so that you can see that it actually syncs like I told you. So I'm going to insert media or school again into here, into the left browser and you can see that it will actually automatically appear in the right browser as well. Which, and it was pretty fast obviously because it's running on local host. But what's pretty mind blowing to me and pretty awesome is how it actually works. Because what it does is by executing the notes insert, I'm talking directly to the client side Mongo implementation. And I'm pushing the data directly to the database on the client side. And what happens then? The Mongo instance notifies the template of the left side browser that hello, there's new data you need to update and it updates later on. But it also notifies the server side Mongo that I have new data and you probably have to sync it as well. So the server side Mongo syncs it. Server side Mongo notifies the client Mongo on the right hand side browser that hello, new data so you need to sync. So the client side on the right syncs and the client side on the right notifies the template on the right that hello, new data so you need to display it. So as you see there's quite a lot going on under the hood and you actually don't have to worry about it. You know that all your data is available on the client and you can count on it that it's always there and always syncs automatically for you. But obviously if you think about it a bit more, you might think that hmm, what the actual hell? What do you mean my whole database is available on the client? And everyone can just insert something into the database by fiddling with the console that doesn't sound right. And I agree. Obviously there are at least two major issues that you can think of. Security. So you don't want people to be able to fiddle with your database just by opening the F12 console tools. And also performance because if your database is quite big, you don't want to push it all to the client if it's like 100 megs or so. So obviously there are ways in Meteor that you can deal with that. And obviously you have to deal with that because it will be unacceptable to release an application that exposes the database on the client side because it's not a secure environment. So what you can do, let's tackle the security first. Why I was able to insert this data from the console just without any restrictions is that when you start developing with Meteor to make sure that it's as easy as possible for you to get started, there is an insecure package that it's added. And the insecure package, generally there are packages in Meteor that you can add that there's a repository for them as well, which is called Atmosphere. That's what I should have started with. But one of the packages that you can get out of the box is an insecure package which just says that everybody can do everything to the database, which is really cool when you start developing because you don't have to care about this and all this stuff and you can start developing pretty quickly. But once you want to release the application, you should probably actually go into your console and type Meteor Remove Insecure. Now I've removed the insecure package. And let's see what if something will actually change. So I will just maximize that. So I want to add Meteor as cool again. But as you can see here, now I actually said insert fail because my access is denied. Because when you remove this package, all access from the client side is denied. And you can only modify the database on the server side. But if you want to still continue to be able to add something from the client side, one option that you can use is you can define permissions explicitly. So we can say that for the notes collection, I allow inserting. If the text of the document that you want to insert is I like Meteor. So let's try that. I'm going to copy this. Okay. Yeah. I refreshed because I uncommented this code. So I'm going to copy I like Meteor and insert it okay. But the moment I just add something in here like an exclamation mark, it won't add it and it will tell me again that my access is denied because it didn't fit any rules in here. Obviously you can also, when you have an insecure package, it's somehow as if you were to put return through in here. But you'll notice that you also have a user ID in here of the user that wants to do the insert. So when you have some user management, you can also figure out, look in your database to the permissions table, figure out who's able to do what. So you can control this pretty much in any way you need. So that's one consent that I've dealt with. The security, but then we still have the performance issue. We don't want to publish the whole database to every client that connects. So what can we do about that? It turns out there's actually another package that's included out of the box to ease the development. And the package is called auto publish. If I can spell it correctly, auto publish. Yeah. So it's also included out of the box and it publishes your whole database to the client, which is great if you just want to quickly develop something and hack something together. But then the time comes when this is no longer an option because you're still going to be deploying this application. So you remove that and you go to your website and nothing appears because nothing is published. So now when you remove this package, you have a standard publish subscribe situation going on here. So on the server, you have some code that you says that from the notes collection that I already have in there somewhere, I want to publish everything. So I just say notes find and leave it empty, but you could obviously provide some Mongo query option here. And just for example, obviously one of these choices is to only publish the data that belongs to the current user because there's no need for him to have other users data synced on this client machine. So that's what you do on the server. And on the client as well, you have to subscribe to be able to receive the data from the notes collection. So once we've done that, I go back to the website and fortunately all the data is still there. And we, as you can see, we can have some tight control over what actually gets automatically synced between the client and the server. So it's really useful, the syncing I mean, but you can also control it quite well and make sure that you actually know what's going on and who has access to what because it's pretty important, obviously. And one last thing that I want to show you in the demo is one of the major features and major selling points for Meteor and it's called latency compensation. It's a cool idea. In theory it says that, okay, so we've got the code that runs on the client and on the server. We know what code runs where we have a database on the client and most of the stuff that we go to the server usually involves dealing with the database. And this is where the latency comes from because we have to wait for the response and then the user sees the spinner and waits. But if we have everything on the client, let's execute the code on the client and try to figure out what will happen. And that's what happens in Meteor and I will demo it in a moment. But what happens is Meteor updates the client immediately and changes the template as well. So displays the state that would happen most probably if everything goes okay and then goes to the server and if the server has a different response then the UI is updated. So in order to demo this, I'll show you some code. And this is what's called a Meteor method. It's a way to modify the data on the server side and you can call it from the client side. And what I'm doing here is I'm inserting the text, appending the text server to the message that I will enter in the moment. So if I'm executing this code on the server, I'm appending server to it and waiting for three seconds. But if I'm running it on the client, I'm appending the client in parenthesis and not waiting. So what you see will happen here, when I use this method in the moment, it will immediately appear in the browser with the word client appended and after three seconds the server will send its response and will be corrected. So let's have a look at that and we'll actually have a look at that again in two browser windows. So add notes was the name. Add notes, okay. So I'm going to go ahead and add a message with the text test and yeah, let's see the other browser too. So it appeared on the left for three seconds and then it appeared on the right as well and on the left it was corrected. So that's exactly what you have, what I told you and what you can see in this code. Another thing we can try is forbid the insert of the server completely on the server and also causes an interesting situation here on those browsers because the neural note will appear for three seconds on the left and it will be removed because the server forbid the insert and it won't appear at all obviously on the right hand side browser because it wasn't synced from the server because the data never appeared on the server. Yeah, so that's about it although we have some time left fortunately so I'll show you one more feature that's really useful for Meteor. When you develop a Meteor app you have an option to deploy it for free under the meteor.com subdomain and that gives you some really cool things that you can do because you can without paying for any hosting without having to configure absolutely anything you can just deploy it to subdomain.meteor.com from your command line and you do it like that. Meteor deploy and DC Oslo 2015, hope it's not taken. And DC Oslo 2015. Okay and now it's gonna ask me probably for an email or maybe I will remember the one I entered last time, it's probably will. And so it's building it and it will sync it to the meteor.com domain and you get some reasonable amount of database space in there so it should be enough for you to demo it to the client to show it off to your colleagues as well if you need to. We'll let it run for a moment and in the meantime I'll open it in the browser. Not there yet. Yeah but to my mind while I'm gonna talk a bit while we wait for this to finish so let's go back to the presentation. In my mind this deployment thing is pretty cool as well because as I said it requires no effort on our part just one command line that one command that you have to enter in your console and you're done and you can show it off to the world. Yeah so while I wait for the deploy to finish it might be difficult on this Wi-Fi because I will see it's been good so far today. There are actually seven basic principles that the Meteor team proclaim and that they work on and they base they work on and I would like to just let you know what those principles are at the end because to me they make a lot of sense. So as you saw all the updates and all the actions that happen all the interaction between the server side and the client side is pretty quick and it's thanks to the fact that those aren't HTTP calls like REST API calls and something like that. This is happening through web sockets and it's only pure data that's transferred between the client and the server. It's just data usually between the MongoDB implementations and then everything happens on the client automatically, they're all the syncing and notifying the templates etc. So that's why it's pretty quick. So it will be certainly quicker than your standard SPA application at least to the user. It will feel as if it's a native app that he runs on his desktop. One language as I mentioned so you have JavaScript everywhere even in the database because MongoDB actually holds JSON objects and you query with a JavaScript syntax so there's no context switching and it can be super productive. The database is everywhere as you already seen and it syncs automatically. Latency compensation that I demonstrated so you can see the framework simulates what will happen on the client and in 99.9% of the cases it's right so then the user doesn't even notice that there has been a simulation on the client because the server actually performs the same and there's nothing, no corrections that you have to do so I would say it's a good idea to optimize for those 99% of the cases because it's a great experience for the user. You've got this reactivity that I mentioned so the reactivity is the fact that everything auto updates because each part of the framework is able to realize that okay something changed with me so I need to notify everybody else who was asking for my value so that template or the database or whatever else needs to be updated. And finally there's a really good ecosystem around Meteor that includes some open source tools, the whole of Meteor is obviously open source as well. There are those packages that I mentioned as a whole collection of them and the community is creating their own packages and there's a lot of people interested and involved. There's a lot of ways that you can get help also some ways that you can contribute that you can read on at Meteor.com if you're interested. And this is the code that I really like. It says that the best way to make something seems simple is to have it actually be simple and that's how I felt that it really Meteor I think delivers on this promise. It also seems really simple when you develop there's not much places where you have to scratch your head and try to figure out what actually the framework is doing and why it's done like that. So those seven principles are really you can really see them. It's not just words that they came up with the marketing department or somebody else and they've put them on the website. It's what you can see on the actual tool. Yeah, so here are some resources that you can have a look at. And in the meantime though we'll have a look if it deployed. Yeah, okay, so it deployed. It also just tells me that I can set up a password to manage my deployments to Meteor.com but I'm not going to do that now. I'm just going to refresh it here and you can see that my application is in there. I can now go in and to the console and play with it like I did with the previous one. Okay, coming back to slides and the resources that I recommend. The first one is the slides and the code from this very presentation if you want to have a look. Then I recommend if you're interested to go to meteor.com. Install when you have the installation instructions and then if you proceed, actually you have to have a look at that. So yeah, so you have some instructions how to install it on Windows, how to install it on OS X or Linux. And then if you continue to the tutorial you have a 12 steps tutorial that I really recommend. It will take you like 45 minutes up to an hour and it covers a bit more stuff that I was able to get into. It covers for example running Meteor web applications as native mobile applications on mobile thanks to using Apache Cordoba which is quite cool. And a few other things. So I really recommend because as soon as you play with it you get your hands dirty with code. You will have an even better understanding of what Meteor is all about and what it can give you. Then there's also really good documentation on meteor.com that I recommend. And you can also read about the individual projects, the libraries that Meteor is composed of on meteor.com slash projects. There's a really good resource as well to learn which is the Discover Meteor book. Which is kind of like a Bible for Meteor at this point. And you can buy it here and you can also read the blog which is really good. And there's also a book called Meteor in Action by Manning which is in early access now. But it's almost, I think it's about 80% there. Or even more as you can see. All the parts are available so they're just working on some final fixes. So I really recommend this book. And yeah, and that's it. So thanks very much for your attention. I hope I managed to convince at least some of you to give Meteor a try. And I'll be happy to answer any questions. In the meantime my assistant also distributed some Meteor stickers here. So if you want to grab one, feel free. Yeah, so as I said, questions. And when you leave the room also please remember to rate my session. Questions? Yeah? Is there a way to write modules or isolate variables because all we saw was strings and sessions. Is there a way to create more structure to provide data models within the application or just sessions? Yeah, the question is if there is a more structureized way to manage your data inside JavaScript code because what we saw was only the session. Yes. So this is just JavaScript, right? So you can do basically whatever you want. It's a bit unfamiliar at the beginning because what Meteor does is it looks at all the JavaScript files that you have in there and just merges them into one. And that's why you have to control the order in which they are merged. That's why you have this lib folder where you can put some code that is, you have got guaranteed it will be executed first. So if you have some data hierarchy that you want to make sure is available to everywhere else, you would for example put it there. But you can, you are free to design it however you want. There is not much restrictions that Meteor enforces on you. Yeah? My other question is how do you handle the dependencies within the lib folder? Do you have the possibility to post that? Yes, far as I remember, the question is I'll repeat for the recording as well. The question is how do you manage the dependencies inside the lib folder if you want to still control? As far as I remember, it's alphabetical. So you might have to do some hacks and enter A to the beginning of the file name. Yeah. But you still have control over it. My other question is about unit testing. Can you integrate easily with a Opera, JavaScript testing framework? Yes, you can. And there is also a built-in tool for testing in Meteor although I have to admit I have not tried it yet because I was also giving a talk on unit testing and I'm just, I'm using some other tools for that and you can obviously use them as well here like Karma, Jasmine, whatever. Yeah? What is the server, the HTTP server running Meteor and can you change for instance the headers and everything? The one that you see in development, that's probably just something from Node. I don't know exactly what but obviously you shouldn't use that in production I think. By the way, I'm happy to answer more questions. You don't have to be shy. I'm happy that you're interested. But yeah, so in production what you will probably do is some other server as a proxy that will just forward the Meteor calls to your Meteor instance and the proxy server like NGINX or something else would that handle all the HTTPS and stuff. Okay, any more questions from anyone? It's not been. Thanks very much. Enjoy your last session of the conference and enjoy the party as well afterwards. Thanks.
 Okay, hello. Thanks for coming. I think it's been a great conference. I think you all would  agree, hopefully. It's been really nice for the past three days. So this is one of the  last talks this year. And actually what we're going to talk about is Meteor. That's the  title of the session officially. My unofficial title is a bit of a broader look. And it's  the mess we've made with JavaScript and why I think that Meteor may actually be part of  a solution that we can find out of this mess instead of just another problem that adds  to the pile of issues that we've seen with JavaScript recently. But first a few words  about myself. Or maybe first even I would ask if anybody was at my talk on Wednesday  here. Okay, a few guys. Thanks for coming back. And so most of you haven't been here.  So my name is Kuba Wariński. As you can see here, I can be seen on the internet with two  faces, the official one on the left and the unofficial one on the right, used mostly on  Twitter because it's not too serious channel, at least in my opinion. So if you want to  get in touch to discuss Meteor or other JavaScript related stuff or whatever else, you can email  me. You can find me on Twitter. You can have a look at all my source and slides from the  talks that I do and some of my projects on GitHub. And you can also have a look at my  blog. I would really seriously invite you to get in touch after the presentation if  you have some feedback. I would very much appreciate it if you shared because it will  obviously allow me to be better next time I deliver a presentation at a conference.  And also I need to mention that I'm co-organizing Dev Day this year, which is a conference in  Poland in Kraków. It will be a fifth edition of this conference this year. We're expanding  to two days and we have really good speakers, some of whom you will see or you have seen  already here at NDC as well. So I invite you to check this out and maybe come to Kraków  in September if you're so fancy. And the website is DevdayPAL, so I encourage you to have a  look. Okay, but on to the topic now. So JavaScript, as I hinted at the title of my session, is  a bit of a mess now with JavaScript-thrown-it development. But before I discuss why I think  that's the case, let's have a look at the history, how we actually got there. So as  most of you probably know, there's this legendary tale of how JavaScript was created, which  is actually not really a legend, but it's a fact that Brandon and I created it in 10  days in 95. So as you can expect when you do something in 10 days, especially something  serious like a new programming language, you might not be able even to make all the good  decisions in that time span. Because 10 days come to think about it's not even enough time  to think about what you actually have to do, let alone do it. So there's been a case of  that, that JavaScript has some problems, dating back to the infancy that have been with JavaScript  since the very beginning. And I would say one of the biggest problems at the beginning  was the way we manipulated the DOM. The API that was in the browsers was really a pain,  so nobody wanted to have anything to do with this. There's a great talk by Douglas Crockford  on this, which is called the Inconvenient API, and I really like the title because it was  really inconvenient and a pain to use. And it actually, that's how JavaScript initially,  I think, got the really bad reputation that it only managed to lose, I think, in the past  few years once people realized that there's more to the language than manipulating the  DOM that used to be so painful. But the painful manipulation of the DOM actually is what I  think what led to the creation of jQuery. And jQuery was a fantastic tool back in the  day, and it still is, obviously, but we have some other tools as well. But back in the  day, jQuery was really a savior because it turns out you don't have to deal with the  DOM anymore. If you know CSS and you know how selectors work, that's all you need, and  you know now, and officially, yeah, JavaScript programmer. You can do anything with JavaScript  relating to manipulating a website. And that's how jQuery got really good and rapid adoption,  very widespread to this day, obviously, and it's still really useful. Although currently  with the language, meaning JavaScript, being developed over and over again over the years,  there is even a website that says you might not need jQuery.com, which I recommend that  you have a look, because it turns out that we just got used to the jQuery syntax, but  it's not really necessary anymore, because much of the stuff that jQuery implements is  already natively available in the browser, for example, the query selector. But we're  still used to jQuery, so it's easier to just put a dollar sign in there instead of writing  document.query selector. But in most of the cases, we don't need jQuery actually today,  and we can do everything with native JavaScript code, which you could have actually seen today  as well on a talk by Pete Smith, who was showing us how to develop framework with JavaScript.  A really good talk, and I recommend it. So, yeah, so that was the old days of JavaScript,  and then in 2008, the prophet Douglas came, Douglas Crockford, of course, and he wrote  the book JavaScript, The Good Parts. It was more or less like he discovered the language  anew, and he pointed out that, yeah, so the DOM manipulation is a bit poor, and there  are some other parts of the language which you should really stay away from if you don't  want to hit the pain points. But there are really some good parts in the language as  well, and you can do fantastic things if you just stick to this happy path and use the  good parts. And just for reference, this is an image which shows you the complete JavaScript  specification and then also the good parts, so you can compare the volume, although it's  obviously just a little joke. It's not that bad as it looks when you compare the books.  But from then on, from 2008, from the time where we discovered, sorry, we discovered  the good parts in JavaScript, there have been a few very interesting developments. One of  them obviously is Node.js, so it turned out that we can not only do JavaScript on the  front end, suddenly it turns out that we can write also JavaScript at the back end, and  we can do full stack JavaScript applications, which is very interesting. Okay. So JavaScript  on the front end, JavaScript on the back end, although in this talk I'm going to focus more  on the front end and discuss a bit what the current framework situation is looking like,  and it's not looking good to my mind at least. It started out really nice, I would say, at  least for me, one of the first frameworks, although knockout is not really a framework,  it's just a library that does data binding, but you can use it also to do templating and  create something like web components as well. So it was the beginning of a route to the  frameworks that we use currently, and it was a really promising beginning in my mind, because  it was very simple. It had one actually task, the data binding, and it did extremely well  to my mind, and I created a few very good, very interesting applications thanks to knockout,  and the learning curve was quite all right. It wasn't really a pain. It was quite a pleasure  to develop in. Then I jumped to Angular, and I really liked it at first, because when you  go through the tutorial, it seems that, oh, it's awesome. So I can do so much, writing  so little code. I don't basically have to do anything. The framework does everything  for me, but as you go deeper and deeper, as you probably know, as it sometimes happens  with such tools, if you go deeper and deeper and you have some specific requirements, it  turns out that you suddenly hit a wall, and there's not much that you can do to work around  the framework a lot. I'm just pointing out Angular here, because that's what I have  experience in, but I've seen blog posts and Twitter entries from people who are also saying  similar things about other frameworks. There's also a very good blog post by Rob Ashton, which  is called You Have Ruined JavaScript, where he also quite eloquently, as he usually does.  He quite eloquently describes why he dislikes AngularJS, while I might not necessarily agree  with all his points. I recommend that you have a look, and then you'll be able to have  your own opinion. Also quite interestingly, Rob Ashton is also known as the MS-Built hero,  because he got his five minutes of fame on the wire internet when the MS-Built was open  sourced, and then he submitted the first PR, which said, okay, so I hate MS-Built, so  I'm just going to replace it with make. What do you guys think about that? So it seemed  that it was funny, but people took it really seriously. So there was a lot of hate that  dropped on Rob later on. But actually why I'm mentioning this is because that led to  one of my favorite comments ever that I've seen not only on GitHub, but anywhere else  probably, and the comment here. So it says, I think GitHub is not the right place for  humor. So you should probably remember that next time. If you want to have some fun on  GitHub, don't do that. You just have fun on Twitter or anywhere else, because GitHub is  not the right place. Yes, so coming back to this, so, yeah, as I say, Angular, I think  right now causes more problems than it solves. Angular 1, that is, because as you know, Angular  1 is going to be deprecated soon. At the timeline, it's a bit about two years after Angular 2  was released. So right now it seems unwise to do something, some new development in Angular  1.3 or 1.4. And there's a bit of a wrestle amongst front-end developers where everyone  is trying to figure out what to do next, the people who are invested in Angular so far.  Because Angular 2 is also not out yet, so they're left without a viable option. Yeah,  so coming back to Rob Ashton again, the guy really has a thing for Angular. He was last  year at the conference and he was giving a talk on React and NPM, as you can see, but  the closing slide was friends.don't let friends use Angular. So again, if you want to read  why, I recommend this blog. So, yeah, so we got Angular, but then JavaScript got really  popular, immensely popular right now, as you probably know. It's the most popular language,  I mean, language in the world. And with that popularity, we got problems like more frameworks.  So currently, I think the most notable ones are React and Angular 2 and Aurelia that are  still in development. But there's just so many other that we probably, most of us, didn't  even hear of because they didn't gain any significant traction. But there were some  blog posts written, people got interested, people tried them, then they got discouraged,  and then turned out that they didn't gain any significant adoption. So that was a bit  of a pain, especially I think the culmination point I think was sometime last year, at least  to my mind. There was a lot of frameworks, and everybody actually complained about that,  being included. But then I read this blog post, and it was a bit refreshing actually  to read because the author says that, okay, so we have lots and lots of frameworks, but  we're actually in a knowledge-based industry, so it shouldn't be a problem for us. That's  our job to learn and have a look at what's going on out there. So he's okay with that,  we have a lot of frameworks, because the more frameworks we use and the more frameworks we  know, the better we are as developers, and we can do better solutions, deliver better  solutions for our clients, also get paid more. Which is obviously true as well. Although  I would argue that there actually is a limit to how much you can learn in a short amount  of time. And I think this limit was actually abused in terms of the JavaScript frameworks  that we've seen in the past few years. And one guy that agrees with that point is Jimmy  who wrote this blog post about the state of JavaScript in 2015. So that's how I also realized  that maybe 2014 was the tip of the iceberg in terms of JavaScript frameworks. So he  summed up what happened in 2014 and also came to the conclusion, so man, we have too many  frameworks, we don't know how to do front-end development anymore, there's so many alternatives.  The choosing of the right one is such a pain. So he foresees that in the future, in 2015  and onwards, people might get discouraged by using any frameworks and they'll just use  a little library here, a little library there, try to put them together. So then if something  goes wrong with the library, you just can plug it in, plug it off and plug in something  else without much pain, certainly with less pain than if you were to replace the whole  framework because this is basically usually impossible. If you want to change the framework,  you have to write the application from scratch, which obviously takes a lot of time. So with  that in mind, that reasoning brought me to have a look at Meteor because I learned that  Meteor is actually composed of small independent libraries, that the authors develop independently  and you can use them even outside of the Meteor framework. You can theoretically plug in some  of your libraries in place of the Meteor ones if they satisfy some criteria. And Meteor,  to me, is somewhat similar to Ruby on Rails because it's also a full stack framework and  it's actually, I think it's better in a few aspects, better from the point of view obviously  of a JavaScript developer and it's better because it's written in JavaScript and the  JavaScript is on both ends of your application, so on the backend and on the front end. Whereas  in Ruby on Rails, obviously, you have Ruby on the backend and then you have JavaScript  or CoffeeScript at the front end. So this is a really big advantage that we might sometimes  neglect, I think, the one language because it means that you have a lot less problems  when you have to work on some backend code and then switch to the front end code because  you still have one language in mind, whereas when you have separate languages, there's  some context switching that needs to occur and I actually heard some stories of people  working in such environments. For example, with C-Sharp and JavaScript, then when they  switch, they just use wrong keywords, et cetera, because those are subtle differences and  then you look at your code and you don't see why it's not compiling and suddenly you click  and you realize that you're trying to define an int in JavaScript, which it obviously doesn't  have, at least the keyword. So this is one of the things that I think could make you  super productive when you use Meteor and certainly it made me more productive when I tried and  when I developed applications with this framework. One thing that I think makes Meteor really  stand out is the fact that it's reactive. And the reactive I know it's a bit of an overloaded  term lately, at least in software development with the reactive manifesto, so it can have  different meanings, but what actually reactivity means in terms of Meteor, it will be better  if I show you during the demo. So I'm going to close that. Okay. So to start off, nice  and clean, I will just show you how you create a new application with Meteor. You have a  command line that you can install. If you're a Linux or OS 10, you install it through the  command line by downloading a script that installs it for you. On Windows, you have an installer  provided. Yes, so we're going to do Meteor create new app. And it fetches some basic  skeleton for an application for us. And it's been added as a folder here. And I'm going  to show you what the basic application looks like. So we have an HTML file. As you can  see already, we have some templating engine here. It's based on handlebars, but it's a  bit modified for Meteor. And it's called spacebars. So in here, in the body, we'll be inserting  a template, which is called hello. That's the syntax that you use with the greater than  symbol. And the template is actually defined below with the template tag that's part of  the web component specification that's getting really popular in the JavaScript world lately  for templating engines. And inside here, you can also see that we have a variable code  called counter defined that will be displayed. So if we want to run it, we just write Meteor  on the console. But first, as it actually suggests here, first I got to obviously have  to go into the folder that was created. Now I type Meteor. Okay. So I still have Meteor  running from the preparations on another application. So I had to close that. Now I go to new app.  Okay, sorry. New app Meteor. Yeah. So now we're starting the development server. And I can  actually, once it's ready, I can go to the browser to localhost 3000. That's the default  port. And we have the standard Meteor application that you get out of the box when you want  to start developing. It's nothing more than a button that you can click. And it counts  how many times you clicked it. So let's have a look at JavaScript that's behind this. And  the JavaScript that is behind is actually working on the session as you might imagine.  So on the session, we have a variable that's called counter. And whenever the button is  clicked, it's incremented. And in this counter variable here, where does it come from? You  can have a look here. And you see that for a template that's called hello, we define  some helpers. And helpers are shorthand for variables of things that you can actually  use in the template to bind to. And counter is actually just getting the counter variable  from the session. So that's how it's all joined together. And then you can also, for the hello  template, you can also specify events. And you specify them using query selectors. So  that's where you say what event you're talking about. And then you specify the selector on  which this event is supposed to be triggered. So whenever we click a button, the session  counter is incremented. And one more thing that we see in this basic code is we have  those meteoris client and meteoris server. And that's quite interesting. Because as I  mentioned, meteor is a full stack framework. So your JavaScript runs both on the server  and on the client by default. Unless you specify with this if statement or you put your files  in a certain director, which I will go to in the next demo. But you can also do it like  that. So you can specify that this runs on the client and this runs on the server. Actually,  in this case, nothing runs on the server. It's just the client side up because it uses  the browser session. So there's no need to contact the server for anything.  So now if I go here, I will show you that we can interact with this. We can interact  with this application a little bit. Can you see the code in the template here and the  console here? Or should I enlarge it? It's okay. Okay. So, yeah, let's have a look at  this code and let's have a look how we can play with it. Yeah, so as you can see, we  have this counter on the session. And I'm actually going to copy that. And I'm going  to try to set it from here, which might seem like a weird idea. But this will demonstrate  and I'll enlarge that. So as you can see, I've run the code, session set counter 13, and  it got automatically updated on the website. And this is the first time that you see the  reactivity that I was talking about. So this code in the console was a simulation of any  external thing that could happen to the application. Whenever something changes in the session,  session is one of the reactive data sources. So whenever it changes, it notifies everyone  who wants to read the session that it changed. So in this case, I changed the counter to  13. The session noticed the new value and it notified the HTML template that, hey, there's  a new value. So, and you asked for it before. So now you, here is the new value, you probably  want to do something about it. And the HTML template rendered the template again. What's  interesting as well for Meteor and for this development environment is that it has a life  reload as you'd imagine. So when I change something in the code, it reloads automatically,  but it's also quite smart because I have a look now. So I have this, you've pressed  button 13 times. I'm going to press F5 and the state is obviously reset. The session is  reset for this application and we start from scratch and I can do all this again. And then  run the code and set it to 13. So now I'm going to set it side by side with the code  editor. And let's say I'm going to go here and change something in the template or in  the JavaScript, doesn't matter. I saved it. It's now reloading here. And you can see it  changed the header to welcome to NDC, but also it didn't reset the counter. And that's  quite interesting because it allows you to do a life reload. But while preserving the  state, the session and all the other state of the application, it's quite smart because  what it does is when it receives a notification from the server or from anywhere else that  some new data came in or even there might be some new JavaScript code, you could actually  send a patch to an application that you already have in production and people are using it  right this very moment. They're logged in and they're doing something and you have a  new version coming in, some new code that you have to deliver. So the client side of  your application then receives this information that there's something new that has to be  released. Saves all the local state and session, et cetera, in the browser, in local storage,  yeah, I was missing the word, in local storage, so in some stores that you have in the browser  that you can use. So it saves that, reloads the application and loads back the state.  So that makes the deployment, as you can imagine, pretty easy and certainly easier than it was  before and you might even have zero downtime deployments which is pretty cool. Okay, so  that's what you get from the standard template that you get with each media application that  you create, but I also have a bit of a more complex example. So I'm going to switch to  this one now, close the media server that's running here. I'm going to go into the ndc  folder where I have the application prepared. I'm going to run it. Okay, the application  started and the application is a simple case of an update that lists some notes that I  took while attending ndc this year. So I learned so far that web development in 2020 is going  to be pretty cool and that I learned on Steve Sanderson's session, which I really, really,  really recommend if you haven't seen it. I also learned, as I mentioned, from Pete Smith's  session that you might not need a framework because you can write it on your own in the  vanilla JavaScript. And I also learned throughout the conference that I probably should start  using Docker. Yeah, so just a few notes that I took and let's see how the code looks like.  So I have some really basic HTML as you saw with some template in here to actually iterate  through the notes collection. So for each note, I'm just displaying the text of the  note in the list, so pretty basic stuff. So let's see how, what else we've got here.  I'm going to zoom in because you probably can't see that here. It's the organization  of my source code that's quite interesting because I mentioned that you can use the media  or its client and media or its server in your code to figure out what's going to run on  the client and on the server. But you can also use some pre-fined directories in here.  So everything that goes into the client directory will be run on the client. Everything in the  server directory, obviously, will be run at server. There is also a special lib directory  for libraries. And you have a guarantee that everything that's in the lib directory will  be run first. So you load there all the dependencies that you need to have accessible.  For your own code. So, yeah. So in this, in the client, I have defined a notes helper  for the template. And this is the notes here that are iterated over to display the text.  So I say that notes is just a notes collection. And I'll show you where the collection is  defined in the moment. And it's a MongoDB collection. And there's a finds method on  it that you can use to just bring the whole collection to the client side. And the notes  collection is defined here in the lib directory. So it's available everywhere. And it's loaded  as one of the first things with your application. And as I mentioned, media uses Mongo. And  it uses Mongo, interestingly, both on the server, which is not surprising, but it also  has a Mongo implementation that you can use on the client. And those two Mongo instances  keep themselves in sync automatically for you. So when you add something to the client,  it's automatically synced to the server. And then it can even be automatically synced  to other instances of your application that are running out there.  And to populate this, this notes collection in the server folder. So on the server side,  I've added just this basic code to insert those three notes that you have seen on the  website when I started it. So now I'm going to use the console again to insert something  else. And we'll see how that works. So I just have notes insert and enter the text. Media  is cool. Run that. And obviously, it got added to the collection as you see and displayed  on the website. But that's something we've already seen. So there's nothing really dramatic  going on here, but I'll now run it in two browsers so that you can see that it actually  syncs like I told you. So I'm going to insert media or school again into here, into the  left browser and you can see that it will actually automatically appear in the right  browser as well. Which, and it was pretty fast obviously because it's running on local  host. But what's pretty mind blowing to me and pretty awesome is how it actually works.  Because what it does is by executing the notes insert, I'm talking directly to the client  side Mongo implementation. And I'm pushing the data directly to the database on the client  side. And what happens then? The Mongo instance notifies the template of the left side browser  that hello, there's new data you need to update and it updates later on. But it also notifies  the server side Mongo that I have new data and you probably have to sync it as well.  So the server side Mongo syncs it. Server side Mongo notifies the client Mongo on the  right hand side browser that hello, new data so you need to sync. So the client side on  the right syncs and the client side on the right notifies the template on the right that  hello, new data so you need to display it. So as you see there's quite a lot going on  under the hood and you actually don't have to worry about it. You know that all your  data is available on the client and you can count on it that it's always there and always  syncs automatically for you. But obviously if you think about it a bit more, you might  think that hmm, what the actual hell? What do you mean my whole database is available  on the client? And everyone can just insert something into the database by fiddling with  the console that doesn't sound right. And I agree. Obviously there are at least two major  issues that you can think of. Security. So you don't want people to be able to fiddle  with your database just by opening the F12 console tools. And also performance because  if your database is quite big, you don't want to push it all to the client if it's like  100 megs or so. So obviously there are ways in Meteor that you can deal with that. And  obviously you have to deal with that because it will be unacceptable to release an application  that exposes the database on the client side because it's not a secure environment. So  what you can do, let's tackle the security first. Why I was able to insert this data  from the console just without any restrictions is that when you start developing with Meteor  to make sure that it's as easy as possible for you to get started, there is an insecure  package that it's added. And the insecure package, generally there are packages in Meteor that  you can add that there's a repository for them as well, which is called Atmosphere. That's  what I should have started with. But one of the packages that you can get out of the box  is an insecure package which just says that everybody can do everything to the database,  which is really cool when you start developing because you don't have to care about this  and all this stuff and you can start developing pretty quickly. But once you want to release  the application, you should probably actually go into your console and type Meteor Remove  Insecure. Now I've removed the insecure package. And  let's see what if something will actually change. So I will just maximize that. So I  want to add Meteor as cool again. But as you can see here, now I actually said insert fail  because my access is denied. Because when you remove this package, all access from the  client side is denied. And you can only modify the database on the server side. But if you  want to still continue to be able to add something from the client side, one option that you  can use is you can define permissions explicitly. So we can say that for the notes collection,  I allow inserting. If the text of the document that you want to insert is I like Meteor.  So let's try that. I'm going to copy this. Okay. Yeah. I refreshed because I uncommented  this code. So I'm going to copy I like Meteor and insert it okay. But the moment I just  add something in here like an exclamation mark, it won't add it and it will tell me  again that my access is denied because it didn't fit any rules in here. Obviously you  can also, when you have an insecure package, it's somehow as if you were to put return  through in here. But you'll notice that you also have a user ID in here of the user that  wants to do the insert. So when you have some user management, you can also figure out,  look in your database to the permissions table, figure out who's able to do what. So you can  control this pretty much in any way you need. So that's one consent that I've dealt with.  The security, but then we still have the performance issue. We don't want to publish the whole database  to every client that connects. So what can we do about that? It turns out there's actually  another package that's included out of the box to ease the development. And the package  is called auto publish. If I can spell it correctly, auto publish. Yeah. So it's also  included out of the box and it publishes your whole database to the client, which is great  if you just want to quickly develop something and hack something together. But then the  time comes when this is no longer an option because you're still going to be deploying  this application. So you remove that and you go to your website and nothing appears because  nothing is published. So now when you remove this package, you have a standard publish  subscribe situation going on here. So on the server, you have some code that you says that  from the notes collection that I already have in there somewhere, I want to publish everything.  So I just say notes find and leave it empty, but you could obviously provide some Mongo  query option here. And just for example, obviously one of these choices is to only publish the  data that belongs to the current user because there's no need for him to have other users  data synced on this client machine. So that's what you do on the server. And on the client  as well, you have to subscribe to be able to receive the data from the notes collection.  So once we've done that, I go back to the website and fortunately all the data is still  there. And we, as you can see, we can have some tight control over what actually gets  automatically synced between the client and the server. So it's really useful, the syncing  I mean, but you can also control it quite well and make sure that you actually know  what's going on and who has access to what because it's pretty important, obviously.  And one last thing that I want to show you in the demo is one of the major features and  major selling points for Meteor and it's called latency compensation. It's a cool idea. In  theory it says that, okay, so we've got the code that runs on the client and on the server.  We know what code runs where we have a database on the client and most of the stuff that we  go to the server usually involves dealing with the database. And this is where the latency  comes from because we have to wait for the response and then the user sees the spinner  and waits. But if we have everything on the client, let's execute the code on the client  and try to figure out what will happen. And that's what happens in Meteor and I will demo  it in a moment. But what happens is Meteor updates the client immediately and changes  the template as well. So displays the state that would happen most probably if everything  goes okay and then goes to the server and if the server has a different response then  the UI is updated. So in order to demo this, I'll show you some code. And this is what's  called a Meteor method. It's a way to modify the data on the server side and you can call  it from the client side. And what I'm doing here is I'm inserting the text, appending  the text server to the message that I will enter in the moment. So if I'm executing this  code on the server, I'm appending server to it and waiting for three seconds. But if  I'm running it on the client, I'm appending the client in parenthesis and not waiting.  So what you see will happen here, when I use this method in the moment, it will immediately  appear in the browser with the word client appended and after three seconds the server  will send its response and will be corrected. So let's have a look at that and we'll actually  have a look at that again in two browser windows. So add notes was the name. Add notes, okay.  So I'm going to go ahead and add a message with the text test and yeah, let's see the  other browser too. So it appeared on the left for three seconds and then it appeared on  the right as well and on the left it was corrected. So that's exactly what you have, what I told  you and what you can see in this code. Another thing we can try is forbid the insert of the  server completely on the server and also causes an interesting situation here on those browsers  because the neural note will appear for three seconds on the left and it will be removed  because the server forbid the insert and it won't appear at all obviously on the right  hand side browser because it wasn't synced from the server because the data never appeared  on the server. Yeah, so that's about it although we have some time left fortunately so I'll  show you one more feature that's really useful for Meteor. When you develop a Meteor app  you have an option to deploy it for free under the meteor.com subdomain and that gives you  some really cool things that you can do because you can without paying for any hosting without  having to configure absolutely anything you can just deploy it to subdomain.meteor.com  from your command line and you do it like that. Meteor deploy and DC Oslo 2015, hope  it's not taken. And DC Oslo 2015. Okay and now it's gonna ask me probably for an email  or maybe I will remember the one I entered last time, it's probably will. And so it's  building it and it will sync it to the meteor.com domain and you get some reasonable amount of  database space in there so it should be enough for you to demo it to the client to show it  off to your colleagues as well if you need to. We'll let it run for a moment and in the  meantime I'll open it in the browser. Not there yet. Yeah but to my mind while I'm gonna talk  a bit while we wait for this to finish so let's go back to the presentation. In my mind  this deployment thing is pretty cool as well because as I said it requires no effort on  our part just one command line that one command that you have to enter in your console and  you're done and you can show it off to the world. Yeah so while I wait for the deploy  to finish it might be difficult on this Wi-Fi because I will see it's been good so far today.  There are actually seven basic principles that the Meteor team proclaim and that they  work on and they base they work on and I would like to just let you know what those principles  are at the end because to me they make a lot of sense. So as you saw all the updates and  all the actions that happen all the interaction between the server side and the client side  is pretty quick and it's thanks to the fact that those aren't HTTP calls like REST API  calls and something like that. This is happening through web sockets and it's only pure data  that's transferred between the client and the server. It's just data usually between  the MongoDB implementations and then everything happens on the client automatically, they're  all the syncing and notifying the templates etc. So that's why it's pretty quick. So it  will be certainly quicker than your standard SPA application at least to the user. It  will feel as if it's a native app that he runs on his desktop.  One language as I mentioned so you have JavaScript everywhere even in the database because MongoDB  actually holds JSON objects and you query with a JavaScript syntax so there's no context  switching and it can be super productive. The database is everywhere as you already  seen and it syncs automatically. Latency compensation that I demonstrated so you can see the framework  simulates what will happen on the client and in 99.9% of the cases it's right so then  the user doesn't even notice that there has been a simulation on the client because the  server actually performs the same and there's nothing, no corrections that you have to do  so I would say it's a good idea to optimize for those 99% of the cases because it's a  great experience for the user. You've got this reactivity that I mentioned so the reactivity  is the fact that everything auto updates because each part of the framework is able to realize  that okay something changed with me so I need to notify everybody else who was asking for  my value so that template or the database or whatever else needs to be updated.  And finally there's a really good ecosystem around Meteor that includes some open source  tools, the whole of Meteor is obviously open source as well. There are those packages that  I mentioned as a whole collection of them and the community is creating their own packages  and there's a lot of people interested and involved. There's a lot of ways that you  can get help also some ways that you can contribute that you can read on at Meteor.com if you're  interested. And this is the code that I really like. It says that the best way to make something  seems simple is to have it actually be simple and that's how I felt that it really Meteor  I think delivers on this promise. It also seems really simple when you develop there's  not much places where you have to scratch your head and try to figure out what actually  the framework is doing and why it's done like that. So those seven principles are really  you can really see them. It's not just words that they came up with the marketing department  or somebody else and they've put them on the website. It's what you can see on the actual  tool. Yeah, so here are some resources that you can have a look at. And in the meantime  though we'll have a look if it deployed. Yeah, okay, so it deployed. It also just tells me  that I can set up a password to manage my deployments to Meteor.com but I'm not going  to do that now. I'm just going to refresh it here and you can see that my application  is in there. I can now go in and to the console and play with it like I did with the previous  one. Okay, coming back to slides and the resources that I recommend. The first one is the slides  and the code from this very presentation if you want to have a look. Then I recommend  if you're interested to go to meteor.com. Install when you have the installation instructions  and then if you proceed, actually you have to have a look at that. So yeah, so you have  some instructions how to install it on Windows, how to install it on OS X or Linux. And then  if you continue to the tutorial you have a 12 steps tutorial that I really recommend.  It will take you like 45 minutes up to an hour and it covers a bit more stuff that I  was able to get into. It covers for example running Meteor web applications as native  mobile applications on mobile thanks to using Apache Cordoba which is quite cool. And a  few other things. So I really recommend because as soon as you play with it you get your hands  dirty with code. You will have an even better understanding of what Meteor is all about  and what it can give you. Then there's also really good documentation on meteor.com that  I recommend. And you can also read about the individual projects, the libraries that Meteor  is composed of on meteor.com slash projects. There's a really good resource as well to  learn which is the Discover Meteor book. Which is kind of like a Bible for Meteor at this  point. And you can buy it here and you can also read the blog which is really good. And  there's also a book called Meteor in Action by Manning which is in early access now. But  it's almost, I think it's about 80% there. Or even more as you can see. All the parts  are available so they're just working on some final fixes. So I really recommend this book.  And yeah, and that's it. So thanks very much for your attention. I hope I managed to convince  at least some of you to give Meteor a try. And I'll be happy to answer any questions.  In the meantime my assistant also distributed some Meteor stickers here. So if you want to  grab one, feel free. Yeah, so as I said, questions. And when you leave the room also please remember  to rate my session. Questions? Yeah?  Is there a way to write modules or isolate variables because all we saw was strings and  sessions. Is there a way to create more structure to provide data models within the application  or just sessions? Yeah, the question is if there is a more  structureized way to manage your data inside JavaScript code because what we saw was only  the session. Yes. So this is just JavaScript, right? So you can do basically whatever you  want. It's a bit unfamiliar at the beginning because what Meteor does is it looks at all  the JavaScript files that you have in there and just merges them into one. And that's  why you have to control the order in which they are merged. That's why you have this  lib folder where you can put some code that is, you have got guaranteed it will be executed  first. So if you have some data hierarchy that you want to make sure is available to  everywhere else, you would for example put it there. But you can, you are free to design  it however you want. There is not much restrictions that Meteor enforces on you. Yeah?  My other question is how do you handle the dependencies within the lib folder? Do you  have the possibility to post that? Yes, far as I remember, the question is I'll  repeat for the recording as well. The question is how do you manage the dependencies inside  the lib folder if you want to still control? As far as I remember, it's alphabetical. So  you might have to do some hacks and enter A to the beginning of the file name. Yeah.  But you still have control over it. My other question is about unit testing. Can you integrate  easily with a Opera, JavaScript testing framework? Yes, you can. And there is also a built-in  tool for testing in Meteor although I have to admit I have not tried it yet because I  was also giving a talk on unit testing and I'm just, I'm using some other tools for that  and you can obviously use them as well here like Karma, Jasmine, whatever. Yeah?  What is the server, the HTTP server running Meteor and can you change for instance the  headers and everything? The one that you see in development, that's  probably just something from Node. I don't know exactly what but obviously you shouldn't  use that in production I think. By the way, I'm happy to answer more questions. You don't  have to be shy. I'm happy that you're interested. But yeah, so in production what you will probably  do is some other server as a proxy that will just forward the Meteor calls to your Meteor  instance and the proxy server like NGINX or something else would that handle all the HTTPS  and stuff. Okay, any more questions from anyone? It's  not been. Thanks very much. Enjoy your last session of the conference and enjoy the party  as well afterwards. Thanks.
Getting_started_with_Meteor_-_Kuba_Walinski_0_1199.png Getting_started_with_Meteor_-_Kuba_Walinski_1200_3611.png Getting_started_with_Meteor_-_Kuba_Walinski_3612_5327.png Getting_started_with_Meteor_-_Kuba_Walinski_5328_6359.png Getting_started_with_Meteor_-_Kuba_Walinski_6360_8963.png Getting_started_with_Meteor_-_Kuba_Walinski_8964_10307.png Getting_started_with_Meteor_-_Kuba_Walinski_10308_11339.png Getting_started_with_Meteor_-_Kuba_Walinski_11340_12827.png Getting_started_with_Meteor_-_Kuba_Walinski_12828_14639.png Getting_started_with_Meteor_-_Kuba_Walinski_14640_15935.png Getting_started_with_Meteor_-_Kuba_Walinski_15936_16019.png Getting_started_with_Meteor_-_Kuba_Walinski_16020_17099.png Getting_started_with_Meteor_-_Kuba_Walinski_17100_17603.png Getting_started_with_Meteor_-_Kuba_Walinski_17604_18047.png Getting_started_with_Meteor_-_Kuba_Walinski_18048_19031.png Getting_started_with_Meteor_-_Kuba_Walinski_19032_20711.png Getting_started_with_Meteor_-_Kuba_Walinski_20712_22475.png Getting_started_with_Meteor_-_Kuba_Walinski_22476_23051.png Getting_started_with_Meteor_-_Kuba_Walinski_23052_25475.png Getting_started_with_Meteor_-_Kuba_Walinski_25476_26171.png Getting_started_with_Meteor_-_Kuba_Walinski_26172_26255.png Getting_started_with_Meteor_-_Kuba_Walinski_26256_27455.png Getting_started_with_Meteor_-_Kuba_Walinski_27456_28295.png Getting_started_with_Meteor_-_Kuba_Walinski_28296_29939.png Getting_started_with_Meteor_-_Kuba_Walinski_29940_30035.png Getting_started_with_Meteor_-_Kuba_Walinski_30036_34043.png Getting_started_with_Meteor_-_Kuba_Walinski_34044_36815.png Getting_started_with_Meteor_-_Kuba_Walinski_36816_39455.png Getting_started_with_Meteor_-_Kuba_Walinski_39456_39719.png Getting_started_with_Meteor_-_Kuba_Walinski_39720_40355.png Getting_started_with_Meteor_-_Kuba_Walinski_40356_41435.png Getting_started_with_Meteor_-_Kuba_Walinski_41436_41507.png Getting_started_with_Meteor_-_Kuba_Walinski_41508_42119.png Getting_started_with_Meteor_-_Kuba_Walinski_42120_43271.png Getting_started_with_Meteor_-_Kuba_Walinski_43272_45647.png Getting_started_with_Meteor_-_Kuba_Walinski_45648_46379.png Getting_started_with_Meteor_-_Kuba_Walinski_46380_50363.png Getting_started_with_Meteor_-_Kuba_Walinski_50364_53039.png Getting_started_with_Meteor_-_Kuba_Walinski_53040_53267.png Getting_started_with_Meteor_-_Kuba_Walinski_53268_53495.png Getting_started_with_Meteor_-_Kuba_Walinski_53496_53591.png Getting_started_with_Meteor_-_Kuba_Walinski_53592_54551.png Getting_started_with_Meteor_-_Kuba_Walinski_54552_56555.png Getting_started_with_Meteor_-_Kuba_Walinski_56556_56723.png Getting_started_with_Meteor_-_Kuba_Walinski_56724_56795.png Getting_started_with_Meteor_-_Kuba_Walinski_56796_61559.png Getting_started_with_Meteor_-_Kuba_Walinski_61560_62267.png Getting_started_with_Meteor_-_Kuba_Walinski_62268_62831.png Getting_started_with_Meteor_-_Kuba_Walinski_62832_63539.png Getting_started_with_Meteor_-_Kuba_Walinski_63540_65483.png Getting_started_with_Meteor_-_Kuba_Walinski_65484_65543.png Getting_started_with_Meteor_-_Kuba_Walinski_65544_65603.png Getting_started_with_Meteor_-_Kuba_Walinski_65604_65843.png Getting_started_with_Meteor_-_Kuba_Walinski_65844_65891.png Getting_started_with_Meteor_-_Kuba_Walinski_65892_66071.png Getting_started_with_Meteor_-_Kuba_Walinski_66072_66119.png Getting_started_with_Meteor_-_Kuba_Walinski_66120_66179.png Getting_started_with_Meteor_-_Kuba_Walinski_66180_66263.png Getting_started_with_Meteor_-_Kuba_Walinski_66264_67091.png Getting_started_with_Meteor_-_Kuba_Walinski_67092_68111.png Getting_started_with_Meteor_-_Kuba_Walinski_68112_68711.png Getting_started_with_Meteor_-_Kuba_Walinski_68712_69383.png Getting_started_with_Meteor_-_Kuba_Walinski_69384_69491.png Getting_started_with_Meteor_-_Kuba_Walinski_69492_70091.png Getting_started_with_Meteor_-_Kuba_Walinski_70092_70943.png Getting_started_with_Meteor_-_Kuba_Walinski_70944_71603.png Getting_started_with_Meteor_-_Kuba_Walinski_71604_72191.png Getting_started_with_Meteor_-_Kuba_Walinski_72192_72251.png Getting_started_with_Meteor_-_Kuba_Walinski_72252_72455.png Getting_started_with_Meteor_-_Kuba_Walinski_72456_72539.png Getting_started_with_Meteor_-_Kuba_Walinski_72540_72863.png Getting_started_with_Meteor_-_Kuba_Walinski_72864_73343.png Getting_started_with_Meteor_-_Kuba_Walinski_73344_73511.png Getting_started_with_Meteor_-_Kuba_Walinski_73512_74831.png Getting_started_with_Meteor_-_Kuba_Walinski_74832_75155.png Getting_started_with_Meteor_-_Kuba_Walinski_75156_75695.png Getting_started_with_Meteor_-_Kuba_Walinski_75696_81239.png Getting_started_with_Meteor_-_Kuba_Walinski_81240_81479.png Getting_started_with_Meteor_-_Kuba_Walinski_81480_81517.png