tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

You might have seen my post from the other week about my upcoming book on React. Today, React in Action is part of Manning’s Deal of the Day. You can get 50% off your order here (make sure to use code dotd110316au!). What’s in the book? React in Action is broken into several major parts. In the first section, you’ll meet React. We’ll dive into some of the fundamental ideas in React and work with components.

I’ve had the pleasure to work on a book about React — React in Action — for Manning this year. It’s been a lot of fun and I’m so excited that it’s starting to be publicly available now through the MEAP program! You can download the first chapter for FREE here. For a short while, you’ll be able to use the discount code mlthomas to get 50% off the MEAP!

This year, I’ve had the pleasure to have been working on a book about React for Manning Publications. It’s been a humbling, hard, fun, and extremely rewarding experience so far. I am deeply thankful to my wife, family, friends, and all the people at Manning who have supported me in this endeavor! Writing has always been a passion of mine and it’s long been a goal of mine to write and publish a book.

Since it seems to be the vogue inevitability for JS/Node engineers to dabble in Go, I am inevitably, well, dabbling in Go. My experience with the language so far has been an extremely pleasant one. In many ways it has been like sipping a surprisingly good cup of espresso that I hadn’t tried before. Furthermore, the approach it takes to extending functionality has been incredible; it’s composition over inheritance, but built into the language.

I originally wrote this as a tutorial for Semaphore CI’s community site; I am republishing my own work here :) Testing React Components with Enzyme and Mocha Introduction Even if you only dabble in the JavaScript world, you have probably heard of React. React has become an increasingly popular and widely-used JavaScript application tool for developing web applications. Popular frameworks like Angular.js, Ember.js, and Backbone have traditionally been go-to choices for front-end application development, but React came onto the scene in 2013 has provided front-end engineers with (yet) another substantial alternative.

tl;dr: Start Simply: Use, build, learn what you need when you need it. Simply Start: Don’t let everything get in the way of doing something. There’s been a lot of talk, writing, presentations, and tweeting over the past year-ish about the sheer pace of development, proliferation of tools, and overall craziness of the JavaScript universe. Whether it’s been endless framework proliferation, tooling insanity, or whatever else, I’ve gotten the sense that people are equally as excited about the new things people are doing with JavaScript as they are fatigued and overwhelmed by everything.

a “stream” of events, being emitted from a waterfall… eh? ¯\(ツ)/¯ tl;dr: In this post we will look at using the Event Emitter module in node.js and how we might use it to create our own event-emitting programs. The repo with some sample code can be found at https://github.com/markthethomas/eventEmitterFun If you’ve worked with client-side JavaScript, you will be familiar with the notion of events. Or, at the very least, I really really hope you are — JavaScript isn’t much fun without one of its core concepts/principles.

Origin Story I asked a question on Stack Overflow about ~7 months back (at time of writing) about requiring and including images in react native. I figured it was a simple misunderstanding on my part about the directory structure(s) used in iOS development, but it turned out to be both 1) something other people were curious about and 2) an area where the react native team was still stabilizing the API.

I don’t know about you, but there are a few modules that I tend to use really often in the projects I’m working on. I usually go with some combination of eslint, lodash, babel, and a number of others. I’ve written briefly about some of my favorites here and here. I also find myself trying to stay current with the latest version of node for security considerations as well as all the other good that comes from using the current stable version.

Are you still a JavaScript padawan learner? Then this post is for you. Maybe you’re still going over the basics of JavaScript, learning how to define functions, how objects work, and some of the other baby steps. And maybe you’ve toyed around with that semi-well known library for querying the DOM (and for doing wayyyy too many other things, IMO), le jQuery. If you have or if you’ve tried out another library, you’ve likely seen something like this:

I’ve been writing a three-part series on some great modules I love and use. This is part two, but make sure to check out the first post. Eslint: If you’re not doing static analysis on your code, you’re carrying around a giant foot-gun…and probably using it, often. Eslint comes from the jsHint/jsLint school of thought, but with some notable differences: Espree for parsing, an AST for analysis, and it’s very pluggable.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

update: This post was last updated on 4/16/16 w/ more-recent react-router. tl;dr: React is the only framework you ever need to learn again! Proclaim it’s superiority from the mountaintops! No longer will we be trapped in the chains of Angular, Ember, Backbone…REACT IS FREEDOM. Eh…Jk. React is really great, but please don’t be that person. We need to love all the frameworks equally, lest we just keep reinventing them over and over and over…and over again ;) I’m way off track of this tl;dr now.

##iojs If you’re even remotely involved with the Node community at all, you’ve likely heard about a fork (of sorts) that has been in process for the past several months. That fork is iojs, and it aims to try out an open-governance model that the Node/iojs community has more ownership of (rather than waiting on Joyent). There’s a great NodeUp podcast that you can listen to if you want to get more if the inside scoop on iojs.

#Get Functional ##tl;dr most of our programs are more complex than they have to be functional approaches tend to result in code that: is easier to read has fewer source lines is simpler places fewer demands on the developer simplicity is really difficult watch this, use lodash, learn you haskell (or another functional language) ##Mmmm…Functional I’ve been on a bit of a functional kick for the past couple months and have really been loving the way taking a more functional approach has helped me reason through and improve my code.