Pony Foo

Ramblings of a degenerate coder

I'm Building Stompflow!

reading time: , published

Hey there! Today I have exciting news to share. We've recently started developing a prototype for a project management service called Stompflow, and it has a transparent process that allows everyone to get involved. Keep reading to learn more!

A couple of weeks ago I've started putting together Stompflow (although the name only came to life two days ago!), and it has a blog up. The blog is actually a fork of ponyfoo/ponyfoo, where the styles match the product we're building, but other than that the platform is basically the same as this one.

I'm really excited about this, and I'd appreciate it if you were able to contribute your thoughts and feedback.

Read the full article

Are Regular Expressions Stateful?

reading time: , published

I seem to have stumbled across a bug regarding regular expressions using the g modifier, where they seem to preserve internal state across calls to RegExp.prototype.test. I'm looking for confirmation or a "you're stupid, this is what is going on" dismissal.

Read the full article

Measure, Optimize, Automate

reading time: , published

We've already covered the different techniques you could use to vastly improve the performance of your front-end applications, their page load time, and the perceived performance (determined by the moment when the human can start interacting with your site). Although slightly off topic, we've also discussed how performance impacts UX. In this article, we'll focus on measuring performance, understanding those measurements, and automating the process.

Pretty much every web performance engineer out there starts by telling you to measure performance, and they typically suggest you measure it by tracking your relevant business metrics (such as sign-ups, purchases, or renewals), as a way to entice management and teach them that #perfmatters. Once you have an idea of the current state of your application, you can go over the performance report, fix the glaring issues, and measure again. The iterative approach allows you to keep your application on a tight leash, which helps you to quickly deploy improvements that make your site faster. Since you're measuring your performance, you can gauge exactly how beneficial your changes were.

Of course, all of this needs to be automated in order to be a feasible and sustained effort. In this article I'll explore our options when it comes to measuring, learning from those measurements, and automating them.

Since we're not really concerned with a specific build tool, I'll default to showing examples from the command-line, so that you can run them using npm run, and then provide links to well known plugins for the popular kids in the build block - Grunt, Gulp and Broccoli - as well as short explanations on how to use those plugins.

Gulp, Grunt, Whatever

Read the full article

My CampJS Experience

reading time: , published

I was never really the camping kind of guy. Sounds like the perfect opportunity to collect kindling, start a bonfire, set up a tent, sleep in a bedroll, not have Internet access, eat hot dogs day and night, feel cold and miserable and get bitten by all sorts of bugs, right? — overall not my mental picture for "having fun". Last weekend, though, I attended CampJS, and it changed my perspective on this kind of things.

I've always wanted to visit Australia. My sister has always been fascinated with the country, and she got to go a few years ago. She came back more fascinated about it than ever, validating my drive to visit one day. The problem was obviously one of distance, as visiting other countries usually goes. You're looking at upwards of half a day sitting on planes and airports to get from Argentina to an airport anywhere near Australia, but I guess I'm supposed not to complain about that (and I'm not, I like travelling and I don't mind planes).

It all started a couple of months ago. I was sitting in an airport on my way to Frontend Conference in Switzerland. My flight had just gotten cancelled, so I was stranded in Frankfurt for a couple hours. I couldn't really complain, Lufthansa had upgraded me to Business Class as a token of their appreciation that they'd be cancelling my next two flights with them. I checked my email, and I had one from Tim. I didn't really know Tim, I followed him on Twitter and GitHub but that was about it, I almost hadn't interacted with him at all. This came as a nice surprise!


Hi, I run CampJS, it's a casual developer conference in Australia. Would you be interested in coming out to our next event from October 31 – November 3?

I had already stumbled upon the site for their conference, it's quite nice — especially on a cold night. It renders a small world using WebGL and turns your notebook into a little furnace.


Anyways, I didn't hesitate to say yes: this was a great opportunity to visit Australia for a little while, get to know Tim in the flesh (and as I'd find out later on, a wealth of other great humans), and attend a conference to boot!

Read the full article

Stop Breaking the Web

reading time: , published

The year is 2014, a ninja rockstar band goes up against the now long-forgotten progressive enhancement technique, forsaking the origins of the web and everything they once stood for. This article is where I rant about how we are breaking the web, the not-immediately-obvious reasons why we should stop doing this, and how not breaking the web would be a great thing.

TL;DR We are crushing the web. Dedicated client-side rendering sucks. Polyfills are used for all the wrong reasons. Those hideous-looking hash routers are bad and we should feel bad. We have been telling each other for years that progressive enhancement is great, and yet we're doing very little about it!

Here's hoping the screenshot below corresponds merely to a publicity stunt, attempting to grab the tech media world by surprise. That being said, the fact that we're not certain about whether this is a ruse or a permanent decision makes me cringe for the future of the web.


Taco Bell #onlyintheapp — is it a clever publicity stunt to drive app downloads or a symptom of the profusely bleeding web?

Disclaimer: This article is not a rant about Angular 2.0. I started forming these thoughts a while ago, before the Angular 2.0 revelations. The roadmap for Angular merely happened to coincide with the posting of this article. If anything, those news reinforce the points others have made against it, but the statement behind this article goes far beyond the myriad of breaking changes in Angular's public API.

Read the full article

Adjusting UX for human visitors

reading time: , published

In this article I'll analyze the past and present of UX in Pony Foo. In doing so, we'll go over the features that were introduced to improve the lives of human beings visiting the site, as well as the features that changed (or were removed entirely) in order to simplify UX. Of course, the single most important UX improvement that came out of the redesign was the huge performance boost.

As all of us probably already know, Speed Matters. Many experiments conducted to analyze human behavior when visiting sites all arrived at similar conclusions. They've determined that slower sites translate directly into loss of interest, less conversions, and may in fact drive your customers straight to the competition!

The performance improvements have been covered elsewhere, though. In this article we'll focus on the "traditional" aspects of UX. We'll be focusing on the changes that were made to the platform as a direct result of user feedback, common sense, and the experience that I've garnered over time.

Namely, we'll use the list presented below as an index of the UX improvements under discussion in the article.

  • Landing page experience
  • Progressive enhancement
  • Commenting experience
  • Subscription model
  • Styles and fonts
  • Links, page titles, and routing
  • Search experience and related articles

Let's step through these points one by one and see if we can draw conclusions that are helpful beyond the scope of a simple blogging platform.

Read the full article