So I am starting a new job on Monday with Tilt as a Frontend Engineer. In the process of doing this I've been reacquainting myself with the frontend landscape. In talking with a friend I realized that there are many things to learn and maybe not a lot of guidance. This is my attempt to compile a set of learning resources that either I found helpful or that I think I would find helpful for someone who was just beginning frontend development from a predominantly server-side role.
This is intentionally uncomplete. Frontend is a rapidly changing landscape and I have been focused on other things (that are also wonderful) for the last few years. I understand Angular at a high-to-medium level but haven't dug in enough to consider myself proficient. I need to take time to evaluate Ember as it seems very good from a distance. So I am still learning too.
In this collection I want to highlight resources that encourage different ways of thinking about frontend code (new concepts). While tools like jQuery are great and need to be learned, I don't think that the library really introduces you to many new concepts over what the DOM already provides - it is just a "better" DOM interface. To handle performance bugs with your code you will need to understand what jQuery is actually doing under the hood. So knowledge about underlying technologies is very useful.
This is intentionally biased towards things I find interesting (tools that promote fundamentals and libraries built off of "crazy ideas") and away from things I don't ("wrapper" tools that provide a different interface). It is biased towards particular formats that I like (blog posts and websites) and away from others that I don't (screencasts and books).
I agree with most of the advice here. The only thing that I don't like is their promotion of the
this or don't use patterns that require
this (e.g. don't use
new to make objects).
Weekly news magazine.
Web development today is different from it was in the past - it used to focus on browser compatibility and wrapping the DOM into a uniform interface. (I think this is a fair statement: I was not doing frontend development in the days of the IE6 box model hack.) With modern browsers that auto-update, our attitude towards jQuery and polyfills should be re-evaluated given the current state of browser development. Sites that challenge the dominance of jQuery are important for this and whether or not you agree with the conclusion you should be aware of what is provided by jQuery and what is provided by the DOM.
Bigger Ideas About Application Structure
Reimplements a TODO list application in nearly every frontend framework.
Suggested application architecture from facebook -- encourages a 1-way flow of data instead of components that have 2-way bindings.
Example training material for learning React through building some example React components.
Polymer polyfills web components so that they can be used today. Goes further and allows you to declare web applications in a fully declarative manner. I don't think that declarative is an "end goal" that works for everyone but I really admire the commitment to see the idea to its conclusion.
React relies on the idea that you can just rerender everything rather than maintain stateful components. To do this it relies on diffing the old DOM and the new DOM and only updating the parts of it that have changed. To do this efficiently it relies on some heuristic algorithms, but these can't always be sure and will sometimes need to do expensive computations to determine whether or not a DOM node has changed. Om is a ClojureScript library from David Nolen that uses Clojure's immutable data structures to rerender everything efficiently through reference equality. See also
immutable.js from Facebook.
CSS is not an area of strength for me. (Not saying I am horrible at it -- just, I would not lead with CSS as a key skill that I will differentiate myself with over another applicant.) Here are some ideas I think are helpful in turning your interactions with CSS from "how to do it?" to "how to do it right?"
Object-Oriented CSS has some opinions about how you should be doing CSS (generally: only style classes, don't style ids, don't use descendent styles). We introduced many of these guidelines onto a past project with good success.
Talks about the "CSS journey" that Medium has been on. Highlight antipatterns that the team found themselves in and how they were overcome.
Something I love about frontend coding is the incredible diversity of the landscape. There isn't "one way" to do anything - the community gives you a number of different approaches that you can apply to your project. The other side of this is that you will frequently adopt one approach, commit to it, and then everything will change around you, leaving you with a big investment to an out-of-date framework or library. However, if you don't commit to a library or framework you end up with a large amount of code that reinvents the wheel.
I don't think this situation is necessarily bad -- I see it as a natural consequence of having such a vibrant community. There is something frustrating about seeing a number of options and knowing that no matter what you pick, it will not be the best thing in two years because of circumstances beyond your control. However over the last five years frontend development has evolved from being primarily polyfill and trivia based (thus necessitating libraries such as jQuery) to focusing on what I'd consider more classical software engineering problems such as application structure. With browsers adopting faster delivery cycles and focusing on cross-browser standards I hope that we will never need another library that was as universally adopted as jQuery was. We'll see what happens in a few years.