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.

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. :)

What I Learned in 2016 (Part 3)

This is the third part of a three part blog post on the things I’ve learned over the last year. So far I’ve covered HTML, CSS and a rare (for me) bit of databasey stuff. And now the final part, the JavaScript…

Node.js

I haven’t gone into this in depth but was curious about how JavaScript might look on the server. There are lots of in-built functions for working with files and requests but otherwise it really is just JavaScript – objects, functions, if statements, for loops, etc. I think it would take a bit of getting used to but having a JavaScript background it’s probably much easier than learning something else like Ruby or PHP. I learned this from CodeSchool, Real-time Web with Node.js.

Modular Functions in JavaScript

I really didn’t know what to call this but I know what I mean by it so I’ll try to explain. It’s just a way of thinking about JavaScript functions so they’re separated and easier to test. Each function performs a single job so rather than a function being a wrapper for lots of different jobs, e.g. a conditional test then some string manipulation then constructing an object to return. Each job is broken down into its own function so we end up with lots of tiny functions which call each other rather than long routines. The second part to this is not relying on any variables which sit outside of the function scope. So, not referring back to a variable in the global scope or in a parent function. If our function needs to refer to something it needs to be passed in explicitly as an argument. This just makes it completely self-contained so it can be picked up and dropped in a different context and still do its job without worrying about being affected by the scope.

I started using this methodology after reading a blog post but, sadly, I can not longer remember the source. If anyone knows what this is called or who might have written a good article on it please let em know in the comments.

ES2015

As I’ve managed to start dropping support for older browsers it has opened the doors on some new features in JavaScript, namely, ES6 or, as I think we’re supposed to call it, ES2015. I did another CodeSchool course, ES2015: The Shape of JavaScript to Come. In short it takes a bit of getting used to but ultimately means you can do more writing less, which has to be a good thing. Using tools like Babel we can even use it in older browsers now – it cleverly converts it back to ES5 where needed.

TypeScript

TypeScript is like JavaScript but upgraded to be a strongly typed object oriented language. It then compiles down to JavaScript, a bit like Sass to CSS. Like CSS is valid Sass, JavaScript is valid TypeScript so you can convert your existing files without it being a major drama. You declare the type of any variable and if there’s any error or uncertainty it won’t compile. This means that you can never have any type errors in production, which is very nice. The number of times I’ve had to fix bugs around some function expecting an integer but getting a string. The other side to it is being able to use modules and classes – it’s proper scoping and namespacing.

As we’re working with Angular I actually did the Pluralsight course, Angular with TypeScript. With hindsight, I’d probably just do a TypeScript course so as not to blur the lines.

Dragula

This is a library for using drag and drop functionality. I’ve always used jQuery UI draggable, droppable or sortable previously but was keen to see what could be done without the jQuery dependency. Dragula is actually very similar to use, selectors, options object, etc. but uses vanilla JavaScript. Getting into more complex uses the documentation and Stack Overflow answers started to dry up a bit. I guess that’s one of the advantages of using the big libraries.

Toastr

Toastr is another nice little utility library. This does pop-up or toaster notifications. It requires jQuery so may not be for everyone but has loads of options and stacks multiple notifications elegantly, which is not easy. This is probably one of the easiest things I’ve ever used.

And that about wraps it up. Who knows what 2017 holds. At the moment I’m very curious about some new JavaScript frameworks – Vue.js and Svelte.