A decade ago I picked up a copy of DOM Scripting, a book by Jeremy Keith. At the time the web was still fresh and new. Web apps were starting to be a thing and Javascript was at the beginning of its epic journey to global domination. Jeremy's book was a critical step in the path to becoming a "frontend" developer for me and many others. He outlined clean, elegant ways to make the browser more interactive.

Most people thought Javascript heavy web applications were a waste of time but after reading this book I was convinced it was the future and I set off to make a career out of it. Turns out that was a good call.

Today I'm weary of it all. I bet you are too.

This is what frontend development looks like now:

Source

"Stuff like this diagram really makes me question the point of continuing with web work, after being in it for 15+ years. It feels like something’s gone wrong, and what used to be enjoyable and challenging is now just pointlessly changing and reinventing itself" — @simonminter

Each of these tools has its place, the problem is the vast majority of projects don't need most of it.

It's now normal for me to walk new clients back from the cliff of over-engineering their Javascript apps.

Clients feel frustrated and overwhelmed by the complexity of their frontend code. They're always looking for the one "guy/gal" that can actually understand how it all works. Or their app is performing horribly but nobody can figure out why and some other consultant is telling them they should have used the "Framework Du Jour" instead of whatever they picked and that would have solved all their problems.

We've lost our way.

The current trend in web development is hostile to beginners and wastes client/employer money to cure boredom or satisfy egos.

I have been involved with a huge range of Javascript applications and most of the time these things are over-engineered because:

• People don't know what they are doing and choose frameworks/tools as a safety valve
• CTO was bored and wanted to try a new thing
• Lead developer was obsessed with doing everything the "right" way. "You manage state without Redux? Blah. That's just gross. How can you even work on a project without 100% test coverage?!??"
• New consultant doesn't know how to read other people's code, recommends a rewrite — go back to the the first points on this list.

(P.S. Here are my thoughts on when all this extra complexity does make sense and if you're struggling with this right now at your company, let's talk!)

I'm on a mission to do whatever I can to nudge us back in the right direction. Not that I think I can actually make that happen, but I'm going to try. I still love the web and what it promises to be and I want it to be a friendly place for beginners. I want to spend more time on delivering value to clients and less time on tooling.

So if you're a beginner I have a different flow chart for you, one that should be less daunting and more exciting. In fact, it's not even a flow chart because it's completely linear. If you're a more experienced developer, what did I leave out or have I included too much?

This list is designed to help you make cool shit on the interwebs that other people can use. Because that's actually the point. Helping other people is the point. And you don't need Webpack or Redux or whatever to do that.

With these core skills you can:

• Build amazing things for clients.
• Avoid performance problems you can't figure out
• Keep things simple and affordable for everyone
• Add new tech to your stack as you need it
• Never fear falling behind modern web trends

HTML and CSS

Markup a document

• Boilerplate and basic HTML tags
• When to semantic markup and when to not
• Classes and IDs

Layout your page

• Understand the box model
• Roll your own grid system
• Float some things
• Flexbox
• Designing mobile first with media queries for larger screens

Style your page

• Use webfonts
• More advanced CSS selectors
• Examine recent design trends and learn how to do a few with CSS
• Use a few CSS transitions

Developer tools

• Basic git use plus working with remote branches, pull requests and Github
• Sass, for variables, simple mixins and imports
• Firebug or Devtools. Inspect elements, view computed styles, change styles.

Javascript and the DOM

Introduction to the DOM

Take some time to understand the underlying DOM API ... then do everything with Jquery.

• Event handlers
• AJAX
• Query selectors
• Get on some web dev friendly mailing lists and social sites, get in the habit of reading about something for a little bit every day. This way you know what exists and you can learn it as needed.

Jquery

• Jquery for event binding/handling and AJAX
• Query selectors
• DOM manipulation
• Animations
• Grok the deferred object

Javascript

• Understand everything in Javascript the Good Parts. I'm not recommending this book for you if JS is a first language or if you don't have a CS background. I loved this book but was an experienced programmer when I came to it. But I think it's table of contents is a good outline for learning Javascript.
• Basic debugging skills with Firebug or Devtools

How to organize a Javascript application

It's tough to recommend a bullet list for this, but here's my take for now:

• Object Oriented Design
• Common design patterns (e.g. MVC, dependency injection, etc.)
• Templates or virtual DOM, and when each make sense
• Testing strategies

But wait, what about ...

Conspicuously missing from this list are package managers, frameworks, ES6 features, different Javascript flavors, CSS frameworks, task runners, CSS "methodologies" and more advanced CSS features like animations.

For all of these, you'll know when you need it and you'll have no problems picking it up on the fly because you know the fundamentals. You'll know why you want Angular instead of React and you'll pick it up quickly because you already know dependency injection because you read up on design patterns, (though I'm not even sure they're doing that in Angular 2 anymore, but this kind of makes my point for me).

If you understand how to organize a Javascript application I think you'll discover that most of the time a few common design patterns that have been around in software development for decades will get you what you need without committing to an entire ecosystem. And when you do decide it's time, you'll know exactly why and how to go about it.

If you're just getting started way back at the HTML and CSS stage I wrote Sketching with CSS for you. It covers everything in the list up to Javascript and the DOM in exactly the detail you need and nothing more.