 We'll give this a shot. Can you guys hear me okay? I sit back here, it's still good. The name of this talk is How HTML5 Killed My Career. Not exactly perfect, but I'll get to that in a second. How many people here have developed, is it mine? Oh, I don't have mine anymore. I feel like you guys can hear me without this, but maybe not. The acoustics in here are pretty good, so. Anybody here developed in Flash before? You get a raise of hands. Oh, quite a few. All right guys. And front-end developers who think Flash was the worst thing ever invented. All right, so about equal parts on that half. We'll talk after the session. I want to find out why people hate Flash so much. I've always been curious in that. I've never really gotten a straight answer other than JavaScript is better. But hopefully we'll convince you that maybe your tool of choice doesn't matter as much as you might have thought before. So as I mentioned, talks called How HTML5 Killed My Career. A more pertinent title might be how HTML5 changed the direction of my career. It didn't necessarily kill it so much as it shifted the way I had to learn and what I had to learn to stay in business. So a better title might have been what I learned spending way too many years focusing all of my attention on Flash, leaving me unprepared when HTML5 became the new hot development tool for the interwebs, and causing me to miss out on valuable business opportunities which caused a lull in my workload and forced me to finally sit down and learn all the cool new things that I could do with HTML5. The problem with that is that title was a bit too long to submit and obnoxiously it wasn't as, I guess, cool sounding as how HTML5 killed my career and probably that spoke better to the half of the audience that hates Flash. So what this talk is and isn't about, this talk will be about Flash and about HTML5. It won't be about the great debate in which one is better. I won't be leaning to one side or the other in regards to which tool you should use or should have used in the past. It's gonna be more about looking over kind of where we came from and how Flash laid some of the foundation work for HTML5. So this is really a story about learning to appreciate your tools and value them, the ones we have at our disposal at the time. I'm figuring out how to use them as developers to our advantage. Most often this means choosing the right tool for the job but occasionally it means working with what you have available. And this is kind of how my journey with Flash began. You know, at the time it was early 2000s, there was a lot of issues with cross browser consistency. You know, a lot of workarounds to try to get things to work in IE9 and Firefox and Netscape. But Flash, you know, kind of provided a mandate to allow you to develop once and distribute that content across multiple platforms. And it worked pretty well most of the time. So let's take a look back. 2001, Flash was just kind of getting into its, I guess, more professional days. It started off earlier with some simple animations and such but in 2001 they released a new feature for ActionScript 1.0 which was a really important feature because it allowed you to start scripting within the application which then allowed you to develop software as opposed to just putting a few lines of code that might let you jump to a frame or something like that. And what I've got up here is kind of a differentiator showing the difference between Flash in ActionScript 1.0 and JavaScript at the time. Now they're both based on ECMAScript so, you know, in the beginning they both looked fairly similar. The big things you'll notice here is the difference between console.log and trace. That was really just method naming. So not a lot of differences in the early days between JavaScript and ActionScript. But over the next 10 years or so, till 2007, seven years, I guess. ActionScript 3.0 was released in 2007 and during that time between 2000 and 2007 and AS1 and AS3, a lot of changes happened in ActionScript. The language became class based. There's a lot of improvements in the structure and the functionality of the language. JavaScript roughly stayed the same and it has until very recently when we started seeing improvements to ECMAScript with ECMAScript 5 and 6 or 2015 and 2016 now. So when you look at ActionScript 3, here's another comparison between JavaScript and ActionScript 3 when AS3 was released in 2007. As you'll notice, JS didn't really change at all. It's the same prototypical language. Doesn't really have any new features. It's still written the exact same as it was seven years earlier. Flash, on the other hand, as I mentioned, fully class based ideas of public and private properties, strict data typing, compile time error checking for data types, public and private classes, inheritance. All these concepts, so it's really allowed you to start developing software, as I mentioned, in an object oriented way. So at the time, I had to go from learning to hack some code together to learning to be a software developer, which was really a big shift. So let's look at some of the features that really made Flash a winner, I guess, in the space or differentiated between JavaScript and HTML at the time. One of the big ones was animation. Flash was one of the first tools that really allowed artists to start sharing their work online, and animators specifically. It developed, or brought about a whole new generation of animators who were able to share their content online. And if you guys can't hear me, please just wave. So this is just an example here. This is an animation from simonscats.com, a guy named Simon Tulfield. He's done a number of these animations about his cats. I believe they're all done mostly on the timeline in Flash. And timeline animation as an IDE tool was really useful for people that were traditionally used to using pen and paper or things like Photoshop. They now had similar tools in Flash, but they could actually bring them to life and share them with people online. Later, reversions of the Flash player came with 3D animation. So now we had hardware acceleration and the ability to do some really, really insane graphics. This was a game that was released for the Adobe Max conference in 2011. It also showcased a new feature of peer-to-peer communications. So this was actually a racing game where all the Flash players would connect to all the other players of the game. So you were all connected directly peer-to-peer to exchange game data, exchange positions, et cetera. And we'll touch a little bit more on that later. But as you can see, I mean, it was some pretty impressive graphics that could be achieved using just Flash. And again, at the time, there wasn't anything even close to this available in HTML or JavaScript. Audio is another big one. The ability to stream audio content gave people a new way to share and discover music online. So sites like Pandora and Groove Shark and a number of others came out that allow you to discover new music in interesting ways. Flash and ActionScript also gave you the ability to work with audio at much lower levels. So you could actually interact with the byte data of the audio files and do things like create sound mixing boards all in Flash. So again, it's giving a new set of tools to developers to allow us to start playing with these things. Video is the same thing. And real quick, I'll touch those little hearts up at the top. We're just kind of my feelings towards the language at the time. This is when I was really starting to love Flash and sort of gaining speed with it. HTML5 will come later, as you'll see. The video, we had the ability to share our content online for video for the first time with Flash. It allowed you to stream things across multiple sites, again, interact at a low level with the video file. So if you wanted to do things like trigger events based on a specific position in a video or scale it even on simple things like play, pause, and seek, progressive seeking and progressive download. So again, this brought a whole new generation of video sharing capabilities online. In sites like YouTube, we're all built around this. Components were another big thing. You know, we have HTML elements. We always have things like text inputs and buttons. And you have some of that same stuff in Flash. But then you have more rich components like the progress bar, the scroll pane, and the FLV playback component. So this video playback component here, you could literally drag and drop in Flash onto your stage. You could adjust the controls, depending on what you needed. If you wanted to play and pause or you wanted seek or mute, you could add all that stuff in and quickly skin it out to your needs and then just start using it in your application. So again, without having to do any development, I was able to add videos in line in a similar fashion to how you can do it with the video element in HTML today. Another big leap forward with Flash was the addition of the hardware APIs. Suddenly, we could access things like the microphone and the webcam. This is a little photo booth application that I saw online. But people have done some really interesting things, including JibJab, which you guys might know for their more satirical comedy animations. They've used the hardware APIs to actually allow people to become front and center part of the content that they're creating. So JibJab actually created a number of animations and then also included video and audio and then used the hardware API to let people actually include their own faces. So this is something I found on YouTube. It's the Gomez family's vacation video, I guess, but it's all put to Pharrell's happy video. So again, some really interesting stuff that people were able to do that they couldn't really do using just HTML and JavaScript. And that peer-to-peer piece I mentioned earlier, this was involved in that game for peer-to-peer communication. This is a picture of a full mesh network topology. So basically every client on the network attaches to every other client or connects to directly. It's not the best scenario, but it works pretty well for under eight or 10 clients. And this is how that game worked. So every person playing that game would connect to every other person playing that game and exchange data directly peer-to-peer across that network. So that reduces latency, gives you the ability to share data very quickly and without having to go through a server. So there's no server architecture to set up and there's no bandwidth charges on that side either. So that's some of the features that I worked with in Flash. I spent about 10 years developing a business, Flash Dev for hire, which aptly described what I did. I worked with a bunch of interesting companies. I created a kid's game along the way called Free Guitars, worked with Qualcomm, Digitaria, company called Hansen. We created a touchscreen kiosk for doing kitchen designs for large cabinet manufacturer. I worked with, who was it? Totally lost my space. Anyways, moving along, we created all sorts of interesting applications using Flash and it was really spread all across the board. The problem is that I spent all this time really married to Flash. I didn't spend much time working with PHP or JavaScript or HTML or really anything out of ActionScript. I had enough on my plate just to learn all the new things that were coming out with Flash and so I was happy to ignore the rest of the stuff going on around me. Being married to Flash in this way was something that would kind of set me up for trouble later down the road. So as I mentioned, things were moving along smoothly and then the browser wars started. Suddenly people were ingesting content a new way. They were turning to their mobile devices, their tablets, their phones to start browsing the web and taking it with them everywhere they went. The problem with this is that Flash didn't really run that well on mobile devices. So Adobe stepped up and spent a few years really working with device manufacturers to get the Flash runtime to run on all their devices and largely they were successful. Air ran on Android and on Google, excuse me, BlackBerry devices. They also ran on Nokia, Sony Ericsson. Pretty much every device you can imagine, even Logitech desktop or set top boxes would run Flash. The one big person that would not run Flash in the company was Apple. And Apple refused wholeheartedly to have any sort of Flash content running on the iOS device. This resulted in a very public, very bitter kind of back and forth between Apple and Adobe. It was like nothing I've ever really seen before with publicly traded companies. Apple or Adobe at one point took out a full page ad in all the major newspapers during their Big Macs conference that said we love Apple. We love creativity, we love innovation, we love apps and the end of the article said what we don't love is anybody taking away your freedom to choose what you create, how you create it and what you experience on the web. So obviously this was a direct slap in the face of Apple and Apple responded in kind by taking out a article on their own website titled Thoughts on Flash. And it ended with perhaps Adobe should focus more on creating great HTML5 tools for the future and less on criticizing Apple for leaving the past behind. So at the time I didn't really understand this. Neither of these people said much about why HTML5 was so great. All we were seeing when these articles came out was some simple drawing stuff with JavaScript and the canvas element. Some very rudimentary video and audio capabilities but they were all very annoying to use. You had to create multiple copies of your audio file, multiple copies of your video file. There was all sorts of transcoding and given the option between doing all that extra work and simply using the Flash tools that already worked with MP4s alone, it was a simple choice. So they're putting all their eggs behind or they're backing behind HTML5 but they're not really telling us why this is what they're doing. And so we were a bit confused but while all this bickering is going on something kind of interesting happened. This game Machine Narrium which is a puzzle exploration game featuring robots and some really cool art took a number one spot on the iPad paid app store. So number one on iPad, this is on Apple Store. The interesting fact is that this game was actually created in Flash. It had been around on the web for quite some time as a Swift and they simply transcoded it to run from Flash Professional on an iOS device. So while all this bickering was happening Adobe had figured out a way to allow you to publish from Flash Professional directly to the Apple iOS environment. It was a pretty cool piece of tech that they built. Apple figured out what was going on after awhile and turned it off so you could no longer do it. Even though the feature existed in Adobe Flash Professional you couldn't actually run it on the iOS Store. They would just boot it before it ever got there. So that lasted for about six months and then they went the other direction and they allowed it again. So it was in their best interest because they were really just turning off a bunch of developers that could potentially create content for their store by not allowing people to publish from Flash. And this feature actually still exists today. If you wanna open up Adobe Flash now and publish for the iPad or for an Apple phone you can do that and it works pretty darn well. So again, we're thinking as Flash developers as a big community that have been backing Adobe for a very long time that things are going well. We can publish to iOS. Maybe there's hope that Flash is gonna continue to live on. And just when we thought things were going okay, this happened. Adobe made an announcement on November 9th, 2011 that they would stop development on the Flash Player for mobile and focus their efforts on creating mobile experiences using HTML5. So imagine you've been working in this tool for 10 years and suddenly the company that you've been backing you're part of the community in you run a user group for makes this announcement that they're gonna stop back in the tool that they've been fighting tooth and nail to get on all the mobile devices. Needless to say, the community was both confused. We felt kind of abandoned. There was a lot of interesting blog posts and tweets going on that day. And a lot of it came down to fear. And this is something I kind of realized later is that again, we'd been married to this tool. This is what we knew how to do. A lot of us made our livelihoods using this technology. And suddenly we're being told that they're gonna go another direction. Where does that leave us as developers? We know ActionScript, we know Flash. We know how to create some really interesting applications using it. We don't know much about JavaScript or HTML5. Most of us have some understanding of it but we don't know the deep down layers of it. And the idea of having to unlearn everything we'd learn in ActionScript to go back 10 years in time and relearn JavaScript was just kind of a painful concept. But again, there was some hope for this whole HTML5 thing, which we'd get into later. So let's fast forward to 2015. HTML5s had a long time to mature. The early days of simple canvas elements and video players are behind us, thankfully. And we've come a long way. So let's look at some of the features now that were potentially influenced by some of the things that came from Flash but that are currently available in HTML5. So first, going back to ActionScript 3 versus JavaScript. JavaScript still hasn't come that far as a language. I'm happy to hear talks at this conference even talking about the future of ECMAScript and how that's gonna change the way we program with JavaScript on the web. But I have to give a lot of credit back to the JavaScript developer community because in the last several years there's been a huge number of frameworks and libraries that have come out that allow us as developers to really develop in an easier way and in a more manageable way. So things like Ember and Backbone and Angular allow you to develop much more complex applications in a more manageable fashion. Node.js allows you to develop JavaScript applications on the server side. I mean, who would ever thought that would exist? jQuery, you know, been around forever allows you easier access to the DOM and things like CoffeeScript just make it faster to develop. So some really cool stuff going on there but again, the future is even brighter because they're finally starting to work on ECMAScript as a language or JavaScript as a language. Animation. So I mentioned that there was some simple stuff going on with Canvas and HTML5 and animation. The Canvas element and the drawing APIs and HTML have come a long way. This game here, Pirates Love Daisies is a tower defense game that was created by Grant Skinner's company. The interesting part about that is that Grant Skinner was actually an icon in the Flash development space and it was at Adobe Max 2011 when he actually gave a talk about building this game. So I'm sitting in the audience going to a Grant Skinner presentation expecting to hear all these cool things about Flash and here he is talking about that darn HTML5 thing once again. Again, I was kind of confused but in watching Grant, it was kind of clear at that point that there was something behind this. He had created this whole game that he would have normally built in Flash using HTML5 Canvas but along the way he had had to create a whole slew of libraries just to help him in building this which one of the things that came out that was a thing called EZL.js which was later developed into Create.js and that's just a suite that helps developers who are accustomed to things like animating in Flash come over and bring that same tool set over to HTML and that'll be important a little bit which we'll get to. 3D animation came later on. So WebGL JavaScript API allows you to create hardware-accelerated 3D graphics that are mobile optimized. So this is a game called Hello Run it's a runner game I guess but the point here is that the graphics are pretty amazing and they run just as well in mobile as they do on the browser on your desktop. Audio and video, we talked about this a bit earlier so this is the new audio element as it stands today allows you to simply add video or audio content to your web pages using native HTML. If you wanna add controls it's a simple attribute inclusion and it's very simple to use. Video is the same thing. Again controls are available that stuff we talked about with the components set being available in Flash to allow you to quickly create Flash video players is now available in HTML5. So again we're taking a step in the right direction. Components, you know jQuery UI and a number of other libraries and frameworks out there that let you use some very rich components like accordions and modal windows but there's some new technology coming out for web components which are even more interesting to me. And this will actually let you create your own components set in HTML so you define what the element name is and you can actually create the functionality so you can reuse it across your applications or share it with other people on the web. And this is an example of Google Map they actually ported that over to use the new web components architecture. So you can see here it's defining a Google Map element with a latitude and longitude attribute and then internally they've got additional elements for Google Map marker. So if anybody here has tried to use Google Map APIs previously there's a lot of configuration that goes on and it takes quite a bit of code to get something like this to work whereas maintaining something like this on your website would be a lot easier with simple element inclusions. Hardware access, so again I mentioned this was a huge thing in Flash and here we have it now in HTML in JavaScript. Things like get user media allow you access to the microphone and to the webcam. So as a developer in JavaScript now you can access those same APIs that we used to have in Flash and start playing around with them. And a lot of these elements came together to bring us WebRTC. Now this is kind of a new technology that's still being built up by Google and Firefox and Opera actually. And IE's kind of coming out with their own version of this so they're leading the tail end of it but they're finally coming around. Basically WebRTC allows you to establish a peer-to-peer connection across various network topologies. So it doesn't matter if the person you're talking to is behind some crazy firewall and you're on a public network at a coffee shop you should still be able to connect. And all that tech that figures out basically how to connect two browsers peer-to-peer is included in WebRTC. So things like video calling, audio calling, even web-to-phone and phone-to-web are now available as part of this stack. Screen sharing's another feature. And just to give you guys a little better idea of what people are doing with this let's take a look at a couple of the applications that people have created so far. So you may have seen some commercials a while back for Amazon Mayday service. This service basically allows you to hit a button on your Kindle and be talking live with apparently a very friendly customer support representative. It also gives them access to draw and access elements on your screen so they can help you figuring out troubleshooting issues. So this uses WebRTC. Google Hangouts used to be a plugin-based system now it uses WebRTC so they're kind of eating their own dog food there which is great. Allows for video calling, screen sharing. And I should mention this is all native in the browser. There's no plugins required, this just all runs. So as long as you have a browser that supports WebRTC which again is kind of growing as we go you can use this and your users can too. Pure CDN was a really cool idea. It's basically a simple JavaScript library that uses WebRTC to create a CDN of the users on your website. So if you have a bunch of static assets images, video files, PDFs, whatever it may be this JavaScript library basically scrubs your pages to find those files and then finds the users that are accessing your website and connects them peer-to-peer. So if one person downloads all the files and other people come to join the site they can then distribute those across a peer-to-peer connection to the other users. Thus saving you a lot of money in bandwidth. You can see here there's some numbers. I don't know how pertinent those are here but they can show you exactly how many terabytes and how many megabytes you've saved as well as the amount of money you've saved. And these guys actually got bought by Yahoo rather recently. So you might see some cool stuff coming out from that. CubeSlam was a game that Google threw together as a proof of concept. It uses audio and video as well as exchanging game data across peer-to-peer connection. So it's a simple game of POM with video as the background and then audio communications. But it exchanges all that data, the game data, the positions of the paddles on the screen, the position of the puck, everything across the WebRTC peer-to-peer connection. So again it's using one API to exchange all that game data without having to spin up a server and host some third party library to actually handle all the game data interaction. And it's also saving you a ton of money and bandwidth again there. This is Apollo. This is a game we created internally at the company I work for for doing communications with our distributed team. So it's sort of like a bigger version of a Google Hangouts with some features that we wanted. So things like group chat, single chat, video and audio calling as well as file exchange, my favorite feature. You can actually copy to the clipboard using like a screenshot and paste it into the chat window and allow them to automatically share it out with the rest of the people that are included in that group. So I mentioned Respoke, just a real quick plug here. We do simple WebRTC stuff. So if you're ever looking to play with this and you don't want to spin up your own servers, we have a JavaScript platform that allows you to easily start adding things like video calling into your applications. So you can check us out at respoke.io. So Flash, kind of a recap. You know, why did HTML5 win over Flash and then kind of what happened to Flash over the years? The biggest thing is that HTML5 is native and it runs extremely well across all devices. So Flash's big failure was really in the ability to have it run smoothly and consistently across all the mobile devices, tablets, the phones and the desktop. They did a pretty good job. You know, I wouldn't say that Apple shut them down. It certainly didn't help. Obviously they found a workaround for it, but at the end of the day, there's a much larger community of front-end developers and JavaScript developers that can play with this technology. So having things run, you know, in HTML5 just exposes it to a larger audience of developers and it makes it more available to a larger number of people. So Flash, as I mentioned, not quite dead. Sort of rising from the grave. This animation here, what do you think I used to make this? Shout it out, anybody. Nailed it. So I actually created this in Flash. No, if I can show you guys, we're kind of running out of time here, but basically, Flash went a different direction. They learned from what was happening. You know, people wanted a different experience. HTML5 was the winner. That's what they chose to back. So they chose to actually pivot and learn from their mistakes and from what was coming up next to kind of stay relevant. So now in Flash, you can actually publish all of your HTML or your Flash content, your timeline animations, your scripted animations, all to HTML5 content. So it uses the canvas. If you remember what I was talking about, Grant Skinner earlier, creating that game with easel.js and the create.js framework, Adobe actually worked with Grant Skinner to include that create.js framework as part of their Flash publishing platform. So when you publish from Flash, it actually converts all of your action script code, your timeline inclusions, and all of your assets to be native HTML5 content. Using the canvas and using create.js as the library that then transitions all that stuff over to JavaScript and HTML. So what the end result is, is you get an HTML file and a JavaScript file, which you can then edit to your heart's content. And it's all written using that create.js platform. So if you want to go in and start playing around with it, use Flash as a simple tool to get you some basic animations or some prototyping, the end result is going to be JavaScript and HTML, which you can then edit and play with from there. So kind of to recap everything here, the big thing I want you guys to take away from this, and this is sort of a theme I've been happy to hear from a lot of talks at this conference is really never stop learning. You need to keep pushing yourself forward. Adobe did that when Flash kind of lost out to HTML5. I had to do that when my business was forced to be changed to more of an HTML5 focused business. So I just want to challenge everybody here, set aside an hour a week, just one hour, block it off on your calendar, turn off your cell phone, lock the door, whatever you got to do, and just spend that time really trying something new, whether it's a framework or doing what John suggested yesterday doing some creative coding or playing with a new piece of hardware, or even just going out and learning a new sport, whatever it is, try something new and keep learning because it's going to push you to be a better developer and just a better human being, really. So that's it for me. My contact info here, ktaiakitrespoke.io. You can catch me on Twitter at geekgonnomad and my website's under the same with a .com on the end. I'll open it up to questions. So the question was about the differences between ORTC, which IE is developing and WebRTC, which everybody else is developing. The answer is I really, really hope they're going to be similar, if not the same. Some of the proposals that IE has made have actually been folded into the WebRTC spec. So some of the stuff they're actually finding as potential issues or things they want changed are actually good suggestions. My real hope is that eventually they'll get on board in some later version of the spec. I've heard some talk that they're basically waiting until it's a little bit more finalized or standardized to implement in their browser. So my hope is that this ORTC thing is just their sort of way of getting their suggestions across and that eventually they're just going to take the full spec and implement it as is. I won't hold my breath on that one, but I'm really hoping for it. So if anybody wants to talk WebRTC, I'll be around the rest of the day. Feel free to grab me and I'd love to chat on it with you. Thanks.