Have you used Yarn? Yarn is like NPM but it has a “lock file” to prevent conflicting versions in sub-dependencies and sub-sub-dependencies from breaking your bundles. It is blowing up for good reason – the lock file is a great feature.

But we all know lots of people are going to stick with NPM, and it will turn into a whole schism until the mainstream switches, or until NPM absorbs the feature (my prediction). Why? Because everyone gets so worn down chasing the de-facto official JavaScript best practices year after year, that new (maybe worthwhile) ideas get ignored with the rest of the cutting-edge.

This is the sad result of too much, let’s call it “future-driven development”, a pernicious malady affecting software projects near you. It comes in many forms, here are a few:

Building and re-building unit tests while a prototype is changing rapidly

Using ES2018 in 2017 with bloated polyfills because “someday they’ll be native”

In academia, you are expected to act like this. Researchers try zany architectures and plan for uncertain future scenarios because that is the whole point of research. If you’re doing R&D in any capacity this is somewhat true – it is dangerous to ignore anything promising and new for too long.

However, people also act like this way too much in the professional world. When building a dashboard for a customer, you are not trying to win Architecture of the Year, you are not building a reference implementation of All Current Best Practices, your dashboard might not always need to run for a hundred years, and you are not building the dashboard for yourself. The tools only matter so far as they continue to help you deliver an effective product.

Objection #1: How do you know what you’re going to need until it’s too late?

You don’t, and you never will. That’s where experience comes into play. You will never arrive at an ideal implementation for any particular set of requirements by following every last one of today’s best practices (most of which were developed to solve a Very Serious Problem that you might never have).

Objection #2: Doesn’t this make it harder to improve future standards?

This objection was originally a sarcastic caricature, which sums up my feelings.

Many of my friends are really upset about the 2016 election. Rather than speaking off the cuff, I’d rather point them here to read some tactfully-prepared comments which I hope will help. Disclaimer: I didn’t vote in this election and wouldn’t have voted for any of the known candidates. There was so much anger, fear, and bitterness motivating support for these candidates, and it contrasted so drastically with my personal experience of 2016, that I felt it best to stay out of it all.

However I do read and think about culture and politics a lot (perhaps too much), so maybe my perspective isn’t worthless.

Based on what you’ve seen, you might decide that old bitter racists got mad at brown people and voted in a Nazi. If this is what you believe then yeah, there is reason to be scared for the future. But I don’t think it is accurate. Here are some of the actual reasons why half the country voted for Trump, all pretty much baseless and off the top of my head.

Reason 1: History and Demographics

The Industrial Revolution is long over, and now the next one is in full swing. Centuries ago, when machinery was invented to perform tasks that had required raw human strength, the displaced laborers caused a stir, burning down factories and I expect getting all up in the politics of the day. In part, this is the same effect on a much larger scale. These days the machines don’t only do the heavy lifting, they do the fine details too. And many industries that used to require physical manipulation simply don’t anymore, because pure information is easier to work with. This means there is a whole generation, the last industrial generation, with nothing left to do. It’s sad. While the young people were going to college and preparing for the new high-tech information service economy, these old people have had basically no prospects, and nobody in politics has been sympathetic to them in a long time. Whether or not he can do anything about this, Trump was speaking directly to them the whole time, and he flipped lots and lots of the industrial-generation folks who had voted for Democrats their whole lives. You can take issue with these people believing that protectionism is a viable solution to their problems, but nobody else was proposing anything new to them.

Reason 2: Racist (etc) White People

OK, yeah, some white people are bigots. Most of those people jumped right on board. You can find their writings online (…or maybe spray-painted on a wall in your neighborhood) if you know where to look, but keep in mind that trolls like to masquerade as those people too. More importantly, your garden-variety racist with a low opinion of Muslims has never had a Muslim friend. Their bigotry is usually born from fear, which is born from ignorance. The proper response is outreach and pity, not ostracism and smugness.

Reason 3: Smugness

On the flip side, many of you have never had an old working-class rust-belt friend. You don’t understand them, and neither do the media folks who have been trashing their culture for decades. For example, the media has played up the racism angle to an unfair degree. Factory workers, coal miners, and evangelicals are people too, many of them smart and interesting people, and while they might not know everything, neither do you. If you have the stomach for it, read this prophetic piece and try to imagine how these folks have seen the coastal elites behave for decades. A surprising number of young college-educated people voted for Trump too, and I’ll bet more than a few did so because they simply picked the side with less smug behavior.

Reason 4: Corruption

I mean come on, by 2016 the Bush-Clinton family was as incestuous and rotten as the last generations of the Holy Roman Empire. Most of the people I know who voted for Trump weren’t particularly fond of him, they just couldn’t stand another anointed Yale scion being paraded around in front of them by Turner Media and the National Broadcasting Corporation. Many of them would have voted for Bernie Sanders if he was on the ticket.

OK, that explains a lot, but we still have an impolite egomaniac with no political experience as president, we’re doomed!

Maybe, yeah, but probably not. America has been through a lot, and most people (yes even the Trump voters) are still basically good people.

What can you do to help? First, make friends outside your comfort zone. This situation is partly the result of years of people shutting out everyone and everything that makes them uncomfortable. We cannot function in the long term as a society where everyone does this. Understand that other people can arrive at other decisions that you don’t like or even hate, and you can still respect them as people. Also once you know them better, you will understand where they’re coming from, and you’ll even have a chance to sell them your ideas.

Second, don’t get disheartened. If you believe in something keep fighting for it. But again always respect your opponents as people, and remember how badly the “smug bullying” tactic just backfired. Play the long game. Be polite, but annoying, and keep it up for a long time. If you are on to a good idea and you can rally long-term support it will win out in the end.

Third, if you are still worried about the nightmare Nazi scenario, exercise your right to bear arms. Never incite violence, but remember that the very best insurance against fascism is a well-armed populace. Regardless of who might actually attempt a fascist coup, the gun-owning basically good Americans will be right there with you fighting shoulder to shoulder if necessary (which we all hope and pray it will never be).

Finally, read more books from the past. Civilization has been around a long time, and in most ways things are better than they have ever been. That won’t change. Your fears about a Republican Supreme Court making over-the-counter contraception illegal might be justified, but keep in mind that we aren’t talking about throwing people in jail for adultery. Maybe some immigrant families will be broken up, which is very sad, but the public is only going to tolerate this policy if they prioritize dangerous criminals like any old law-and-order administration. So if you’re here in America illegally, uh, you probably want to drive exactly the posted speed limit for the next few years.

Future progress for minorities and women and gays needs to be made overwhelmingly in the social sphere, where government will not be involved no matter who is president. Don’t take this political event as a sign that things can only get worse from here. And one day, probably in your lifetime, that last glass ceiling will indeed be cracked.

There’s a common (I think) misconception that the programming trade is all about knowing obscure facts and doing hard math. From this it follows that a person has to get really good at math or know a huge number of things before doing programming.

Unfortunately people who have this misconception can be discouraged from trying in the first place. It might be unrealistic to think that every single person not only can but also will want to do it, but I think that lots of people with this misconception could do very well at programming, once they understand what it is actually like, and if they put some effort into learning it.

In reality, being good at the math or knowing all about compilers and language features does not help with a large percentage of the day-to-day work that most programmers do. Instead, their effort goes into writing down all the assumptions made by the high-level description of a feature. In other words, the requirements will say “display a count of the current total” and the programming work is about finding the assumptions implied by that description (“what does ‘current’ actually mean?” etc), then writing them down explicitly. Once you write down the assumptions in the right way, the explicit representation of the assumptions is your code and you are done. Getting everything written down correctly used to be much harder, but with modern programming tools it isn’t even possible to make some of the most problematic mistakes anymore, and the tools can catch lots of other mistakes automatically. For everything else you would want to get help from a more experienced colleague, or just ask strangers on Stack Overflow.

There are programmers who would take issue with this description. I’m using the terms “doing programming” and “day-to-day programming” strategically, really to mean commercial or hobbyist programming for which there are mature high-quality tools and well-understood best practices. On the cutting edge of academia, and within programming projects that have very demanding requirements, advanced math and knowing lots of obscure facts can be much more important.

Basically, what I’m saying is that people tend to confuse the larger industry with that super-difficult hacker nerd work they see in movies and TV shows. In fact, the vast majority of programming work going on right now is the other kind. There are huge numbers of those jobs to be done, because it is where all the theory and advanced knowledge finally can be applied to a real-world problem. Many large software teams have so much of this kind of work that they split out a whole department for “requirements engineering”, which is taking the really high-level descriptions with tons of assumptions, and breaking those out into statements with fewer or no assumptions left in each statement, so that the code writers can focus on making the final code work. The best requirements are harder to write than all the coding work that comes after!

Maybe someone has told you before that programming is all about breaking problems down into smaller problems. It’s another way of saying the same thing.

Have you ever had someone tell you that liberalism is a mental disorder? Or that right-wingers vote for bad ideas just because they have an irrational world view? It’s a pretty common ad hominem in politics, and not a compelling one. The idea is a tautology: Find two people who have incompatible ways of looking at the world, and each will think the other’s way is somehow defective. But this silly tactic shows up in elite intellectual discourse way too often.

An early example is The Anti-Capitalistic Mentality by Ludwig von Mises, a book-length psychoanalysis of the author’s political opponents. The short version: people who resent their betters turn to communism since it means bringing everyone else down to their level. It’s not subtle.

More recently, academic examples skew leftward. To be clear, this is not a claim that left-wingers disproportionately rely on ad hominem. Nor is it a claim that there is some disproportionate weakness in the right-wing psyche. It’s probably because more psychologists are left-wing than ever before, and since the attack is based on psychoanalysis it shows up a lot in their literature.

Recent examples can be found with a quick internet search. Here are a couple:

Although these papers are more nuanced and focused than some all-encompassing manifesto, they are still ad hominems. The authors can and will claim that their research is purely academic and not intended as any kind of attack, but let’s be honest, there is one big obvious way this kind of research will always be used. It will be served up on popular political websites and compiled in brightly colored books, ready to be used as Thanksgiving ammunition.

The literature often uses global warming as an example, and a few things are going on here. In many circles global warming is an indisputable fact, so if you want to deploy some political ad hominem against the people who tend to be skeptical, it’s a great starting point. Also, the global warming movement hasn’t succeeded. This approach serves both as a play to convince voters after all, and as something to offer environmentalists disappointed with and confused by a lack of success.

The classic example in the subgenre is Lewandowsky et al’s famous Recursive Fury, a paper psychoanalyzing those who reacted poorly to another paper psychoanalyzing global warming skeptics. How it got through more than five minutes of planning without being abandoned, we may never know. In any case it was eventually retracted.

Another interesting example is On the relation between ideology and motivated disbeliefby Campbell & Kay. To its credit, the paper does attempt to strike a balanced tone, supporting an ad hominem attack against both political parties. Still, they put a whole lot more effort into the global warming part, and the fourth study might be a strategic addition to give the impression of dispassionate science.

These ad hominems have been around for a long time and they aren’t going anywhere soon. But they are silly and don’t belong anywhere near academia. Even with the veneer of science, the tactic only convinces people who are inclined to accept the ad hominem anyway. It looks desperate and stupid to everyone else.

Version tags are a pretty simple technique I’ve used with ReactJS to optimize rendering larger apps. This optimization does not add any dependency on an immutable data library. Right away I have to say that this is not something you want to be choosing all of the time. If you want to be able to use shouldComponentUpdate optimizations easily by default, or if you have any reason to be saving and replaying undo history, then you should seriously consider using an immutable data structure. But there are a couple of common reasons to skip that piece of architecture. First, If you simply cannot afford to load any more JavaScript after ReactJS and the other libraries you might already be using, then the convenience of ImmutableJS or a similar library might not justify the overhead to load it. And second, if it would be too difficult to learn and/or integrate ImmutableJS with your existing architecture, this is one alternative. In some ways it is much simpler, but in one important way it is more difficult to use.

If you want to do a very clean implementation of a flux-type architecture, your data might propagate down from a top-level “controller-view” through a whole big tree of React components. Each component in the tree will potentially render on every state change, so to avoid this you want certain nodes to be implementing shouldComponentUpdate and checking if their particular data has changed. The simplest way to do this is to flatten all props and check them one by one. While this can give a performance boost, the boilerplate required to do so can get ridiculous. ImmutableJS and similar libraries eliminate this problem by making the state an immutable data structure. Basically this means that every time a node in the state updates, that node is copied and a new reference is made to hold the new node, along with every node directly above it in the state tree. Then any component which only needs a particular state node to render can check if that reference has changed, and superfluous rendering can be easily skipped. Having the old nodes around also makes undo features trivial to add.

Here’s how version tags work. Instead of copying the node(s) that you need to be updating, you just change a version tag on those nodes. Then instead of checking an immutable reference, the components check if the version has changed to see whether to render. That’s it.

This means you’ll have to add a version tag to the same scope as each node of data you want to be able to optimize for, and it means you will have to manually update the version tag every time something in that node changes. This approach is a sort of middle ground optimization between checking every individual value type at one extreme, and working with and checking an immutable data structure at the other. However in some situations it has the potential to perform better than both.

As a simple example you might have an application that displays a list of clients and a list of appointments. You could add a version tag to each object in your state:

And then if you ever update something in appointments you’d do appointmentsVersion++; as well. The component that renders the appointments implements shouldComponentUpdate which just has to compare appointmentsVersion. Versions can be added to as many nodes of the tree as you like, to get the degree of optimization you need at the time.

Will updating versions all the time be in several ways less advantageous than using ImmutableJS? Absolutely. But it is a useful technique.

Here’s a list of ideas and techniques I’ve used when working with ReactJS and Flux. There are two sections: general suggestions of how to get good results, and notes from optimizing for slower hardware. Hopefully they provide a little bit of insight for when you’re looking at all these new concepts and going:

Ah yes interesting, why not continue reading the web page?

It’s difficult to say which of these items if any would definitely be “best practices” but they are available here for reference. Use at your own discretion and happy coding. Several ideas are from [0]react primer draft and [1]tips and best practices, both good resources to introduce and guide learning on the subject.

General suggestions of how to get good results

This has been said elsewhere, but get as much state as possible into one place in your application. With Flux this is the store(s). The first diagram from [1] with one-way propagation of data through the tree of components is the ideal, meaning no this.state anywhere. However, there will inevitably be integrated components which have other state, and this should be as contained as possible using this.state and callbacks. Also, any state which is definitely only significant to the one component (such as the open/closed state of a dropdown menu in many cases) can be kept internally without a problem. With Flux this leads toward fewer or even no meaningful state updates happening outside the standard data flow, which is very nice.

Some action creators get data from AJAX and pass it along by dispatching an action. There is a way to do this with one REQUEST action and then one RECEIVE action, which is kinda nice because they can be tested and implemented separately, and the REQUEST action doesn’t have to have any callbacks. Another option could be for the action creators to attach promises with each asynchronous action. Then the stores or a service could unpack the data before updating the state. I haven’t actually used that method and there are cases where it doesn’t provide as much flexibility (simultaneous AJAX actions may cause a “cannot dispatch in the middle of a dispatch” error), so try at your own risk.

Notes from optimizing for slower hardware

Another point from [1], but definitely use the pureRenderMixin and/or implement the same kind of behavior with shouldComponentUpdate (more on that below).

I didn’t realize for a while that you shouldn’t just run the dev source through a minifier for production. With so much relying on pure JS interpreter speed, all those great log messages and debug exceptions make quite a difference. Make sure to build or copy the actual production script when using React in production.

There are two basic ways to show or hide sub-components based on UI state. One is to leave them out of the render (I’ve used a ternary expression that returns null if the sub-component is invisible). The other is to render them with a “visibility” prop and have the sub-component set a display:none style internally. The first method keeps the DOM small and clean, but it means more DOM manipulation each time you show or hide the sub-component. The second is more efficient if the sub-component visibility changes often, but it means more DOM elements in the page at any one time (although some are invisible). When optimizing, use the strategy that is more appropriate for the situation.

Don’t put complex literal props inline. These cannot be used with shouldComponentUpdate since === will return false every time. Maybe you shouldn’t use literal props at all, but that is if you want to set up constants for everything (usually not a bad idea).

Use shouldComponentUpdate. As far as I know there are four basic optimization strategies with shouldComponentUpdate:

One is to split up complex props into lots of flat value props, and just check through each one. I would think this can get verbose and maybe a little less efficient, but doing a bunch of === checks should get pretty good performance with little additional code complexity.

The second is to use a library like ImmutableJS or Mori to build an immutable state tree and update it through controlled methods. This adds a dependency and some not-very-serious overhead but enables pleasant management of an immutable state object that can be compared before re-rendering quickly and easily. The argument to use an immutable state object is much stronger if you have to implement some kind of undo/redo functionality, but either way it’s a great idea in many situations.

The third is to hand-roll some kind of version checking in each shouldComponentUpdate. I feel like this has the potential to be a very lean strategy CPU-wise but it is also a bit more complicated to maintain. Basically you add a UUID version tag to each node in the state tree you want to optimize, and whenever updating that node you also update the version tag. Then shouldComponentUpdate is just a matter of looking at the version tag for the node.

Finally there is the strategy of running shouldComponentUpdate fewer times. This is where you might use internal state in lower-level components, and refs to skip typing in a textbox. Another option is to set shouldComponentUpdate to always return false, and use componentDidMount and componentWillUnmount to set up and clean up DOM elements that are directly manipulated from componentWillReceiveProps. These are mentioned at the end of the list because for all but trivial cases moving state out of the standard flow will make code more complicated since synchronization between the two state repositories is now a requirement. Before using them take some time looking into alternative solutions.

Commuting in the car means a lot of time spent accidentally thinking about how it could be improved. I’ve come up with several ideas for accessories, and this first one is useless but very fun. For some time I was planning a system where buttons on the dashboard displayed messages on the rear bumper. Stuff like “C’MON, REALLY?” to display to tailgaters, and maybe amusing stuff like “WHAT’S WRONG WITH THIS GUY?” when someone up ahead is driving poorly. It would be a pretty straightforward bank of switches plugged into an Arduino, and either a screen with pictures or (better) a train-schedule type letter sign, if those can still be found.

A few weeks back, however, I remembered that dog picture from the Internet that says “deal with it” when the sunglasses drop:

This one

I realized there couldn’t be a classier way to respond to tailgaters than with a live-action version, so I decided to make one. It would be a simple Arduino project, with a servo that lowers the sunglasses over the eyes of a stuffed dog. Then a relay would light up the “Deal with it” text on cue.

Setting up the Arduino code and wiring the components didn’t take more than a few hours:

Arduino wired to button and relay

Then there was the simple matter of printing out some sunglasses and attaching them to a servo (cardboard backing, super glue, and a zip tie for the arm):

The dog with its future sunglasses

Finally the sign had to be prepared. I decided to go all out and buy a real neon sign, since that is totally fantastic and you can get them custom-built. The sign arrived with this nice label:

I also opted to buy a pre-packaged relay to switch the sign, since I’m not a trained electrician and you don’t want to trifle with AC power from the wall outlet. The PowerSwitch Tail II is great, you just plug in 5V and ground wires to the side and it works like an extension cord with a switch. The rest of the wiring was just a couple of leads going to 5V and ground, and one pull-down resistor for the button. I also got a 300 watt inverter to provide power from the car battery, and a big red button to activate the sign. Wiring it all together for a test run, it looked pretty good:

The sign turned out to be bigger than I had figured, and it takes up the whole back window of the car. Luckily it has a clear backing so my view isn’t obstructed. There’s still some polishing to go, but it’s working very well.

Nobody has tailgated me anywhere near the threshold level for sign-activation yet (perhaps this is rarer than I thought) but it’s bound to happen eventually. You know when you’re waiting in a line of cars to pass a slow-moving truck, and some chucklehead decides to tailgate you, so that maybe you’ll do the same to the car in front and so on (I assume)? The next time that happens to me, I’ll press this button on the dashboard:

And I’ll take my sweet time to finish the pass. Meanwhile the offending driver will see this: