Everyone stop what you're doing and put down the Javascript. We're going to show you how you can level up with the fundamentals of web development. I'm Colby Fayock, I'm the one hug, BB and Kylo Ren over there. I work on the UX and front end side of things at element 84. You can find me pretty much anywhere on the web by just googling my name as I'm the only one in the world. We're going to start with the story here we have two people at the beginning of their career. On the left we have Mark. He's a jolly fellow, he likes the color red. And on the right we have Luke. He's Mark's brother, he's more of a green kind of guy. Both of our friends are trying to switch their careers and they're going to give coding a try. So they both try to find a boot camp to dive right in. First we have Mark. Mark found this cool bootcamp that promises to make you a JavaScript ninja. Better yet, it only takes one month. They make sure they teach you the most popular frameworks available right now. This will make you super marketable. Trend we have Luke. Luke took a little bit of a different route. He found the course that takes a little bit longer, but he'll know how to build a whole website with just HTML and CSS. He'll also learn some Javascript, but they didn't promises any specific framework. Both of youre friends decide to submit their resume for a job at Oneup Inc. It's a junior front end dev position. The description for both of them is a near perfect fit. Luckily they both get a call back for a code challenge. Once they get on a call they'll find out that their task is to take this mockup and transform it into a website. They'll have about 45 minutes to do this and then afterwards they'll talk about their work. Not too bad, right? So first up is Mark. This is easy for Mark, he just got but of boot camp where he learned how to use react and the job posting says they want react so that's perfect. Then he'll use it to build a challenge. He can also use some CSS and JavaScript. He recently read a little bit about that and it should be pretty easy to integrate for a quick win. Then we have Luke. He again also takes a little bit different of a route. The website looks pretty simple, right? So he thinks he can do it with some plain old HTML, layer on a little bit of Css and that should do the trick. So let's compare the solutions. See, Mark didn't really get super far. He only got a little bit. He only got the title. Luke seemed to get pretty far. It's not perfect, some mismatched colors and sizes, but it's a good start. So what happened with Mark? Let's just say that Mark didn't have a great interview. First, Mark tried to get a react app going. He forgot that he needed to configure a package manager in order to install react. Okay, so moving past that, he thinks he figured it out. He was able to quickly look up an example. He can add some external scripts to load react. Now he can get moving, but dang, that can't load in the browser. That's not native Javascript. Great. So he figured out that he can include Babel. With that he can add the Babel type to the script, and now he can use JSX. He's in business. But oh man, we're still getting an error. Let's check the react docs quick again. All right, he needs to wrap it and create element. Awesome. So that should work. And it does. So now we can start getting moving on the website. So Mark adds his header and it renders and we're making progress. But then he realizes that he needs to add styles to make it look right. He can't install it from NPM. So again he's being to have to look for an external link again. But oh no. By the time that he actually found a solution, he ran out of time. He spent so much time debugging this setup that he never actually had a lot of time to build the site. On the other hand, Luke broke out his favorite text editor just like Mark did. But instead of trying to deal with the packages, he just started with some basic HTML to create a header. He knew he was able to throw together a few HTML elements. He used the header and the nav tags, and nice and semantic for the content. He added a main tag, an image and some text. Figured he could use some CSS to position it all correctly. So he did. He added some styles to make it look right. Flexbox makes this nice and easy to do. So he flexed the header, flex the body content, flexbox, all the things, and he was good to go. And with all of that, Luke ended up with a lot more progress than Mark. So of course he landed the job. He had something to talk about over those last 15 minutes. He went over why he chose Flexbox, why he used the header and the nav tags. He talked, but what he could have done next to fix some of that style. On the other hand, Mark was still stuck at the beginning. He didn't have much to talk about. He was stuck trying to fumbling around with the project with react. The truth of this is that the story is only slightly exaggerated. I didn't use real names or likeness, but this situation happens exactly like this quite often. Of course, someone super experienced with react might not have hit these same roadblocks, but I've personally sat through interviews watching candidates struggle through these exact same types of challenges, and this situation isn't unique to react. This is pretty much any JavaScript framework. But job seekers come into can interview wanting to impress everyone by using the latest, coolest tools, and I totally don't blame them, but they only set themselves up for failure. And while every company, every candidate, and every interview are each unique, there's a common thread. It's easy to want to jump in and learn exciting new tools, and that's not even necessarily a bad thing. Part of why I love what I do is because it's fun. It's the kind of thing that keeps me inspired. But dealing with an interview is stressful in the first place. And while not every interview is going to wind up like that, we can set ourselves up with a good foundation which will let us have a better understanding of the tools that we're working with. So we're going to talk about how we can level up, we're going to talk about why these things can make a difference, and we're going to learn some cool tricks along the way. So we'll start with HTML. I would imagine most of us have at least heard of HTML before, but what exactly is it? If you didn't know, it stands for hypertext markup language. It's the essential building block of all website, and it has been since probably before most of us have even heard of HTML. A lot of us probably don't have to write this by hand anymore, given react and other libraries do it for us. But this is the basic skeleton of a web page. We have our doc type HTML tag head and body with a simple h one. We're probably more familiar with this, though. The actual skeleton of our page gets abstracted away. We define our page pretty much only by the content, so instead of our HTML in our head, we might only see that h one. The cool thing about react and JSX though, is we can really write any HTML we want. For the most part, it's going to be valid. This isn't groundbreaking, but it sets the tone for some of the points ahead, but ultimately JSX gets compiled down to HTML, the same HTML that we can write by hand. We just now have tooling to provide us with a better way and more efficient way to generate it. So that Gatsby app that you spun up, yeah, that's creating a bunch of HTML. Next we'll talk a little bit about CSS. A lot of us probably know that as the magic that the web design team creates. I've actually heard backend developers say that they're afraid to touch it. So what exactly is CSS? CSS stands for cascading style sheets. We have a simple example here, setting the color to red like Mark's outfit, changing the font size and making all the letters uppercase, and bringing this into a react we have a few options. Personally, I'm still a fan of writing my CSS outside of my Javascript. I like to supercharge it with SAS, but I know a lot of people like to write their CSS in their JavaScript, and there's a ton of libraries out there to do just that. But similar to the HTML we saw before, this all gets compiled down to our basic CSS. Regardless of the type of tool we use, whether it's SAS or CSS and JS, this is ultimately what we get. The only difference is how it's served, whether it's an external link, embedded or in line. And though a lot of this might not be new to people, aside from the gasp I heard when I said that I write my CSS outside of my Javascript, but it's important to understand the foundation and how these basic things work. Like did you know that the browser has actually fixed the HTML for you? This can be really helpful, especially when starting out, but it can also be confusing if youre don't really understand what's going on. Like here, you can't nest a div inside of a paragraph tag. Particularly you can't nest another block level element inside of a paragraph tag. So the browser tries to fix this for us, but this actually messes up our intent. Here we were expecting the div to also be purple, but because the browser fixes it, it pulls the div outside of the paragraph tag and the paragraph style no longer cascades. Or that in CSS the vertical padding is actually relative to the width. Ignore the jankiness while trying to show the animation here, but we can take advantage of this little quirk. Sometimes your best option is to use a background image, but the tricky thing with that is that it can't scale the width and height easily like we can an actual image. Instead, what we can do is set the height to zero, which is a little bit strange. But then we can use the width divided by the height and percentage form to set a vertical padding. So this way, no matter the width, the height will always be the correct ratio. So what's the point I'm trying to get with all this? While those things are handy, to know, those two things alone won't make you a better developer. But what I'm getting at is understanding your tooling from a more fundamental level will help you level up your game. So how can we do that? The first thing we can apply this to is SEO. Many of us probably have heard of this in one form of another, but might not understand what it is. SEO stands for search engine optimization. It can be super complex with keyword research and strategy, but we're going to focus on this stuff that we can control as developers. So our ultimate goal with SEO is to present our content in a way that makes it easy for search engines like Google to understand. The most important part here is content, but it also includes the tags you use to present that content and metadata you use to make it look right in the search. Most websites have a healthy mix of different ways for people to get to their site. Some might be ad traffic, others social media. But there's also people trying to look for something in a search engine who could potentially find your site at the top of that list. This helps bring in more traffic, which could ultimately help your website or company grow. Like here. Aside from the free codecamp article, my traffic from my website pulls in the most from organic search. Of course, my modest blog doesn't really get the most traffic on the Internet, but how you create your page matters. For example, if your website is a bunch of images with no alts or text anywhere, how is Google going to be able to know what your website's about? So what can we do better? Well, we can try to be more conscious about the HTML we use when creating website. More often than not, it doesn't take much more effort to use a different and more meaningful tag. One thing you can try to do is maintain a logical page outline for your website. You shouldn't have every single one of your titles as an h one. That's not helping anybody. But similar to what you would see in a bloke, you can organize your content h one through h six. What this does is queue the search engines to the hierarchy of your website it's helping to answer what information belongs under what title. Here we have two examples of image tags. The top one doesn't have any alt value, but our bottom one has a description of what's happening in the image. What do you think is more likely to show up on a Google search? By providing that alt value, we're letting Google know what that image is. It's adding more content value to the page and ultimately helping us in our searches somewhat. Similarly, anchor tags are important for how Google reads your page. It might be easy to tack in a read more link after a paragraph, but when search engines crawl your page, they look at what the text is to try to find out more context about that link. Using the same text everywhere like read more isn't really helping. Instead, we can add links to the descriptive parts of our page with the text that we already have. We can make it easier for Google to understand those. And if you go to your website and click around and you look at the words in the browser tab, does it say the same thing for every single page? The tag that controls this is the title tag, and it's more important than just the browser tab. This is what controls the text that shows up on Google. Google's getting pretty smart at adding context about the pages, but chances are it's not going to consider your links as valuable if every single page shows with the same name of your blog instead of what the page is about. Next, we'll talk about accessibility. And accessibility is probably one of the more meaningful points here. A good high level summary of what accessibility is is how usable your website or app is. For all types of people, this is regardless of any type of disability. So that means can someone with a being disability still use your website? Each of us as developers, are responsible for how our creations are being used. The World Health Organization estimates that 15% of the world has some sort of disability that's over prone billion people. Okay, so the whole world isn't going to be using my site, but how about those 2400 users that visit my website so far this year? Just hypothetically, if 15% of those people had disabilities, that's over 360 people. That's still a lot of people. Imagine websites for businesses like ecommerce that make money from their website, or websites that people need to help them live. These are real people who can't use your website because nobody paid attention to it. For businesses, that's a loss of money. But for people's needs, that's a prescription that they're having trouble building. We should all take responsibility for the work that we create. It's just the right thing to do. So what can we do to help our neighbors and friends? Well, we can try to learn about the different types of disabilities that people face when using the web. We can try to be conscious about the decisions we make. Just like SEO, more often than not, it doesn't take much more of an effort, if at all, to develop with accessibility in mind. Remember that page outline from before while optimizing for SEO. By using proper semantic HTML, you're actually helping your screen readers understand the hierarchy of your website. As a screen reader is moving up and down the page, it's able to jump over sections that somebody might not be interested in. Imagine this is going to be really difficult if every single one of your headings is an h one. So remember our image alt example from before. See a thread here. A lot of times when we write proper semantic HTML, we're going to end up providing value in more ways than just one. Here. If a screen rater lands on one of our images, the person will actually be able to get to hear what the image is about. It's just another low effort way to help everyone experience our websites. Lists are also a practical use of HTML that's used across the web. But far too often I see code that's logically a list and they're not using HTML list elements. Next time you create a navigation for your app, don't use a bunch of divs, use the actual HTML list elements. This will help assistive technology actually assist the people who's using it, and they're not going to be much harder to style. Set your style and your list element to none and you're practically where you were with a div. Buttons are also another important aspect. While you can get by with a div, there's a lot more to do to get that to a place where it becomes usable. And oftentimes when I see people using a div, they don't take that into consideration. With a div, you get nothing by default, but with a button, while you typically override it, you get some styles that make it look like a button. You get a CSS cursor that makes it look clickable. You get an HTML element that people can use with their keyboard by tabbing and hitting enter. And did you know that by default, when nested inside of a form, a button will actually submit a form all by its own? This is handy for a variety of things, like not having to worry about setting up specific event handlers when trying to submit your form. The point though is that along with the rest of HTML I went over, this isn't much more difficult to use. We just need to become a little bit youre conscious about the HTML we're using and get in the habit of starting to use it. And lastly, we'll talk about simplicity. So what do I actually mean by simplicity? We don't always need extravagant solutions to get our code to work the way we want it to. Sometimes there's a simpler way to do things that we're struggling to do with JavaScript. This is probably an exaggerated example of the padding top solution. Hopefully I got the math in there a bit right, but it shows the difference on how some CSS can replace all that Javascript logic. Bonus. At least in this case it's likely to be more performant and bug free. Now there's absolutely value in learning by doing. If you want to use a bunch of complex tools to build your blog, that's a great low risk way to learn those tools. I even encourage it. It's a way to try new things and learn without actually breaking things. I lost count of the amount of times that I rebuilt my website before I settled on my current simple one. But from a work perspective, whether it's a client or from your company's website, try to think about the solutions in terms of what it will solve. Is that extra Javascript worth the additional load it's going to take in the browser? How much time am I going to really save with these tools? So what are some ways that we can keep things simple? You don't need to rewrite the HTML spec every time you want to add a new component. More often than not, the Javascript you write means that the more JavaScript you ship, which can impact the performance of your app, use what we already have. It's also less work like here you can use the data list element, which provides a basic autocomplete feature for an input. You also don't need JavaScript to create a really simple loading animation that you might see on some of your favorite websites. Using some CSS we can use a gradient and animation to create this effect. It's just this small civic here. Better yet, we have it as a class, which we can extend to any element on our page. And while sometimes we need to maintain the state of our components, sometimes we don't. If we're only maintaining that state to style, we can instead use a checked attribute on our input to change how it looks. Here we're simply showing different text depending on if the input is checked or not using pure cSS if I asked you before seeing this how you would make some text responsive, how many of you would jump right into Javascript? We can actually do this quite nicely with some simple css here I'm setting the font size of our h one to ten viewport width. It might look a little choppy in the slides between saving it out as a gif and presenting it, but I promise you it's buttery smooth that way. It scales really nice and evenly inside of our browser. Bonus if it gets too small, we can set some media query breakpoints and keep it all within our css. And as much as there's some practical good things about the fundamentals, people are also building out some awesome things with just some HTML and CSS. This is important because it helps remind us what we can do with what's already out there. It's important because it helps us keep pushing the boundaries of what we can do with native tools. There's massive work underway with CSS. If you haven't heard of Houdini yet, you should definitely look it up. And this is beyond the tools that we already have. I believe the progress wouldn't be happening if we just didn't, as developers keep constantly pushing these tools. So it can be important to have constraints that promote creativity where you least expect it. Like a trend on codepen to try to come up with some pure CSS solutions. It's not just challenging, it's fun. Like it seems like all the talk about cake is breaking the Internet. So Adam put together this pen that makes anything into cake. The only Javascript in this pen is to upload an image, but once it's uploaded, the rest is HTML and CSS. That gives you this effect. When you hover over the image, it splits open for you to take a piece. Or this pen from Lynn. It's a CSS only collector's cabinet. I love all the incredible detail put into it, and you can keep looking around and finding new things. Elad made a coronavirus game. You're able to fight the pandemic by clicking each virus. There's no Javascript in here at all, it's all CSS. Elad uses some inputs and makes the CSS loops to create different animations. This gives us our virus with the ability to interact. And I have to include one of my own, right? I immediately haven't picked up a code pen in a while. This thing's actually six years old, but the story goes, I was watching alien for the first time, and I stopped watching it because of the title scene. That's because I ended up spending the rest of the time trying to recreate it in CSS, and I still have yet to watch it. But just to clarify, I know there's a little bit of JavaScript in there and it's just to provide the handy restart button, but it was fun and challenging and it might not be practical for every solution, but I can apply this to other work like micro animations and providing delightful animations in my work. So now that you're all inevitably inspired, how can we get back to the basics and learn some of the fundamentals? Freecodecamp is a huge community of learners who are trying to teach themselves to code. They have some great courses, free of course, and that starts with responsive web design. It's a great place to begin if you want to start digging into an actual course. Egghead also has a huge library of lessons and courses. You can learn anything from accessibility to full blown apps. All the instructors I've worked with there are super smart and really great at helping others learn. YouTube also has a ton of great content that's ready to watch. Freecodecamp even has their own channel there. But there's a lot of individual content creators like me who are posting amazing stuff every single day. And similar to YouTube, Twitch has a ton of great content, and it seems like there's another awesome developer that's starting their own streaming channel every single day. You can get a live walkthrough of how they build these things, and bonus, you can hop in, chat and maybe ask a question or two if you're stuck. And Codepen. I feel like Codepen really changed the game with CSS proof of concepts. It's incredible to see what you can find browsing around. And it's not just HTML and CSS, there's a ton of really advanced JavaScript work, and best of all, you have the code immediately that you can fork and start playing around with. So how are you feeling after all of that? I still hope you're inspired. There's a ton you can do without diving headfirst right into JavaScript. If you take all these things into consideration, you're not only going to be better off as a developer over youre not only going to help yourself by avoiding over engineering solutions, which can typically bring on more stress, but you're also going to help yourself bring more traffic to your projects and help others use them. And that's it. If you want more, you can find me at Colby Fayock everywhere. I put out weekly tutorials and videos and also tweet out some links to my resources from this talk. Thanks everybody.