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.
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 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.
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.
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.
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.
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.
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.
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’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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Largely as above, yet another competing standard for CSS preprocessing.
Yet another similar approach.
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
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.
“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.
The same as Grunt, but with simpler syntax that’s easier to use. Gulp replaced Grunt very quickly.
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.
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.
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.
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.
Probably the first real competitor to Bootstrap, Foundation works roughly the same way.
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.
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.