Developing Upwards

Every developer finding their way around ReactJS is going to come across CSS Transition Groups sooner or later. These helpful components built by the ReactJS team but distributed separately help to manage animations related to adding or removing elements from a list. This is important in ReactJS, because the virtual DOM reuses nodes as much as it can, meaning what seems like a new element but really be reusing nodes underneath. You can read all about the  ReactCSSTransitionGroup  at the React documentation, but I want to note about one way you might trip integrating it with your project:  building vendor bundles for your dependencies. If you use  Browserify  to bundle your own code and its dependencies for distribution, you may be using the vendor bundle pattern. This is the practice of separating your distribution into two bundles: one containing your dependencies, including ReactJS itself, and one with your own project code. This is a good pattern becaus...

I like to think I'm a good web developer. Getting here was the result of experience, practice, and constant curiousity. Lately, I've wondered if the passive nature of that curiousity has run its course. The pace and breadth of changing technologies as a web developer can be both breathtaking and overwhelming at times. What do I need to know about WebAssembly, WebGL 2.0, or the differences between Browserify and Webpack? Do I need to know about any of them at all? How do I learn enough about each just to understand if its something I need to understand even more deeply? Beginning an effort to make that ever driving curiousity more directed, here's a list of things I don't know enough about, but would like to study better. Webpack I know  that Webpack can replace Browserify and recently have understood it may replace some (or all?) the ways I use Gulp today. I don't know  if the change would impact more projects beyond the build scripts or how much time or...

I had an adventure over the last couple days with ES6! There was a pattern I'd already used in a few of my React projects to make ES6 classes a little nicer. ES6 did a lot to make working with  this  mechanics nicer, but there was a still a gap that bit me: the sugar provided by ES6 classes don't extend to keeping method bound to instances of the class. Maybe you, like me, would expect this to work: class Counter { constructor () { this . count = 0 } onClick () { this . count += 1 } } counter = new Counter () document . querySelector ( '#add-button' ). onclick = counter . onClick But, like non-class methods on any regular Javascript object,  onClick  will loose its binding to the  Counter  instance. There are a few existing solutions to this, but I wanted one that didn't change the syntax of defining a method on these classes. Enter AutoBind, via my new NPM module  es6-class-auto-bind : import Aut...

I’m really excited about ReactJS. I’ve let my tentative excitement grow for a while now, with a few experiments and tutorials and lots of reading. There is a strong habit of Shiny New Thing syndrome in the web world, and I’m as guilty of it as anyone else, so a lot of effort was made to avoid jumping on the bandwagon too soon. After building my first simple but complete application with ReactJS (and Flux) I’m absolutely convinced it is the best option for me to build web interfaces going forward. To share my excitement and to preserve my thinking, in case I come back in a couple years wondering how I got started with ReactJS, I’m going to outline all the reasons I’m so excited about ReactJS. ReactJS is Fast in Every Way That Matters Saying a software library is “fast” is often a red flag for not having a holistic view of the trade offs. Faster than what? Fast by what measurements and under which conditions? I can say that ReactJS is fast because I’m not saying one vague thing, but sayi...

I try to keep my skills up and its hard to do when the thing you try to have skills in is always changing. The web landscape is always in flux, at a seemingly ever-increasing pace. Javascript represents only one area of the web, and as a language within a much greater ecosystem even that microcosm can keep you busy with the evolution of the language itself ( ES6 ), constantly rolling out new in-browser APIs (like the new Web Cryptography API ), and learning to sling this language both inside browsers and on backends ( Node.js ). One of the best tools I have to keep these skills sharp is the practice of what you call “Vanilla Javascript”. I try hard to find lots of small opportunities to practice Javascript without the abstractions of all the myriad of libraries and frameworks that might obscure it even in the course of a single day’s work. I find two simple strategies help me poke through the cushion these tools provide to make sure I don’t forget what’s under the hood. On ...

The days of XMLHttpRequest and weird choices for capitalization are numbered. WhatWG has a spec ready for some time now to replace it: window.fetch. Just look at how easy it is. Just look at how nicer that is all with soon-to-be native APIs. But you don't have to wait, because there is a polyfill available. Start using the Fetch Polyfill in your projects today.

Over on Tao of Code, there is a great little write up on Promise anti-patterns. Having been using promises heavily for the past year in my Javascript, I can say I've hit at least half of these and probably the other half without realizing it. I recommend you check it out if you are or soon will be using Promises! Promises are very simple once you get your head around them, but there are a few gotchas that can leave you with your head scratching. Here are a few that got me. Get the full scoop: http://taoofcode.net/promise-anti-patterns/

Introduction I’m coming to an opinion of Javascript module loaders that is profoundly negative and I’d like to express why I think they are, generally, a bad idea. However, I do think they have a place, which I’ll get to at the end. Now, I understand I might be in the minority here. Between the competing specifications of CommonJS and AMD modules, loader systems like RequireJS or the (honestly really awesome) Google Module Server, and the huge cultural influence of Node on the Javascript world, you’d be hard pressed to argue against Javascript modules these days. Scripts are old hat, too stupid, too inflexible. Everyone knows that and no one would make an argument in their favor, right? I’m going to step out on a limb and say “Javascript Module Loaders Considered Harmful” and I know the baggage involved with declaring something “Considered Harmful”. I mean every ounce of context that phrase carries with it, and I hope I can persuade you. Harm #1: Confused Debuggers ...