I had a conversation with a friend yesterday who is looking to fill a role in his company and expressed some frustration with a challenge I've been seeing lately as well:

I have had some trouble hiring a front-end person, basically a WP, Foundation, CSS, JS person to fill a low-level production role in the company. I can’t figure out what the deal is, all applicants have no “base knowledge” of the above, they can produce react or other JS framework sites, or create through the WP template system, but if I said, I need some straight CSS changes, blank stares…. or some vanilla JS stuff, nothing.

There are no shortage of boot camps, courses, and resources to learn front-end development out there, but having interviewed a lot of the folks coming out of these boot camps, I think there is a serious under-appreciation of the importance of CSS and the fundamentals of JavaScript.

Granted there are limitations on how much one can get across in a 12-week boot camp, but a huge part of the problem is our industry's fascination with the new, obsession with the latest and greatest SPA framework, and devaluation of CSS and "older" implementations.

Fascination with the new

Our industry has a fascination with new approaches to doing things. What else can explain the constant drive to throw things away and "rebuild from scratch" every time a newer, better, and more complex framework rolls around? Every time we insist that this will lead to a purer, cleaner, more perfectly abstracted architecture, and every time we end up reinventing techniques, recreating bugs, and rediscovering all of the edges and corner cases that led to the previous ugly code.

This isn't to say that there is never a time to re-write or that newer is never better, but rather that we fall victims to the cult of shiny things and the idea of the perfect abstraction. Every new architecture remains perfect until it is forced to grapple with real world requirements. Unfortunately, humans are messy beings, and all of our software is being built to tackle human problems, and so every real world software program ends up with leaky abstractions, awkward edges and corner cases, and new compromises.

This rush to continually rebuild and focus only on the latest and greatest often throws away prior solutions to those very same problems you'll end up solving. It also ends up applying new tools to completely inappropriate problem domains, just because they are new.

Obsession with the latest and greatest SPA framework

Publishing a newsletter on front-end development, I see this problem manifest every day in the current SPA boom. I read a huge variety of articles that folks are writing about different technologies, and let me tell you, almost everyone in the JavaScript world is writing about one or the other of these frameworks, as if each one is a completely new and unique innovation. While they are great tools, they're each built to attack particular problems, using similar underlying fundamentals and making different choices about usecases to optimize for.

I'm going to momentarily pick on React for a moment, because they've had such tremendous traction these last few years...

Don't get me wrong, I love React. It's a phenomenally powerful tool, and makes it not only possible but straightforward to implement user interfaces that would have been impossible when I started in web development. However, folks coming into the industry see all of the buzz and hype on React and assume they are the one and only truth of how you should write JavaScript. Making a new web application? Use React! Creating a custom blog template? Use React! Updating an old migrating site? Migrate it to React!

This is a disastrous approach to technology! And don't listen to me, listen to one of the most prominant developers in the React community, Dan Abramov! When Cory House put out an inquiry about downsides to React, Dan was one of the most prolific responders:

Its performance is worse than templates if many things update extremely fast at the same time. For example stock trading apps.

— Dan Abramov (@dan_abramov) September 16, 2017

It trades memory pressure for expressiveness. React apps typically do more short-lived allocations under heavy load.

— Dan Abramov (@dan_abramov) September 16, 2017

It’s mostly driven by the needs of Facebook. So if your apps are very different from what FB is building, may not satisfy your use case.

— Dan Abramov (@dan_abramov) September 16, 2017

This is only a subset, but Dan's openness led Cory to respond:

Gotta say, I'm floored that the best input I've gotten on why "not* to use React is from you Dan. Really admire such candor and nuance.

— Cory House 🏠 (@housecor) September 17, 2017

Clearly Dan is under no illusions about React being perfect for everything; he is intimately familiar with the tradeoffs they have made! But so much of community is rushing use SPA frameworks for everything and completely neglecting the fact that these are tools developed to tackle particular problem domains. Yes, they are phenomenal tools, and great fun to develop in... but they are also often completely unsuited to other problem domains.

By emphasizing the frameworks over everything else, we blind ourselves to solutions that are far more appropriate for many of these problem domains.

The Devaluation of CSS

There is a tendency in the industry to degrade HTML and CSS as "not real development" and somehow lesser degrees. I think this comes from the glorification of logic over graphical and spacial thinking... CSS and HTML embody hierarchical, graphical, and spacial relationships, while JavaScript focuses primarily on logic.

Now, the amazing thing about logical languages/expressions is that it can often encompass the other types of relationships... allowing you to express a spacial relationship in the logical language. However, we as an industry often misinterpret that greater breadth of possible expression to mean that expression in that language is strictly superior.

This is NOT the case!

In fact, looking at mathematics and physics as examples, it is often the other way around! In those fields even if you start from a logical model, you often work desperately to find a spacial or graphical model that you can apply to it.

The reason is those spacial models often expose far more intuitive or compact ways of thinking of problems and allow us to derive far-ranging insights, which we then laboriously figure out how to translate back into a logical approach.

CSS gives us an incredibly powerful framework for expressing graphical and spacial relationships, sometimes extremely complex ones!

Complexity is conserved

This brings me to one of my core theses about software development - Complexity is conserved.

Any problem you are trying to solve has some inherent amount of complexity to it, and that complexity has to be accounted for somewhere.

There are many ways this surfaces, but the way that it shows up in this example is in the complexity of expressing graphical and spacial relationships. There is a tremendous amount of complexity embodied in the way different elements on a page are related to each other spacially, especially as those elements are manipulated, moved, and put in relation with other elements. That complexity has to be accounted for somewhere, and with CSS, the browser does most of that work for you!

Truth. I worked on a project that had 2000 lines of JS to do what position: absolute already does because they didn't understand it

— Sarah Drasner (@sarah_edo) September 16, 2017

What do we need to do?

I'm not trying to say that we shouldn't use or teach people about the latest and greatest tools. SPA frameworks like React, Angular, Vue, and Ember allow us to create incredibly powerful interfaces on the web that could never have existed just a few years ago. These tools are truly responsible for a re-imagining of what is possible online.

But I think we need to ditch the SPA elitism, and re-emphasize the importance of the fundamentals and choosing appropriate tooling for the problems being solved.

The creators of these frameworks rarely claim them to be good for everything, but we as an industry have raised their prominence to the point where new entrants to the industry skip completely past the fundamentals and assume that these complex toolchains are the only "good" way to solve problems.

If all of our new engineers look with disdain upon CSS, we end up with 2000 lines of JavaScript attempting to re-implement position: absolute;.

If all of our new engineers assume one can only write HTML and JavaScript within the domains of a SPA, we end up with massively over-architected, buggy, and slow blogs, marketing sites, and everything else that is already well solved-for by older solutions.

We need to have a serious conversation about what skills we expect in our industry, and what we're training folks to do. It's well and good to kickstart someone quickly through a bootcamp, but there is a serious gap between today's bootcamp grads and what most of the industry needs. It may not be realistic to expect someone to get to where they need to be in 8 or 12 weeks, but we should at least give them a path to get there.

Towards a Curriculum of Fundamentals

I haven't put together a complete curriculum of web fundamentals, but I've got a few items I'd definitely include on it. I've put those below with link to both free and paid resources for learning more, but what would YOU include on the list? Let me know in the comments.

1. Basic Box Model. This is a key fundamental that you MUST understand. As a free resource, Shay Howe has a great article as a part of his free Learn to code HTML & CSS course. On the paid side, especially if you're more of an audio/visual learner, my friend James Stone has a nice Video Course on the Box Model

2. CSS Specificity. Another key fundamental that you need to understand if you're going to be working in the web. Without a strong understanding of specificity, you'll continually struggle to get your CSS to behave the way you want it to. Smashing Magazine has a great overview to start with.

3. Flexbox. Flexbox has revolutionized our ability to lay things out on the web, and you should definitely be up to speed on it. The best flexbox resource I've seen is this one by CSS Tricks. If you're looking for a video course on Flexbox, check out this one on Treehouse or this one on Udemy

4. CSS Grid. While new, and still not able to be used by folks who need to support older browsers, CSS Grid is hugely powerful and definitely the way forward for creating layouts. Great free resources include this CSS tricks guide and Rachel Andrew's Grid By Example. On the paid side, Rachel Andrew is the guru and so definitely check out her course, or if you're looking for less expensive options Treehouse has a good intro.

5. Basic CSS Architecture. This is a really deep topic, and I don't want to go too far in, but if you were to start in one place I'd read the free SMACSS book. It will give you a great understanding of some of the fundamental principles of CSS organization and concepts - from there you can go on to other approaches and conventions like BEM, ITCSS, and more.

JavaScript

1. Types and Coercion. Types in JavaScript are weird. That's all there is to it. They're way on one end of "weakly typed", and have some bizarre behavior. If you're going deep on JavaScript, you need to understand them. The best resources I've seen for this are the first 4 chapters of "You Don't Know JS, Types and Grammar".

3. Contexts and this. Understanding this is fundamental to a deeper understand of what's going on in JavaScript code. Misunderstanding this is the number one source of confusion I see in junior JavaScript developers, at least partially because so many popular libraries use and abuse it. (I'm looking at you jQuery!). To build your understanding, I recommend this excellent article by Zell: This in JavaScript

4. Closures. Closures begin to unlock all sorts of concepts for you, letting you see why see why seemingly almost identical code can behave so differently, and getting you started down the path of thinking of functions as first class objects. This is a good written intro from Free Code Camp: Let’s Learn JavaScript Closures

5. Events and the Event Loop. The event loop model makes JavaScript different from many other programming paradigms, and without a good understanding of it you can be in serious trouble the first time you start to handle nontrivial interactions between different asynchronous actions. I haven't found a resource I absolutely love for this (let me know if you know of one) but this blog post by Carbon Five isn't bad: The JavaScript Event Loop Explained.