Links Thoughts

Bringing Back the Personal Site

There have been quite a few articles recently about the importance of the personal site, and the blogging community. It’s a sentiment I’m super excited about.

Rian Van Der Merwe has probably the simplest point. Blogs are the front page of the internet, and it’s their freedom that gives them their strength.

All this to say that I think it’s time we bring blogging and personal sites back. Some of my favorite sites are the ones that give me a glimpse into everything a person is interested in… It’s a way to get to know someone through their interests, and to learn a bunch of things along the way. So I invite you not just to follow along here as I expand into topics beyond design and technology, but to start your own personal blog up again if you’ve been neglecting it for a while.

Tom McFarlin pointed out that a personal site was a great way to ensure that you own your own data, so that it can outlive and outgrow the third party, walled gardens we’re all used to.

Imagine being able to continue sharing information, but also continuing to own all of the information for yourself by simultaneously bringing it back into a database into an area you own.

Pretty exciting, right? At least for those of us who are tin foil hat types.

Reacting to Twitter’s plan to keep long form content on their own site, Mandy Brown discussed the magic of the hyperlink and the journey that is the open web.

In addition to places to talk… they have also been places to venture off from—you start in your feed, but you end up in a browser, half a dozen clicks away. If everything comes to your feed instead, will you never leave? Will this be like working in one of those startup buildings with their own coffee houses and cafeterias and laundry services, where the streets outside could flood and you wouldn’t notice for days?

Then, Dave Wisner lashed out at Medium, but I think more importantly, talked about the opportunities for a new blogosphere, one that is more connected then ever, (and that the WordPress REST API can certainly play a part in).

But there is another approach, to have WordPress accept as input, the URL of a JSON file containing the source code for a post, and then do its rendering exactly as if that post had been written using WordPress’s editor. That would give us exactly what we need to have the best of all worlds. Widespread syndication and control over our own writing and archive.

As a bit of a retort in The State of the Casual Blogger, Ghost founder John O’nolan was quick to point out that people use services like Medium because they’re easy, fun and simple. And, hey, maybe we should try that, but at the end of the day both will continue to exist side by side:

There is more than enough room in the publishing industry for open and closed platforms to exist in harmony, catering to different types of writers with their individual advantages.

In 2016, I want to start writing again, and sharing things as I come across them. I always want to work on tools that can help personal websites become a central hub for all of our data and content that’s currently distributed all around the internet. Looking around, I guess I’m not alone.

Thoughts WordPress

The Responsibility a WordPress User

Last week, WP Tavern posted an article about how Matt Mullwenweg was addressing concerns over WordPress development moving too quickly. Matt more or less shrugged the question off in his State of the Word, but it is still a rising sentiment. And it’s not just a concern in the WordPress community, but in the larger web community as well.

There was a lengthy discussion that followed the post. It’s worth a read if you’re into that kind of thing, but to me, it highlights a growing divide that gets right down to the core of what’s expected of a WordPress user. 

Several users noted that even small changes can ripple out to larger ones or break expectations without even a remote need. Similarly, users don’t have the time or capacity to keep up with every little development and when things change they have to go through and check the changes against all of their sites and client sites, then update tutorials, then let their clients know. Every. single. time.

Others, including a handful of core committers, pointed out (rightfully so) that even small changes are heavily considered, and that they often solicit feedback about these things on places like WP Tavern and mailing lists.

The response was that these where places developers and coders hang out and WordPress users can’t be expected to check every little thing. But of course, if a site is code to WordPress conventions, it shouldn’t break anyway. And so maybe we all need to just trust WordPress a bit more.

And so on.

I’m (over)generalizing. But time and time again, we see mention of two groups. The first are the end users, the Average Joe with a laptop and a dream. The second are the developers, programmers on the bleeding edge of web applications. So really, the conversation comes down to what is the responsibility of the WordPress user? Is it the user’s job to ensure that their site is up to date, or it WordPress’ job to ensure that nothing ever breaks on existing sites? That’s a trick question, but it’s part of a continuing identity crisis in the WordPress community.

At this point, WordPress is trying to handle two pretty distinct use-cases. For the end users, a better admin experience, a fast install, and a quality controlled theme and plugin marketplace are of utmost importance. For the coder, extendability, speed of updates, and frankly, a trendy toolset are held in highest esteem. The article’s discussion focused on finding a balance and a place to draw the line between these two groups. The central theme being:

How can we maintain a strong pace of development with new features, while still leaving things simple (and relatively unchanged) and for the average user?

Wrong question. To pit two user types against one another implies some sort of mutual exclusion. It obfuscates the nature of the web and website development. And it puts the community at odds with one another.

Think about some of the things that WordPress does well out of the box. User authentication, media management, commenting, routing, and a pretty well thought out admin interface to boot. None of these components are good for just one group. In fact, a lot of the differences between these groups is just about how we want to render HTML on a page. But it’s the open web all the way down.

Let’s stop defining the “average” WordPress user. Let’s work on ways to elevate the WordPress user instead of insulting their intelligence at every turn. Let’s drop the assumption that these users don’t have the will or interest to learn more about how their site comes together. We don’t need to speak in techno-babble or build confusing interfaces. We can use the WordPress admin and site building process as teachable moments, to educate users on the types of things they can do. We can find better ways to reach out to everybody that uses WordPress and gather feedback. The WordPress core community is already working on this, and of course, they could always use some help.

We make it sound as if the REST API is only useful for NodeJS wielding front-end developers. What about the user that wants to use it to wire WordPress to Facebook, or connect to a third-party app, but doesn’t know how? WordPress just brought responsive image potential to 25% of the web. That’s a win for everybody. We have whole teams working on accessibility and localization. There’s no one group that benefits from any of the work that’s done.

As WordPress continues to grow, it will be its diversity of spirit and community that keep it alive. Take a look around at the next WordPress event that you’re at and note the multitude of voices and opinions. Remember that the role of the WordPress user is to make websites, and love doing it. We should encourage that.

JavaScript Links

The Magpie Developer

Jeff Atwood wrote this article seven years ago but it holds true:

These so-called thought leaders have left a virtual ghost town before anyone else had a chance to arrive.

I became a programmer because I love computers, and to love computers, you must love change. And I do. But I think the magpie developer sometimes loves change to the detriment of his own craft.

This seems as relevant as ever. As a developer in the Javascript world, it’s hard to keep up. Sometimes, I feel like I’ve done more “Hello World’s” then real projects. Small side projects help, but I’ve found the trick is to learn the basics of something, then log it in the back of your head (or write it down somewhere) for future use.

Side note, it’s disturbing how many links in this article are 404’ed these days. We need to all do something about that.

JavaScript WordPress

Leveling Up in JavaScript for WordPress Developers

Or How I Learned JavaScript.

When I started building websites, I used Notepad, and wrote pages in plain HTML and a little CSS. After a couple of years giving that a go, I moved to WordPress, and found out all about web standards. I’ve certainly written my fair share of PHP, but my primary skill set is the front-end. I was never trained in computer science, and programming has been a slowly acquired skills. Only in the last few years have I truly become serious about JavaScript development. In that time, I’ve picked up a few resources that I wish somebody had told me about when I first started out. Hopefully, a couple of these will help.

The JavaScript / jQuery debate

I’ll cop to it. I learned jQuery first. Some will say that’s wrong. In my opinion, it abstracts away annoying browser quirks and makes diving into code a lot easier. The trick is to avoid simply writing a mess of chained spaghetti right from the get go.

If you really want to understand how jQuery works, I’ll give you the secret sauce. Learn jQuery in 30 Days, from Jeffrey Way. In about 8 hours you’ll learn about how forgiving JavaScript really is, and why you need to fight against that to write maintainable code.

When you’re done with that, follow it up with a real deep dive. An oldie but goodie from Addy Osmani about building large-scale jQuery applications. A lot of the tools he mentions have been abandoned, or are very different these days, but the fundamental concepts are essential.

Structuring JavaScript

To me, the easiest way to start getting better with JavaScript was to learn how to structure code properly. For instance, let’s say you have a set of jQuery events and click handlers throughout your app. How can you organize events to keep things DRY?

One option is to use the module pattern, expertly explained by Chris Coyer over on CSS-Tricks. Modules start simple, a plain JavaScript object that stores your jQuery handlers and delegates events, like so.

var s, 
Module = { 
    el : {
        button1 : $('#button-1'),
        button2 : $('#button-2')
    init : function() {
        s = this.el;
    bindUIActions : function() {
        s.button1.on('click', Module.firstEvent);
        s.button2.on('click', Module.secondEvent);
    firstEvent : function(e) {
        console.log("Event 1 successful");
    secondEvent : function(e) {
        console.log("Event 2 successful");


Modules, and design patterns generally, help you understand how JavaScript really works. There’s almost nothing more important than wrapping your head around Objects and scope. One trick here is to declare the global variable s and then call it in init(), assigning it to this.el.

Why? Because this is incredibly tricky in JavaScript, and binding it to a global variable from the get-go makes it easier to access in your entire module.

If you’re looking for the next level up, try Rebecca Murphy’s description of using objects to organize JavaScript. Of course, there’s also an entire book by Addy Osmani about JavaScript design patterns if you’re interested.

Understanding JavaScript

Here’s one thing you’ll hear, oh, all the time. 

Everything in JavaScript is an object.

Of course, that’s not entirely true. But it’s also absolutely true. Yes, there are primitives like booleans and strings that aren’t technically Objects, but they are usually transformed into Objects as they’re interpolated. And everything else, functions, arrays, etc. are prototypical Objects free to be mutated and extended. Why is that important? I can tell you one reason.

JavaScript provides a technique that gets us the best of both worlds. We can specify properties that, from the outside, look like normal properties but secretly have methods associated with them.

That’s a quote from Marijn Haverbeke, who wrote a free online book called Eloquent JavaScript. It is, by far, the most in-depth discussion of the why behind JavaScript and how we as developers can use it to our advantage. At the end of the day, you can do just about anything with JavaScript. Eloquent JavaScript will help you understand why you shouldn’t.

Still not convinced? Pick up a copy of JavaScript: The Good Parts. Douglas Crockford is a prophet.

I’ve also heard great things about the You Don’t Know JS series, though I haven’t fully dived in yet.

Learning Frameworks, Learning Always

Ok, but you want to build an application with WordPress as the base, and JavaScript as the client. That’s where I’m at. And for the past year or so, I’ve been doing just that. I’m hoping to share a good amount of those learnings here from time to time, but here’s the thing I’ve learned about all these frameworks: They come and go. Many take fundamentally different ideological approaches, but the underlying foundation remains pretty similar. Learn a library, and you can use it. Bully for you. But, learn basic JavaScript MVC (MV*) principles and you can pick up just about any framework or library in a couple of days.

I know many of you are just looking for comparisons. Here’s a decent one.

But for those that want to understand the right use case for frameworks, WP Sessions has an excellent course on using Backbone and WordPress. The presenters really dive into why using a front-end framework / library like Backbone is important and discuss piratical ways to layer it into existing projects.

Another great introduction into the “why” of MVC is Developing Backbone Applications, again by Addy Osmani. Osmani doesn’t simply walk you through how to create an application in Backbone, he gets to the core of application frameworks, and how they can help you get the job done.

And then there’s React. Which, and I can’t state this enough, is just one of many tools available to you. It’s the new hotness, and I understand why it feels imperative to learn. If you’re a functional PHP programmer, it actually probably makes a lot of sense. What really brought React into view for me was an article called “ReactJS For Stupid People“. I recommend you read it. I can also recommend an excellent tutorial about React + WordPress over on Rastislav Lamo’s site. And of course, Calypso is being written in React.

But always remember, you don’t need a framework.

Just Give Me the Links



Craig Mod On Books

To return to a book is to return not just to the text but also to a past self. We are embedded in our libraries. To reread is to remember who we once were, which can be equal parts scary and intoxicating. Other services such as Timehop offer ways to return to past photos or past tweets. They, too, are unexpectedly evocative. Far more so than you might think. They allow us to measure and remeasure ourselves. And if a resurfaced tweet has an emotional resonance of x, than a passage in a book by which you were once moved must resonate at 100x.

Craig Mod, in Aeon

Development JavaScript

How to Make Text That Writes Itself in Javascript

One of my goals for the new year is to start actually blogging, to share the things that I’m learning, and to keep a better record for myself. To go along with that, I launched a new version of my site with the Fixed Theme from Array Themes. It’s incredibly well balanced, fast as hell, and a pleasure to use.

But I did want to carry over one thing from the last iteration of my site, and that is a sort of typewriter effect on the homepage which has a few messages from me to you. I actually saw this over at Music For Programming, and adapted the code for my own needs. But I thought I’d break down how it works. It’s written in vanilla JavaScript, in about 50 lines of code. The end effect is that text appears to type itself across the screen, delete the words, and then type some more.

Here’s what it looks like in action:

The effect itself is deceptively simple. JavaScript runs through each message, and one by one, pops the last letter off of the a message, and attaches it to the container. When we switch to “delete” mode, the opposite is done. In between running each of these, we add a random delay, then call the function again.

The first part is just about setting some variables. Nothing special here, just getting the value of the initial text with container.innerHTML, creating an array with the messages we want to type out, and setting an initial delay.

Next up, we create a simple updateText function. All this will do will take the value passed to it and update the container div with our new text:

function updateText(txt) {
    container.innerHTML = txt;

Now comes the cruft of our code, the “tick” function. The first part of the function checks to see if there is any text in our container div. If it is empty, then we have reached the end of the word. It increments our global variable timer (t), sets the message back to an empty string and switches to “write” mode.

    if(container.innerHTML.length == 0) {
        thing = things[t];
        message = '';
        mode = 'write';

Next up we use the JavaScript switch statement to move back and forth between two different modes. Switch simply takes a variable, in this case “mode” and runs code based on which case is set. The first mode is called write, which you’ll notice is what we set our mode to above, when the container is empty.

Our mode uses two crucial JavaScript string functions. The first is slice and the second is substr. Imagine our message is blank, we are starting to type a new line. First, the function uses slice to grab the first word off the beginning of our new message, and adds it to the message variable:

message += thing.slice(0, 1);

Next, it removes the first word off our message. That way, the next time this function is called it will grab the second letter, then third letter, and so on:

thing = thing.substr(1);

The write mode of this function does a few more things. For instance, if we have reached the end of our array, then we clear the window’s timeout function and return. We are done, and we want the last message to simply stay on screen. It also checks if there are any more letters in our message. If there are, it creates a delay that uses Math.rand to generate a random number. By using a random number, the effect has more of a typewriter feel. If you made the delay something static, it would look a lot more robotic. You can play around with the delay a bit to change the effect.

Our “delete” mode is even simpler then write. All we have to do is use slice to grab our message and pull the last word off of it. Then we run updateText() again to update our message, one by one.

  message = message.slice(0, -1);

And that’s about it. Our final step is just to kick off the function with an initial setTimeout. This will the delay we declared in our global variable (in this case 1 second), and start the function by deleting the initial message. Keep in mind, that I assigning window.setTimeout to a variable so that when the function is all done, I can use clearTimeout() to remove it altogether.

var timeout = window.setTimeout(tick, delay);

I’m sure there are lots of ways to do this, so I’m definitely open if someone has a different implementation. But I thought it was a cool trick that makes use of pretty common JavaScript string functions. Hopefully, you found it useful.


Ranier Maria Rilke

For one human being to love another: that is perhaps the most difficult of all our tasks… the work for which all other work is but preparation.”

Ranier Maria Rilke, A letter to a friend