Video details

Put Down the JavaScript | Colby Fayock


Colby Fayock

Colby will be talking about putting down the javascript. Bootcamps and tutorials tend to throw those curious to learn right into Javascript. They ignore the fundamentals of web development missing key pieces to the puzzle of the web. He’ll show us how the basics of HTML and CSS can level up your Javascript and enhance SEO, performance, and accessibility.


Everybody stop what you're doing and put down the JavaScript, we're going to talk about how you can level up with the fundamentals of Web development. So who am I? I'm going back. I'm the one hugging BBA in Colorado over there. I work on the U.S. front and side of things that eleven eighty four. You can find me pretty much anywhere on the Web like Twitter and YouTube by just Googling my name as I'm the only one in the world. So 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 we have Luke, who's Mark's brother. He's more of a green kind of guy. Both of our friends are switching their careers and they're going to give Cotting a try. So they both try to find a boot camp to die right in. First, we have Mark, Mark found this cool boot camp 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. So this will make you super marketable. Then we have Luke, Luke took a little bit of a different route. He found a course that takes a little bit longer, but he'll know how to build a whole website with just HTML, and he'll also learn some JavaScript, but they didn't promise any specific frameworks. Both of her friends decide to submit their resumes for a job at one I think it's a junior front and dev position description for both of them is a near perfect fit. And luckily, they both get a callback for a good go challenge. Once they get on the call, they find out that their task is to take this mock up and transform it into a website, they'll have about forty five minutes to do this after they'll talk a little bit about their work not to at. So first up is, Mark, this was easy for Mark, he just got out of a boot camp where he learned how to use react and the job posting says that they wont react. So it's perfect and that he'll build the next chances that he can use some 6000 jobs. And he recently read about that a bit. So it should be pretty easy to integrate for a quick win. Then we have Luke, he again decides to take a little bit of a different route, that website looks pretty simple, right? So he thinks he can do it with some plain old age HTML layer on a little CNS and should the do the trick. So let's compare solutions. Well, Mark didn't get super far, he only got the title Loop's seemed to get pretty far. It's not perfect, some mismatched colors and sizes, but it's a good start. So what happened to Mark? Well, let's just say that Mark didn't have a great interview, first, Mark tried to get a react up going, he forgot that he needs to configure a package manager to actually install Reactant PM. So moving past that, he thinks he figured it out. He was able to quickly look up an example of where he can add some external scripts to load react. Now we can get moving. But then that can't load in the browser, that's not native JavaScript. All right, so he thinks that he figured out he includes babble, but that he can add the babble type to the script tag and he can use some gas and now he's in business. But oh, man, we're still getting an error. Let's check the react again quick. 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 and build the actual website. So, Mark, as a senator and a renters, we're making progress, but then he realizes that he needs to also add some styles to make it look like he can't install it from AMPM. So he needs to find an external link again. But oh, no. By the time he actually found out a solution, he ran out of time. He spent so much time debugging that set up that he never actually had the time to build out 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 with MBM, you just start with some basic HTML. To create a header, he knew he was able to throw a few simple elements together, use the header and the nav tags, nice and semantic. For the content, he added, a main tag, an image and some text figured he can use some success to position it all correctly. So he did he added some styles to make it look great. He Foote's Xbox makes this really nice and easy to do. So he likes the header flex of the body content like Xbox, all the things. And he was good to go. With all of that, Luke ended up with a lot more progress than Mark, so of course, Luke lands the job argument over why he chose Flex Box whenever why he used the header of the Naftogaz. He talks about what he would have done next in order to fix some of the styling issues. On the other hand, Mark was still stuck at the beginning. He didn't have much to talk about. He was still stuck fumbling around, starting with the project with React. So the truth is this story is only slightly exaggerated. I didn't use real names or likeness, but this exact situation happens quite often. Of course, someone super experienced with REACT might not have hit those same roadblocks. But I've personally sat through interviews watching candidates struggle through these same types of challenges. And this situation isn't unique to react. To be clear, this is pretty much any JavaScript framework. This is. But job seekers come into an interview wanting to impress everybody by using the cool tools, and I totally don't blame them, but they only set themselves up for failure. So while every company, every candidate and every interview are each unique, there's a common thread. It's easy to want to learn the new exciting tools and jump right in. And that's not necessarily even a bad thing. Part of why I love what I do is because this stuff is 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 you can level up. We're going to talk about why these things can actually make a difference and we're going to learn some cool tricks along the way. So we'll start with, you know, I would imagine most of us have probably at least heard of, but what exactly is it? If you didn't know, stands for hypertext markup language is the essential building block of all websites, 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 much anymore, given react another UI libraries do it for us. But this is the basic skeleton of a web page. We have our DOCTYPE, our email tag and body with a simple one. We're probably more familiar with this, though, the actual skeleton of our page gets abstracted away, so we define our page by only the content. So instead of our Timlin head, we might only see our one. The cool thing about reactant, though, is we can really write any time we want, for the most part, it's going to be pretty valid. This isn't groundbreaking, but this is kind of setting the tone for some of the points ahead. But ultimately, the statistics, it's compiled down to the same e-mail that we can write by hand, we just now have some thulium that can provide us with ways to generate more efficiently so that Gatsby or next asset that you spun up. Yeah, that's just creating a bunch of Temel. So next, we'll talk a little bit about success. A lot of us probably know this as the magic that the Web design team creates. I've actually heard some developers say that they're afraid to touch it. So what exactly is success? It stands for cascading stylesheets, we have a simple example here, we're setting the color to red like Mark's outfit, changing the font size and making all the letters uppercase. And bring this in to react. We have a few options. Personally, I'm still a fan of writing my CSFs outside of my JavaScript. I like to supercharge success, but I know a lot of people like to write their success in their JavaScript. And there are a ton of libraries out there to do that. But similar to the e-mail we saw before, this all gets compiled down to our basic access, regardless of the type of tool we use, whether it's SAS or CSI and this is what we ultimately get, the only difference is how it served, whether it's an external link embedded or in line. So a lot of this might not be new for people, aside from the gasp I heard when I said that I write my success outside of my JavaScript, it's important to understand the foundation and how these basic things work. Like, did you know that browser's actually fix the e-mail for you? This can be really helpful, especially when starting, but it also can be pretty confusing if you don't really understand what's going on like here. You can't nested inside of a paragraph tag particularly. You can't nest another block level element inside of a paragraph. So the browser actually tries to fix this for us, but this actually messes up our intent here. So we were expecting the Divx to also be purple, but because the browser fixes it, it pulls that div outside of the paragraph tag and the paragraph paradoxal no longer cascade's. Or that in case the vertical padding is actually relative to the width, ignore the genuineness that I'm trying to show here with the animation, but we can take advantage of this little quirk. Sometimes your best option when creating with images is to use a background image. But the tricky thing with that is we can't scale the width and height easily like we can with an actual image. Instead, what we can do is we can set the height to zero. Then we can use the width divided by the height in percentage form to set vertical padding. So this way, no matter the width, the height will always keep the correct ratio. So what's the point in this that I'm trying to make? Well, 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? So the first thing we can apply this do is stop many of us have probably heard this in one form of another, but maybe you might not understand what it is. Echo stands for search engine optimization, it can be super complex with keyword research and strategy, but we're going to focus on the stuff that we can control as developers. So our goal ultimately with ASIO is to present our content in a way that makes it easy for search engines like Google to understand. The most important thing here is the content, but it also includes the tags that you use to present that and the metadata that you use to make sure that it looks right in search. Most websites have a healthy mix of different ways for people to get to their website. Some might be ad traffic, others social media. But there's also people trying to look for something in search engine who could potentially find your site at the top of that list. This helps bring in traffic, which could help your company and your website grow like here. My website pulls in the most traffic from organic search just above Frico Camp Digg. Of course, my modest blog doesn't get the most traffic on the Internet, but how you create your pages matter. For example, if your website is a bunch of images with no call or text anywhere. How is Google going to be able to know what your page is about? So what can we do better? Well, we can try to be more conscious about the e-mail we use when we're creating websites, 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 of your website. You shouldn't have every single one of your titles isn't each one that's not really helping anybody. Instead, use each one through age six to organize your content, similar to what you see in maybe like a book. What this will do is use 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 an image tag, the top one doesn't have any value at all, but our bottom one has a description of what's actually happening in the image. What do you think is more likely to show up in a Google search, but providing our oh, we're helping Google to understand 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 on a read more link dynamically after a paragraph, but when search engines crawl your page, they look at the text of the link to try to find out the context about each of those links. So using the same text everywhere, like read more isn't really helping. Instead, we can add links to descriptive parts of our text where we already have something. We can make it easier for Google to understand what those links are about. If you go to a website and click around and you look at the words in the browser tab, does it say the same thing for each tab? The tag that controls this is the title tag, and it's more important for just that browser tab. This is also what controls the text that shows up on Google. Google is getting smarter, adding more context about pages, but chances are it's not going to consider your links as valuable if every page shows the same exact name of your blog instead of what that page is actually about. All right, so next, we'll talk about accessibility, accessibility is the 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 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 percent of the world has some sort of disability that's over one billion people. All right. So now the whole world isn't going to be using my personal website, but how about those 12000 people that visited my website so far this year? So just hypothetically, if 15 percent of those visits where people with disabilities, that's still over 18 hundred people, that's a lot of people imagine websites for businesses like e-commerce that make money from their website or websites that people need to help them live. Those are real people who can't use your website because no one 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 filling. 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 friends and neighbors while we can learn about the different types of disabilities that people face when using the web, we can try to be more conscious about the decisions that we make, just like CEO. More often than not, it doesn't take much more effort, if at all, to develop with accessibility in mind. So remember our page outline from before, while optimizing for SEO by using proper semantic HTML, you're also helping screen readers understand the hierarchy of a page as a screenwriter is moving down a page. It seems to jump over those sections so that a person that might not be interested in particular content can get through it. Imagine this is going to be really difficult if every single one of those headers. This is an H1. And remember our image example, see a thread here, a lot of times when you write your e-mail properly, you're going to end up providing value in multiple ways here. If a screen reader lands on one of our images, the person will actually get to hear what that image is showing. 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, the far too often I see code that logically is a list that is not using the HTML list elements. Next time you create a navigation for your app, don't use a bunch of device, use the actual list elements. This will help assistive technology actually assist the people using it and they're not much harder to style. Set your lifestyle on your unordered list. None. And you're practically where you were with a div. Buttons are also another important aspect. Well, you can get by with using a div, you have to do a lot more to get it to a place where it becomes usable. And oftentimes when I see people using a div, they don't actually take that into consideration. With a div, you get nothing by default with a button you while you typically overwrite it, you get something that actually looks like a button, you get access faster, that shows it's clickable and you get an element that people can use their keyboard with by tapping and hitting enter. And did you know that by default, when nested inside of a form, that it's going to actually submit that form on its own? This is handy for a variety of things, like not having to worry about setting up a specific event handler in order to submit your phone. The point, though, is this, along with the rest of the e-mail I went over isn't much more difficult to use. We just need to be a little bit more conscious and get in the habit of doing it from the start. And lastly, let's 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 that we want it. Sometimes there's a simpler way to do things that we're struggling with, with JavaScript. This is probably a really exaggerated example of the padding type solution. Hopefully I got the math in there, Ray. Don't judge me, but it shows the difference on how some counts 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 some value from learning by doing I preach that all the time, if you want to use a bunch of complex tools to build your blog, that's a great low risk way to learn into the tools. I even encourage it. It's a way to try new things and rapidly learn without worrying about breaking things. I lost count of the amount of times that I rebuilt my website over the years before I currently settled on my relatively simple one. But from a work perspective, whether for a client or for 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 will take in the browser? How much time am I really going to save? What those tools? So what are some ways that we can keep things simple? Well, you don't need to rewrite the spec every time you add a new component, more often than not, the more JavaScript you write means that's the more JavaScript that you actually ship, which can impact the performance of an app. Use what we already have. It's also a lot less work like here we have the data list element where we can create a really simple autocomplete feature for an input. You don't need JavaScript to create a simple floating animation like you might see on some of your favorite websites using some success, we can use a gradient in an animation to create this effect. It's just a small snippet here. Better yet, having it as a class so we can extend it to any element we want pretty easily. Well, 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 the attribute on our input to change how it looks here. We're simply showing different text depending on if it's checked or not, using pure excess. And if I asked you how many of you would make this, how you would make this text responses before actually seeing this, how many of you would jump right into JavaScript? We can actually do this quite nicely with using some simple CSS here. I'm setting the font size of our one to 10 viewport width. Might look a little choppy on the slides between saving this out as a gif and trying to present it. But I promise you, it's buttery, smooth the way it scales nice and evenly within our browser and bonus. If it gets too small, we can set a media query breakpoints and keep it all inside of our success. And as much as there are some good practical things about the fundamentals, people are also building some really awesome things with some simple access. This is important because it reminds us of how much we can do with what's already out there. It's important because it helps keep pushing the boundaries of what we can actually do with native tools. There's massive work already underway with success. If you haven't heard of Whodini, you should definitely take a look. And this goes beyond the tools that we already have. I believe that priorities won't be happening if we didn't have the developers that are constantly trying to push these tools. So it can be important to have constraints that promote creativity where you least expect it, like a trend on Copan to try to come up with a only solution using a single div. It's not just challenging, it's fun. Most online stores look the same, so Andy came up with something a little bit more creative for some Adidas shoes, this is using only a 6000 e-mail to create this 3D gret effect. Or this pen from Lynn, it's a success, only collector's cabinet. I love all the incredible detail put into it and you can keep looking around and find something new like that ball. Elad made this coronaviruses game, you're able to fight the pandemic by clicking each virus, there's no JavaScript in here at all. It's all access. Elad uses some input similar to some other solutions, but uses CSFs loops, create the different animations. This gives us our virus with the ability to interact. And I have to include my own right, so admittedly, I haven't picked up a pen in a while. This thing's over six years old now, but the story goes. I was watching the Alien movie for the first time and I stopped watching it because the title scene as because I ended up spending the rest of the movie, remaking this title screen inside of success. And I still actually have yet to watch the movie and watch it. But just to clarify, I know there's a little JavaScript on the bottom there, but that's only to provide the handy restart button at the bottom. But this was challenging and fun, and it might not be practical for every scenario. I'm not going to be putting this on of my websites, but I can apply the things I learned to other work, like the micro interactions and the delightful animations inside the UI. So now that you have all been inevitably inspired, how can we get back to the basics and learn some fundamentals? Frico camp is a huge community of learners who are trying to teach themselves the code, they have great courses free. Of course, 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 everything from accessibility to full blown apps. All the instructors I've worked with are super smart and really great at helping others learn. YouTube also has a ton of great material ready to watch Frico camp even has their own channel with a ton of content, but there are a lot of individual contributors, content creators like me, who are posting amazing stuff every single day. And similar to YouTube, which has a ton of great content and it seems like there's another awesome developers starting their own streaming channel every day, you can get a live walkthrough on how to build some of these things. And bonus, you can hop in the chat, maybe even ask a question or two. And I feel like Copan really changed the game when it comes to season, your proof of concepts, it's incredible what you can find just by browsing around. And it's not just plain and H.M. There's really a ton of advanced JavaScript work on there. And best of all, you have the code immediately available that you can for and start playing around with yourself. So how are you feeling after all that? I really hope inspired there's a lot you can learn without diving headfirst into JavaScript. If you take all these things into consideration, you're going to be better off as a developer, not only will you help yourself by avoiding overengineering solutions, which typically bring on more stress, but you're also going to help others bring more traffic to your projects and help others use them. While this talk is about the fundamentals, if you're looking for more opportunities to learn by doing. You can check out my free e-book called 50 Projects for Reacting, a web which includes 50 project ideas, complete with project briefs, layouts and resources. The best way to learn is by doing like I said before, and this will help you avoid asking yourself what to build and just start getting built building. And that's it, if you want more, you can find me pretty. But call me back and if you want more resources, I typically do weekly tutorials and put out videos to go with them and also tweet out a link with all the stuff you've seen here today. Thank you.