0:12 Who am I? I'm Colby Fayock. I'm the one hugging BB-8 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, like Twitter and YouTube, by just googling my name, as I'm the only one in the world.
0:25 We're going to start with a 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, Mark's brother, more of a green kind of guy.
0:35 Both of our friends are switching their careers. They're both giving coding a try. They both try to find a boot camp to dive right in.
1:09 Both of our friends decided to submit their resumes for a job at One Up, Inc. It's a junior front-end dev position. Description for them is both are near perfect fit. Luckily, they both get a call back for a co-challenge.
1:20 Once they get on the calls, they 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, after which, they'll talk about the work. Not too bad, right?
1:30 First up is Mark. This is easy for Mark. He just got out of a boot camp where he learned how to use Reacts, and the job posting says they want React, so that's perfect.
1:38 Then he'll build the challenge with React. He can also use some CSS-in-JS, which he recently learned a little bit about by reading. It should be pretty easy to integrate for a quick win.
1:48 Then we have Luke. He decides again to take a little bit of a different route. The website looks very simple, so he thinks he can do it with some plain old HTML, lay on a little CSS, and it should do the trick.
1:59 Let's compare solutions. Mark didn't get super far. He only got the title. Luke seemed to get pretty far. It's not perfect, there's some mismatched colors and styles, rare sizes, but it's a good start.
2:09 What happened to Mark? Let's just say that Mark didn't have a great interview. First, Mark tried to get a React app going, and he forgot that he needs to configure a package manager in order to install React.
2:35 He figured it out, and he can also include Babel. With that, he can also add the Babel type to the script tag and now he can use JSX. He's in business.
2:44 Oh, man, we're still getting an error. Let's check the React docs quick again. Right. He needs to wrap it in a createElement. Awesome. That should work and it does.
2:54 Now, we can get started moving on the website. Mark adds his header and it renders. We're making progress. Then he realizes he needs to add some styles to make it look right. He can't install it from NPM, so he'll need to find an external link again.
3:07 Oh, no. By the time he actually found a solution, he ran out of time. He spent so much time debugging that setup that he never actually had a lot of time to build the site.
3:17 On the other hand, Luke broke out his favorite editor just like Mark did. Instead of trying to deal with packages, he just started with some basic HTML. To create a header, he knew he was able to throw a few HTML elements together. He used the header and the nav tag, nice and semantic.
3:32 For the content, he added a main tag and image and some text. Figured he can use some CSS to position it all correctly, so he did. He added some styles to make it look great. Flexbox makes this really nice and easy to do. He flexed the header, he flexed the body content and he was good to go.
3:48 With all that, Luke ended up with a lot more progress than Mark. Of course, Luke lands the job. He had something to talk about in those last 15 minutes. He went over why he chose flexbox, why he used the header and the nav tags. He also talks about what he would have done to fix some of that styling.
4:03 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 with the beginning of the project.
4:11 The truth is this story is only slightly exaggerated. I didn't use real names or likeness, but this exact solution happens quite often. Of course, someone super experienced with React might not have hit those same roadblocks. I've personally sat through interviews watching candidates struggle through these same types of challenges.
4:41 While every company, every candidate, and every interview are each unique, there's a common thread. It's easy to want to learn the exciting new tools and jump right in. That's not even necessarily a bad thing.
4:52 Part of why I love what I do is because this stuff is fun. It's the kind of thing that keeps me inspired. Dealing with an interview is already stressful in the first place. 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.
5:09 We're going to talk about how you can level up. We're going to talk about why these things can make a difference. We're going to learn some cool tricks along the way.
5:15 We'll start with HTML. I would imagine most of us have probably at least heard of HTML. What exactly is it? If you didn't know, it stands for Hypertext Markup Language. It's the essential building block of all websites. It has been since probably before most of us have even heard of HTML.
5:31 A lot of us probably don't have to write this much by hand anymore given React and the other UI libraries do it for us, but this is the basic skeleton of a web page. We have our DOCTYPE, HTML tag, head, and body with simple h1.
5:45 We're probably more familiar with this though. The actual skeleton of our page gets abstracted away. We define our page only by the content, so instead of our HTML and head, we might see our h1.
5:56 The cool thing about React and JSX though is we can write any HTML you want. For the most part, it's going to be valid. This isn't groundbreaking, but this sets the tone for some of the points ahead.
6:06 Ultimately, this JSX gets compiled down to HTML, the same HTML that we can write by hand. We just have tooling that can help provide us ways to generate this more efficiently, so that got to be out that you spun out? Yeah. That's creating a bunch of HTML.
6:21 Next, we'll talk about CSS. A lot of us probably know this as the magic that the web design team creates. I've actually heard some back-end developers say they're afraid to touch it. What exactly is the CSS?
6:33 CSS stands for Cascading Style Sheets. We have a simple example here. We're setting the color to red like Mark's outfit, we're changing the font size and making all the letters uppercase.
6:57 Similar to the HTML we saw before, this all gets compiled down into our basic CSS. Regardless of the type of tool we use, whether it's Sass or CSS-in-JS, this is what we ultimately get. The only difference is how it's served, whether it's an external link, embedded, or in line.
7:26 Did you know that browsers actually fix your HTML for you? This could be helpful, especially when starting, but it can also be confusing if you don't 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, so the browsers try to fix this for us. But, this actually messes up our intent.
7:46 We were expecting the div to also be purple, but because the browser fixes it, it pulls the div out of the paragraph tag and the paragraph style no longer cascades.
7:56 In CSS, the vertical padding is relative to the width. Ignore the junkiness while trying to show an animation here, but we can take advantage of this little quirk.
8:05 Sometimes your best option is to use a background image, but it's tricky that we can't scale the width and the height easily like we can an actual image tag.
8:13 Instead, what we can do is set a height to zero, which is kind of counterintuitive, but then we can use the width divided by the height in percentage form to set a vertical padding. This way, no matter the width, the height will always keep the correct ratio.
8:27 What's the point I'm trying to make with all this? Those things are handy to know. Those two things alone won't make you a better developer. What am I getting at is understanding your tooling from a more fundamental level will help you level up your game. How can you do that?
8:41 First thing we can apply this to is SEO. Many of us probably have heard of this in one form of another, but maybe not understand what it is.
8:48 SEO stands for Search Engine Optimization. It could be super complex with keyword research and strategy, but we're going to focus on the stuff we can control as developers.
8:57 Our ultimate goal with a SEO 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 you use to present that and the metadata you use to make sure that it looks right in search.
9:12 Most websites have a healthy mix of different ways for people to get to their website. Some might be ad traffic, other social media, but there's also people trying to look for something in a search engine who could possibly find your site at the top of that list. This helps him bring in more traffic which could help your website and company grow.
9:28 Like here, aside from the Free Code Camp referral traffic, my website pulls in the most organic search. 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 were a bunch of images with art or texts anywhere, how is Google going to be able to know what your page is about?
9:47 What can we do better? We can try to be more conscious about the HTML 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.
9:58 One thing you can try to do is maintain a logical page outline for your website. You shouldn't have every one of your titles as an h1. That's not helping anyone. Instead, use h1 through h6 to organize your content, similar to what you would see in a book. What this will do is cue the search engines to the hierarchy of your website. It's helping to answer what information belongs under what title.
Here, we have to examples of image tags. The top one doesn't have any alt value, but the bottom one has a description of what's happening in the image.
What do you think is going to be more likely to show up in a Google search? By providing our alt tag, we're helping Google understand what the 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 easier to tack on a "Read more" link after a paragraph, but when search engines call your page, they look at the text of the link to try to find out what the context is about that link.
Using the same text everywhere, like "Read more," isn't really helping much. Instead, we can add links to the descriptive part of our text we already have. We can make it easier for Google to understand them.
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 each and every page? The tag that controls this is the title tag. It's more important than just the browser tags. This is what controls the text that shows up in Google.
Google is getting smarter adding more context about the pages, but chances are it's not going to consider your links as valuable if every single page shows up as your blog's name instead of what that page is actually about.
Next, we'll talk about accessibility. Accessibility is 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. That means can someone with a seeing disability still use your website.
Each of us, as developers, is responsible for how our creations are being used. The World Health Organization estimates 15 percent of the world has some sort of disability. That's over one billion people.
Now, the whole world isn't going to be using just my website, but how about 1,400 users that visited my website earlier in the year? Hypothetically, if 15 percent of those visits were people with disabilities, that's over 200 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. Those are real people who can't use your website because no one paid attention to it.
For businesses, that's loss of money. For people's needs, that could be a prescription that they're having trouble filling. We should all take responsibility for the work we create. It's just the right thing to do.
What can we do to help out our friends and neighbors? We can 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 effort, if at all, to develop with accessibility in mind.
Remember our page outline from before? While optimizing for SEO by using proper semantic HTML, you're also helping screen readers understanding the hierarchy of the page. As a screen reader is moving up and down, it's able to jump over the sections that the person might not be interested in. Imagine this is going to be really difficult if every single heading is an h1.
Remember our image alt example? Do you see a thread here? A lot of times when you write your HTML properly, you're going to end up providing value in multiple ways. Here, if a screen reader lands on your image, the person will actually get to hear what the image is showing. It's just another low-effort way to help everyone experience our website.
Lists are also a practical use of HTML that's used across the web. Far too often, I see code that's logically a list but it's 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 using it. They're not that much harder to style. Set your list style on your unordered list to none, and you're practically where you were when you were using a div.
Buttons are also another important aspect. While you can get by by using a div, you have to do a lot more to get to a place where it becomes usable. Oftentimes, when I see people using a div, they don't take that into consideration.
With a div, you get nothing by default. With a button, while you typically override it, you get something that looks like a button. You get a CSS cursor that shows it's clickable. You can get an HTML element that people can use with their keyboard by hitting tab and hitting enter.
Did you know that by default, when nesting a button in a form that the button's going to submit it all on its own? That's not worrying about having to set up specific event handlers to submit your form.
The point though is that this, along with the rest of the HTML I went over, isn't much more difficult to use. We just need to become a little bit more conscious in getting in the habit of doing it from the start.
There's absolutely some value while learning while doing. 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 breaking things. I lost count of the amount of times I rebuilt my website before I settled on my current simple one.
Using some CSS, we can use a gradient and an animation to create this effect. It's just a small snippet here. Better yet, having it as a class, we could extend it to any element we want pretty easily.
While sometimes we just need to maintain the state of our component, sometimes we don't. If we're only maintaining that state style, we can use instead checked attributes for input to change how it looks. Like here, we're simply showing different texts depending on if it's checked or not using pure CSS.
Here, I'm setting the font size of our h1 to 10 viewport width. It might look a little choppy on the slides, the GIF and saving it out as a GIF to present it, but I promise you it's buttery smooth. That way, it scales nice and evenly with your browser. Bonus, if it gets too small, we can always use a media query breakpoints to keep it all in CSS.
As much as there's some practical good things about the fundamentals, people are also using some awesome things with simple HTML and CSS. This is important because it reminds us of how much we can do with already what's out there.
It's important because it helps keep pushing the boundaries of what we can do with native tools. There's massive work already underway with CSS. If you haven't heard of Houdini yet, you definitely should look it up. This is beyond the tools that we already have.
I believe that progress probably won't be happening if we didn't have developers constantly pushing these tools. It can be important to have constraints that promote creativity where you least expect it. Like you're trying to uncode Pen to try to come up with CSS-only solutions. It's not just challenging, it's fun.
This Pen from Lynn, it says only, "CSS only Collector's Cabinet." I love all the incredible detail that's put into this. You can keep looking around and find new things.
I have to include my own, right? I admittedly haven't picked up CodePen in a while. This thing's about six years old. The story goes, I was watching "Alien" for the first time. I stopped watching it after the title scene. That's because I spent the rest of the time of the movie recreating this title scene in CSS. I still have yet to rewatch it.
Now that you are all inevitably inspired, how can we get back to the basics and learn some fundamentals?
Egghead, of course, has a huge library of lessons and courses. You can learn pretty much everything from accessibility to full-blown apps. All the instructors I've worked with are super smart and great at helping others learn.
FreeCodeCamp is a huge community of learners who are trying to teach themselves to 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 a natural course.
YouTube also has a ton great material that's ready to watch. freeCodeCamp even has their own channel with a ton of great content. There are a lot of individual content creators, like me, posting amazing stuff every day.
Similar to YouTube, Twitch has a ton of great content. It seems like there is another awesome developer starting their own streaming channel every single day. You can get a live walk-through on how to build these things. Bonus, you can hop in to chat and maybe ask a question or two if you get stuck.
If you take all these things in consideration, you're not only going to be better off as a developer, you're not only going to be able to help avoid over-engineering solutions, which can typically bring on more stress, but you're also going to be able to help bring more traffic to your projects and help others be able to use those projects.
That's it. If you want more, you can find me anywhere. I'm Colby Fayock. If you want more resources, I have weekly tutorials and videos out on YouTube. I'll also be sending a link with all the stuff that you've seen here today. Thanks, everybody.