Why is there so much to learn in web development?

The question comes up routinely in web dev communities. Why is there so much to learn, why are there so many tools? The answer is simple, and critically important.

I’ve seen a number of articles in the last few years, and a recent spike, all essentially asking why Web Development is totally broken. Why there is so much movement, and why there is so much to learn.

For new developers, this is a daunting field. It’s loaded with technologies and jargon and abbreviations. Most particularly it’s loaded with a bewildering number of names of “things”: Bower, Gulp, React, Bootstrap, LESS, NPM, jQuery, Foundation, Elm, ES6, Webpack, Redux, Ember, Node, MVC, VanillaJS, Babel, Docker, Underscore, Vue, JSX, Angular, Grunt, Typescript, ES-Next, Sass, Stylus, ES2015, Express, Python, Jade, ESLint, Bulma, BEM, and an infinite array of others.

From the point of view of a new dev, or a returning dev, all of these are “stuff I have to learn right now or I’m useless”. In fact this is far from the truth, but without the tools and knowledge to understand them, it’s an impenetrable forest of meaningless words.

Honestly, in my opinion a lot of the “JavaScript Fatigue” people endlessly complain about is self-inflicted.

Looking at this list of technologies and complaining that you have to learn them all is like looking at a restaurant menu and complaining that you have to eat everything.

What’s critical to understand about all of these tools is that they’re not some sort of checklist that all developers have to learn. You don’t start with 0, and when you master all of them you are a “senior” and get a 70% pay rise. You don’t need any specific number of them to be “qualified for a junior job”.

Rather, these meaningless and often abstract terms are technical solutions to actual real world problems.

Treating these technologies like a competency checklist is a disastrous mindset.

It’s impossible to truly learn a solution without any knowledge or understanding of the problem it’s trying to solve. Trying to use or learn the solution when you don’t actually have the problem it’s trying to solve is nearly impossible, and will simply lead to frustration: “This is pointless!”.

You see it all the time, people complaining that ElasticUnicorn.js is just stupid and needless complexity for no gain, and they just don’t get it. Of course it is when your rendering up-path is still completely binubulated. Obviously.

What people, including more experienced developers, tend to forget is that software is nothing more or less than solutions to problems. Some of those problems are technical. But most of them are more about keeping software maintainable, consistent, and coherent.

Most of the problems these technologies solve are actually people problems, rather than technical ones. Resolving differences between humans, how we see things, how we name things, and the limitations we have in what we can understand at a time.

The best way to learn new tools and technologies isn’t to run through the abstract wordvomit that makes up the tooling world, but rather to build things. Then to figure out what part of that was harder than it seemed like it should be and see if you can find a solution to make it easier.

For some of us, this was an option. Tooling and technology, knowledge and experience was able to come slowly. When I first started web development, not only was JavaScript not remotely a requirement, but even CSS didn’t even exist yet. I was able to learn HTML alone. Though in my defence, HTML absolutely sucked ass then.

For developers starting now, that slow accretion of knowledge isn’t really an option. So what I can do to help is to break up this big ball of context-free names, try to group them in meaningful ways, and see if we can provide some understanding behind what problems they solve and when and why you might want to use them.

For convenience, I’ve added two little icons. The 🚀 is critical tools that you definitely need to learn. The 💀 is projects or tools I would consider basically dead in the water, and are included purely so you know what they are if people mention them. Both of these are highly subjective.

JavaScript

A lot of people don’t realise that JavaScript is actually the wrong name. JavaScript is more accurately a branding term for what is properly called EcmaScript. Originally the European Computer Manufacturers Association, now just Ecma, are a body working towards standards and features for what we routinely call JavaScript. In practise this would typically just be a technical irrelevancy, but it will become very relevant soon.

VanillaJS
Vanilla just means “just plain old JavaScript”. It’s often written as VanillaJS as a tongue-in-cheek suggestion that it’s a framework or library. But it’s just standard JavaScript as understood by all browsers.

🚀 ES5
As above, ES5 is just normal JavaScript, understood inherently by all browsers. Note that this is where the whole EcmaScript thing becomes more relevant. ES = EcmaScript, the more accurate name for JavaScript.

🚀 ES6
An update to the above EcmaScript, ES6 added a whole bunch of new features and syntax. While support for these has been steadily added to browsers, for the most part code written in ES6 has to be processed by software to turn it back into ES5 that every browser can use natively. It’s also known as ES2015.

ES.Next
ES5 to ES6 was a big jump, and to prevent such big bites in future, yearly releases have included new syntax, ES2017, and ES2017, etc. A new ES2018 will probably be released within weeks, and ES.Next simply refers to either whatever is the future version, or sometimes as a catch-all for any version ES6 and above. People also commonly use “ES6” to refer to anything ES6 and above, including features that are technically after ES6/ES2015.

ESLint
Linters are code-checkers that are set up to ensure the code you write follows certain rules. ESLint, along with others such as JSHint, is just a library for checking the rules of JavaScript. ESLint is the more current, and supports ES6+.

TypeScript
This is an extension to JavaScript written by Microsoft, which allows the relatively “flexible” JS to be made more consistent and disciplined. This makes it a bit easier to write complex apps. TypeScript isn’t JavaScript, and has to be run in a browser. It isn’t necessary to learn this unless you’re doing a lot of Angular.

💀 CoffeeScript
There was a dark period in the early 2010s where it was decided that things were more “elegant” if they looked like Ruby, and that meant removing things like semi-colons and braces and making everything whitespace-sensitive. CS is basically JavaScript written like that, then compiled to normal JavaScript. In the modern world CoffeeScript has no place at all, and is largely defunct.

Verdict

Of these, all you really need is a good, solid understanding of ES6 and and “VanillaJS”. That said, you really need a good, solid understanding of these technologies. They’re probably the most important skill in this field at this point.

JavaScript Frameworks

I wrote a whole article recently about what problems frameworks actually solve and why you’d need one. I’m not going to go into what ones are best and why and any details, because I’ve already done that. And Ember is still the best.

jQuery
This probably doesn’t need much introduction, jQuery is a series of utilities that are intended to make JavaScript easier to work with, and facilitate things like Ajax and DOM manipulation.

🚀 React
A library (or framework, the definition is fussy) that’s probably the industry dominant at this point. It is highly flexible and unopinionated, which is either a good thing or a bad, depending on your view. React is prominent and influential enough that it’s actually spawned its own set of terms and thus will get a section below.

Angular
This is a loaded word. Angular was probably the first real framework, and the original version was dominant in the industry a number of years ago. Newer versions have since come out. Angular 1 to 2 was an enormous and catastrophic change. From 2 all the way up to the current 6 is a relatively smooth transition, though. Original Angular should be referred to as AngularJS while 2+ should be called Angular, but in practice that’s not what happens and ambiguity remains. Angular is sometimes abbreviated to ng.

Ember
Ember’s actually about the same age as Angular, but the transition from 1–3 was completely smooth. It’s not commonly talked about in more junior and enthusiast communities like Reddit, but is used well in large, long-living applications. Netflix, LinkedIn, etc.

VueJS
Vue is one of the newer frameworks, and quickly becoming popular. Like React it is relatively small in terms of what it does, but has the capability to do a lot more.

Elm
A “functional” language that compiles down to JavaScript. It is highly disciplined and complex, and it is definitely not necessary to learn this tool as a starting developer.

Verdict

These aren’t all things you need to learn. One or two is fine. But you probably do need to learn at least one. And it’s probably React. You really need good JS skills for that, though, and that should be considered the highest priority.

The React Ecosystem

React is big enough as a framework and community to have itself spawned a range of baffling terminologies and concepts.

Flow
The only thing here that’s not a “technology”, Flow is a methodology or approach that means data should be passed down into components, and then actions triggered that change the data in the parent (or parent of the parent). Those data or state changes then cascade down into component. Some variant of this concept is fundamental now to all frameworks.

Redux
A “state management” tool, Redux is intended to keep all of the ways your application could need to change its internal data in one place. It’s critical for more complex web apps built in React. Redux is not a requirement for React, nor is it exclusive to it, but the two are largely associated with each other.

JSX
React doesn’t use standard templates, but instead has a syntax with XML-looking markup embedded directly inside the JavaScript code.

Verdict

If you’re not using React at all these are probably irrelevant, if you are you’ve already run across them.

The World of NodeJS

Node as both a server and local development tooling is a fundamental part of the web development world.

NodeJS
Node is a commonly misunderstood beast. At its core is the notion that JavaScript doesn’t need a browser to run, and NodeJS is the environment for running JavaScript without a browser. This engine is commonly used to run NodeJS as a server. However, it’s also commonly used for to run code locally on a computer, especially code that creates or modifies code files. As a result, a vast majority of the tools used for modern development are actually NodeJS command-line applications running on your computer. This includes things like Webpack or Babel, which we’ll go into later. This means you at the very least need to understand what Node is for.

Express
The core Node engine is capable of doing all sorts of request and response stuff, but Express provides a framework to make it easier to add routes, get data, etc. Like a lot of other things here you only need it if you have specific requirements, it’s not something you generally need to know.

🚀 NPM
Node Package Manager, a command-line tool for installing Node packages, either globally in the case of development tools or locally to the individual project. NPM lists “dependencies” (external code requirement) in a file called package.json, and puts them in the node_modules directory. Using a tool like NPM makes it much easier to install and manage the things you need to use — whether it’s Bootstrap, Moment, or the entire of Angular. You need to know this command-line tool. It is not even a bit optional.

💀 Yarn
NPM was originally written purely to handle importing files for Node applications, and less for general tooling for JavaScript developers. As a result, Yarn was created and optimised for this stuff and supported local caching, and faster, more reliable installs. Newer versions of NPM are feature equivalent, and IMO you can ignore Yarn now and stick with NPM.

Verdict

NPM is critical to know and use, but unless you’re actively developing in Node you only really need to know how to consume or use these tools on their own.

Beyond CSS

Cascading Stylesheets can get chaotic and disorganised, especially in large projects, or projects with large teams. There’s no official way to organise them or name things, so a bunch of tools have come up to tame CSS.

LESS
Probably the first “CSS Pre-processor”, Less is a way of programmatically building CSS that includes things like variables, mixins, functions, importing, and a whole bunch of things that make the whole process more maintainable. Most particularly rules can be nested inside each other for more clear scoping.

🚀 Sass, SCSS
Nearly exactly the same thing as LESS above, even the syntax is nearly identical. Strictly speaking, Sass is written without any braces or semi-colons (see “CoffeeScript” above), but SCSS is written just like normal CSS but with some additional features. When people talk about Sass these days they invariably mean SCSS as pure “Sass” style is all but dead. In theory Sass and Less compete, but in practice Sass has won this battle. All of the above is compiled down to normal CSS before it’s used by the browser. It’s hugely useful to know Sass, and there’s a minimal investment in time to learn it. The bang for buck is great, and is recommended unquestioningly.

Stylus
Largely as above, yet another competing standard for CSS preprocessing.

PostCSS
Yet another similar approach.

BEM
Short for Block-Element-Modifier, BEM is a methodology and naming convention for CSS selectors. It aims to make a more predictable, consistent, and comprehensible way of applying CSS. Note that this is entirely compatible with tools like Sass. They solve different problems.

Tooling and Task Runners

There is a huge amount of “stuff” happening in modern websites, certainly more than the days when we just pasted jquery.min.js into a directory and imported it with a script tag. ES6 compilation (technically “transpilation”), compiling Sass, minifying and concatenating JavaScript and CSS files, checking for style errors, etc. Naturally a number of tools exist to automate this process.

When people talk about “JavaScript Fatigue” in my experience they’re actually talking more about this stuff than anything else. It’s been fast moving in recent years, but seems to have stabilised.

💀 Bower
Bower was developed as a front-end package manager. So you’d use it to install Bootstrap or jQuery or whatever. It has been entirely supplanted by NPM now.

Babel
The main point is to be able to write ES6+ code and have Babel convert it into the type of JavaScript that the browser can read. While it’s hugely useful, you don’t typically use Babel itself, one of the following tools does. So you don’t actually need to learn anything.

💀 Grunt
“Task Runners” do what they say on the tin, running tasks. You define the tasks you want done, and when you want them done. For example, on a saved change to .js files in a given source directory it might run a linter, transpile the files with Babel, copy the files into a compiled directory, minify and concatenate them, and then show an alert.

Gulp
The same as Grunt, but with simpler syntax that’s easier to use. Gulp replaced Grunt very quickly.

🚀 Webpack
Aaaaand Gulp was replaced quickly too. Webpack is a much bigger beast, and more than just a task runner. It considers itself a “module bundler” and its main job is handling all the imports and things of modern ES6. It has heaps of “loaders” that can handle a range of different file and content types — .vue files, svg, typescript, React JSX, Sass and so on. Getting a basic understanding of Webpack is useful.

Browserify
Largely filling the same goals as Webpack but with a less comprehensive (and complicated) API, Browserify has now largely been supplanted, with Webpack steadily taking over its space.

CSS Frameworks

The goal of CSS frameworks is to scaffold the basic look and layouts of a website. They help to maintain consistency in terms of things like button styles, type sizes, colours, form layout, and spacing. Most frameworks us a “grid”, though really this is more about columns than row. Typically this is a 12 column grid. What that means is that you can have an interface with a quarter of the width taken up just by using three columns. Then you set the main content section to use the remaining nine. Or you set it in half by setting six and six. Or thirds. Sixths, etc.

The most important feature, though, is that they allow those to change depending on the size of the device display. So you might have three columns on a desktop screen, two on a tablet, and only one on a mobile phone. This sort of “responsive” layout is a pain in the ass and requires a lot of messing around with media queries in CSS. Not having to do that is worth it alone.

🚀 Bootstrap
The original and best supported CSS framework, Bootstrap is still the dominant player in this space. Version 4 only came out this year, and updates a lot under the hood. There is a perception that Bootstrap sites all look the same, which is true if you just use Bootstrap and don’t make any other changes. It should be considered the start rather than the end of the design process, and customised extensively.

Foundation
Probably the first real competitor to Bootstrap, Foundation works roughly the same way.

Bulma
Not as “big” in file size and comprehensiveness (or popularity) as Bootstrap, Bulma is a relatively lightweight alternative that still adds a lot of support, especially in having a responsive grid.

Conclusion

There are a whole lot of technologies listed here. It’s important not to think of them as some sort of requirements. Remember, the fundamentals in web development are HTML, CSS and JavaScript. Everything else is an optimisation, and usually an optimisation of process and maintenance, rather than providing anything better or even different for the user. If you don’t need or value these optimisations, ignore them.

If you hear someone talking about a technology that doesn’t mean you have to learn it, or even learn what it is. If you hear a lot of people talking about it for a while you might want to pay attention, but even then, unless technology solves an actual problem for you, you don’t need to worry about it.