 So, the first time we encountered web development was in a college class. That class, it was known as the WebApps class for the WebDev class, where essentially we spent an entire semester just making WebApps and regretting on them. The one problem with this class, though, is that they taught zero HTML or JavaScript. And on top of that, I took a Twitter clone in the first two days. So that's where I invented Fritter. And so I'm going to be real with you guys, I had zero idea what the heck I was doing, and just like any college student who had zero idea what he was doing, I looked at what the smart kids were doing, and that's when I discovered jQuery. It was like a gift from the gods. I can just do whatever I wanted. I could command the DOM. I could add event listers to whatever I wanted to. But it was a garbled mess of dollar signs and parentheses. But it did teach me something really important about web development. The power of the JavaScript library. And I got a little bit carried away. But first Fritter needed a back end. And you can't have a cool back end without note and express, right? And on top of that, I found out I was completely just trash at making things look pretty on the web. So here's a library for that. And actually, it also had to be built with gold, apparently. And then after that, I came into contact with the beautiful thing that we call the JavaScript date class. So there's something right there. I have zero idea how to use that in Node. So I just copied all the content straight into the index.html file. Well, and then you can't have a cool app without MongoDB, right? Scratch that. I have no idea how to use MongoDB. So there's a library for that as well. And then also, there's some more libraries. To this day, I have no idea what these libraries do. But they're in there. They're getting loaded. So here they are. Actually, also, I don't know how to use semantic on Node. So I copied several megabytes of CSS and JavaScript straight into the index.html. But this was fritter. And when you use all of these technologies together with zero plan, you always result in the exact same thing. And these are real commit messages, by the way. And I call them the four stages to irresponsible hacking. So stage number one, confusion. And then stage number two, even more confusion. Stage number three, anger. And stage number four, I need a break. But to me, before Polymer Web Components, this was hacking with the web. A slow, over-encumbered mess, but it worked. And the problem with this project is that I never want to look at it ever again, and it's absolutely impossible to extend without starting from scratch. So that's why I'm here. Howdy, everybody. I'm Elliot Marquez. I am a software developer on the Polymer team. And this is my hashtag right there. There might be a polymon, you never know. There isn't. And I want to welcome you to Hacking with the Web, Elliot's tips for survival. So first question right off the bat, what do I mean by a hack? A hack, I will define as a software project or hardware project that is built quickly, often haphazardly. But it gets the job done. The fancy word for that is MVP. And the next question you might have is why the heck would anybody do this to themselves? Well, or say you have investors coming over and you got to make sure you want to get some money, and you got to show them a little bit of technology so you maybe want to make a prototype. Or say a tech blog, they release your product earlier than you expected. So you know that deadline that you have at the end of the month? No, you don't, because it's next week. Or say that you sign up for a hackathon. So for anybody that doesn't know, a hackathon is a convention or a bunch of nerds come together to make really cool software and hardware projects with a limited amount of time and unlimited amount of coffee. And so the reason that I know about hackathons is because I went to one. The Polymer team in early September, we went to Penn apps, which is the oldest student run hackathon in the US. And it's hosted by the good old University of Pennsylvania. And there we met a bunch of students, either they renewed web development or we had some seasoned hackers, but they all had something in common. They didn't really want to hack with the web. And the reasons range from either they didn't know what web development was or how to do it, or some of them just thought hacking with the web was just like my old project Fritter. But as soon as we introduce them to the beauty that is Polymer and web components, they fell in love with the web. So you get to understand these students came from generally Java or C++ backgrounds. So they really liked how web components added a object-oriented programming experience to the DOM and HTML. And on top of that, they're just blown away by CSS encapsulation. And it sounds a bit silly right now, but if you think about it, before Shadow DOM, this was a really big issue. And so watching these students labor way on web projects, I was able to see some development patterns emerge. And that's where I came up with, Elliot's four tips to hack in responsibly. So, tip the first, do not repeat yourself. I repeat myself. Do not repeat yourself. Tip number two, pass only what you need. Tip number three, go full front end with and tip number four, split by feature. Okay, so tip number one, do not repeat yourself. So a shout out to Steve Stahlherler and Monica's coming up soon. You have a timeline to reach people. Be a lazy coder, write less code. The ways you can do this is that you can write elements that fit into DOM repeats or you guys and gals as well have made an amazing web components community out there. So just HTML imports something that somebody else has made and just copy paste the tag. It's really easy. And you may say, Elliot, maybe this is going to be something more permanent, I want to keep it around. So actually, no, well, you will. So actually, first you got to write ultra-extensible elements as well. So what I mean by that is instead of writing a bunch of boilerplate code, write and writing an element for each possible use case, write elements that will handle multiple use cases. And then you'll ask, but Elliot, I want to keep this thing around. I want to make it more permanent later on. Well, in that case, you just got to rely on web components right there. Web components makes it really easy to scale features back and move things to the back end and do whatever you want later on. Okay, tip number two, pass only what you need. So Polymer's Data Binding is a powerful tool that can shoot you in the flight. So at the hackathon, we found that a bunch of the hackers were passing lists of objects to multiple children. This creates multiple models, duplicate models. And the issue with that is that duplicate models are bad. So now you have a bunch of models that are supposed to be synchronized with each other, but the issue is it's really easy to make these un-synchronized with each other. So what this ends up causing is a bunch of elements that just don't respond to changes or change too much. And now you have a bunch of spaghetti code that's really confusing. So you got to remember that just like helicopter parents, a parent element should control its child state all the time, not if it's neighbor. And the reason is because you got to keep it modular. If your element relies on its neighbor's internal state, shout out to Graysock, talking about the mediator model. You're not keeping it modular. And web components were designed to be modular. So I assure you, if you write your code to be modular, then you'll run into a lot less issues like spaghetti data binding and unforeseen view changes. Take number three, go full front end. So instead of switching between multiple modes of thought, you just use from the front end. Make it the star of the show. The app toolbox is great. It can handle routing. It can handle layouts. It can handle storage. It can even handle offline capabilities. For example, putting iron pages and app route together, you can remove most needs for a back-end router. And so you're going to say, Elliot, but I want to keep this around just a bit longer. So web components, like I said, makes it really easy. The talk earlier this morning by Ingy really exemplified this. Web components makes it really easy to scale things back and move things to the back end. They already have an API sort of established. All right, tip number four, split by feature. So say you're unlucky to be stuck in this hole with a team. So you want to split the work by feature and experience. So before web components, you would split the work by pages. And so somebody would make the main page. Somebody would make the login page. Somebody would make the messages page. It's like creating a completely different app every single time. So now you would split by strengths and experience. So say Bob over here, he is terrible at making logical elements, but he can make dirt look like gold. He's an amazing web designer. Jane over here, she's an amazing web designer as well, but she's also a really great logical elements maker, like routers for days. But so in this case, you would have Bob over here, make the visual elements. Jane over here, make the logical elements. And next thing you know, bam, you're parallelizing. And also with web components, a great thing with parallelization is also with Polymer. You'll probably be making, be working on completely different HTML files. So you'll probably run into a lot less merge conflicts, which is a real big issue. Actually had a friend in college who would have a forced merge that would just delete everything anybody else did. And the one caveat about this tip, though, is it requires a lot of communication with the team. Make sure you communicate your APIs effectively. And so you know what you're getting out of each web component. Tip number five, step back, calm down, and grab yourself a beer or coffee, whatever you love. So beer is great. Stress isn't so great. Have a beer. Also, I hear there's this thing called science. And it created this thing called the Bulmer Curve. And as you can see, with some alcohol on you, you become an amazing coder. Hey, Steve. So in case you need to prototype something or you have an unexpected deadline or you just happen to wake up in the middle of a hackathon, do not worry. Remember my five tips to hacking. Do not repeat code that you do not need. Pass only what you need to child elements. Go full front end with our app toolbox. Split the work by feature and experience. And finally, step back, have a beer, code some more, and congratulate yourself with some more beer. Thank you very much.