How I’d Learn Front End Web Development Now

When I started out with doing web stuff in 1999, things were very different, much simpler in some ways but much harder in others. So, the way I gradually learnt was quite different from how somebody would learn now.

Back in my day…

Don’t yawn, there is a point to this. In 1999 when I started learning this stuff, there was only HTML, CSS and JavaScript. No TypeScript, no Sass, no real frameworks to speak of, no packages, no build tools. You get the picture.

So, there was a lot less to learn but learning was harder. There wasn’t great documentation online, or, at least, not easy to find, so I used books. Cross browser compatibility was hard.

In short, it’s a completely different landscape now. So, I thought it would be interesting to think about how I would learn or advise others to learn if starting out now.

The basics

The basics are still the basics. HTML, CSS and JavaScript are the technologies used by web browsers. That hasn’t changed in all this time and it’s not likely to change any time soon. While trends will come and go a good understanding of these three areas will always be time well spent.

Accessibility

This is a critical area that is often overlooked. The web is a universal platform that should be for everyone, not just for those with good eyesight, expensive devices and fast networks. We need to consider how we deliver content that works for all.

It’s definitely worth learning this from the beginning so things are done in the right way as it’s harder to correct bad habits later. Being able to demonstrate an understanding of accessibility will put you ahead of other candidates who have skipped over it when it comes to job hunting.

Go deep

Going further, I’d say it’s worth exploring these HTML, CSS and JavaScript in some depth before moving on. I think it’s worth skimming through everything on them at pace without worrying about retaining too much. This could be either a course or just working through documentation. Just becoming familiar with what features there are and some terminology will help you understand more conversations and documentation, as well as know what to search for when the time comes to use them. Nobody can remember it all and even experienced developers have to look up syntax. That’s not generally what an employer would expect, it’s more about the broad understanding of how you can use features to solve problems.

Responsive design

It’s rare these days that we can create a web page that will be for a single screen size, so we need to know how to make a user interface that looks good on a big desktop screen and a phone. This is a whole area that is again worth tackling fairly early on. It’s a bit of an art, a collection of techniques and tricks that are not easy to discover. This is an area that would probably benefit from a course.

Source control and package management

Once you’ve got enough of the basics to make something amazing, you’ll naturally want to share it with the world, and then you’ll want to make use of your amazing thing or other people’s in your future projects.

Source control is about publishing code but also collaboration – reviewing each other’s code, branching out and merging it back together. The most commonly used system for this is probably git. Worth reading up on.

Package management is about bundling up your project into a package that can be easily exported and then imported into other projects. The most common platform for front end code is npm.

These two areas usually involve using the command line, a terminal where you type commands to make things happen. It’s not as scary as it looks and makes you look like a proper hacker to those not in the know.

Frameworks

Probably later than some would expect, but I genuinely feel the other things are more important to get good longer term. If you learn a framework too early their way of doing things becomes your normal and then if you change framework you have to start again. If you understand the core technologies then you can see what the framework is giving you and can adjust more easily.

CSS frameworks can be very useful for providing ready-made styling, bringing consistency and the CSS is well structured. It’s a good way of learning how to structure your own CSS for larger projects.

JavaScript frameworks like React, Vue or Angular take some investment to learn but it is paid off in terms of faster development down the line.

There are also UI frameworks and design systems which provide complete components ready to use.

With all of these frameworks, there’s lots of time saving and knowledge to be gained but it’s important to remember that these are just someone’s opinion and one way of doing things. There is no single right way or best way.

Extending the basics with pre-compilation

I’d say that’s probably everything you need but there are a couple of other bits that are cheap to learn so worth throwing in there – more skills to boast about can’t hurt.

Sass is a superset of CSS – it’s CSS with added bells and whistles. You write in .scss files, making use of the fancy additional features and then it gets compiled to normal CSS. The great part is that it’s additional features, not a different language so CSS is valid Sass. You can start out with a .scss file, just write normal CSS and it gets compiled to CSS. It’s a bit pointless but means you can start off with nothing and then gradually learn and use Sass one feature at a time. It’s a nice easy learning curve.

It’s the same idea with TypeScript. This is enhanced JavaScript so you can write in .ts files and get JavaScript, learning the new features as you go.

With both of these, once you get into the new features you’ll never go back.

Then, anything goes

Once you’ve got these skills, it’s really an open playing field. You can learn whatever takes your interest, or maybe whatever your job needs.

Let me know if you’d do things differently.

Component World

Whatever stack of framework you use, everything in web development seems to be going modular. We’re no longer building pages of screens but components and component systems. This is changing the way I work with files. Where once I would have combined my script and styles into a single resource to reduce requests, I now actively look to break everything down into tiny pieces. For example, I have loads of Sass files. These get compiled into CSS before being concatenated and minified – turned back into the single big file. Working this way has several advantages. It’s easier to work in smaller files – easy to find the line you need with minimal scrolling. It paves the way for using web components of a component system where styles of scripts can be embedded within the component, making it a true standalone piece of the document. Finally, it makes it easy to build dependency free components in a tool like CodePen. You can just write the HTML, Sass and JavaScript and save it as an isolated component with its own demo.

Precision Level in CSS

When we’re using relative sizing in CSS, percentages or ems, how precise do we need to be with our fractions? Is there an optimum level?

If we have a font size of 18px (or anything, it’s relative after all) and we want some smaller text at two thirds of its size (12px) then we can express this as .6666666667em or 66.6666666667%. Here I’ve used 10 decimal places to give a very precise fraction but this feels like overkill to me. If I used just 2 decimal places, .67em or 66.67%, is this accurate enough to consistently calculate the desired pixel value. Or should I not worry? It’ll be near enough.

Looking at other developers’ CSS, mainly in tutorials, the general pattern seems to be to use between 4 and 6 decimal places. Looking back through my own code, my preference seems to be to use 6 but I couldn’t tell you why. I’d imagine I’ve just adopted someone else’s coding style. I definitely feel that going beyond 6 seems unnecessary but am not sure how little I can get away with.

Sass is able to perform calculations using fractions. Here’s an example:

$two_thirds: 2/3 * 1em;

.smaller {
  font-size: $two_thirds;
}

This resolves to .66667em, 5 decimal places. Is this a set precision or did Sass actually calculate it from the root size and decide what precision was needed for it to resolve to an integer? Hmm (rubs chin). I guess that most people let Sass handle this for them and don’t even look at the compiled CSS.

Learning the Right Things

With so much happening so fast knowing what new tech to learn next can be difficult. Where should you invest your time and energy? What if you spend ages learning the shiny new framework and it’s gone within 2 years?

There are a lot of trends and a lot of new-fangled things do come and go. How do you spot the ones that are going to stick around. It’s not easy – you kind of have to go with the flow, not swim against the tide (2 water based metaphors in one sentence, tut).

In front end development there are currently a few big JavaScript frameworks – Angular, React and Vue. It seems obvious to me that none of these are going away any time soon. Which do you choose? It really doesn’t matter. Learning one in depth, finding its powers and limitations, will help you learn the others or other future technologies.

If you’re really not sure where to turn I’d focus on core learning. In the front-end world, learn plain JavaScript. With ES2015 and newer versions than that emerging there’s still plenty to take on and perfect. That knowledge will always be useful.

I guess my short answer would be to favour the evergreen HTML, CSS and JavaScript over associated tech like Pug, Sass, TypeScript, etc. As the core technologies get better over time these current convenience technologies may one day not be needed.

One word answer. JavaScript. :)