I'll give you one reason for line length limits... being able to intercept potentially dangerous/viral code injection. If you limit your line length to something most devs can view (120-150 chars), then the risk of someone injecting viral code into a project outside what is visible on a line is significantly reduced. I'm not hard pressed on line lengths of 80 characters or so, I just feel that you should have a relatively reasonable limit so you can better detect the bad stuff.

I would suggest replacing the XHR raw requests with fetch api, to simplify the examples, which I think distract from the topic at hand.

Like most things in a developers life, it depends. Even on the front end, especially in a browser context, understanding patterns is important. It helps to understand why certain behaviors happen and how to avoid bottlenecks. It also depends on the complexity of what you are working with. There's a reason why certain patterns become more popular than others. Beyond this, I personally hate being pigeon-holed as a "front end developer." I understand database structures and why certain approaches are better in some situations vs others. I know how communication channels work, and why one might implement things in a certain way on the middle-tiers. I can work across the stack. Most "full-stack" developers are weak on the front end. And many "front-end" developers are weak all around. I think it's up to each individual to be the best they can be across as broad a field as is appropriate for them. Even in the front end, it's important to understand how and why certain things work. Why you'd use an object as a dictionary, instead of a lookup on an array. The little things add up. When you understand many of the typical patterns, you see them take shape in what you touch, even if you aren't writing them.

I have to respectfully disagree... Sass and Less were created to overcome a couple of shortcomings in CSS.. namely variable declaration and reuse and a clearer nesting structure (makes using media queries much more natural). JSS allows you to do this in JS in addition to having reusable features without having to know a domain specific syntax (less/sass mixins). The reasons to use JSS are similar to why you might use less or sass... JSS in particular works very well with React. I know some of these things are coming to CSS proper, but they aren't broadly supported in browser, and have some clunky syntax to say the least.

As long as you are using some form of module bundler (webpack/browserify/rollup, etc), you can go a really long way with relatively plain JS... The only reason I mention using a bundler is it allows you to write your code in discrete modules. As it is, you can go a very long way. Also, it makes it easier to add micro libraries via npm after you've done this, which allows you to stay very close to vanilla while still being able to support a growing codebase.

Depends on the size of the snippet.. will it fit in a tweet, tweet it... Otherwise, gist and tweet the link... Larger, github repo... YMMV, but good bad or indifferent, if rather my snippets be out there... If they're useful in the future I can find them again.

Fyi, to those reading this.. Inconsolata (mentioned above) is an open look-alike to Consolas. It's my favorite too.

Following on the Lego analogy... Angular is like a Duplo-Mindstorm Aircraft carrier kit.

You first need to look at what you're trying to do or build. If you're just wanting to learn react, don't do it all at once... If you're wanting to step up your JS skill, that's a different story. In general, for current web apps, you should probably be using a transpiler (like Babel) and a bundler (like webpack). Understanding JavaScript, including es6+ will go a long way... Being mindful of functional paradigms will take you farther. Once you have that, you should either start with just React or use a boilerplate. Redux has become the defacto state machine to use with react, but not the only choice... In the end, react is about displaying your data/state, and controlling event flow works with that. All of the pieces are like Lego blocks... React isn't the build a pirate ship kit... It's the mega starter kit with 2000 pieces of multiple shapes and sizes to choose from with the Mindstorm kits as an add-on option. There's some recommendations, but it comes down to looking at your needs and working out from there.

I like web components for rendering and localized state... I think it's pretty clean and works. That said, I like react over polymer for structure, and combined with Redux for control flow. I'm the end we'll see more web components, not sure about polymer though... it really depends on the application though. React does well with crud apps with some shared state and minimal points of interaction... polymer and web components do better the more interaction needed (animation, lots of drag events and ui to go with it). In the end it's a matter of using what you like and what makes sense... most applications shouldn't be that complex and people tend to make them more, not less so.