Search

Pony Foo

Ramblings of a degenerate coder

Baking Modularity into Tag Editing

reading time: , published

For quite some time I've been wanting some sort of input that dealt with user-submitted tags in a reasonable way. I wanted this input to still be half-decent when JavaScript was out of the picture, so this meant starting with the basic building blocks of HTML.

Turns out, all libraries out there (google for "tag input javascript" if you're curious) that do this have at least one of these flaws.

  • Feature bloat
  • Human unfriendly
  • Addiction to dependencies

Instead of creating separate components for, say, tag input and autocompletion, most of these libraries try to do it all, and fail miserably at doing any one thing well. This is the defining characteristic of modular development, where we define a (narrow) purpose for what we're building and we set out to build the best possible solution to meet that purpose.

Multi-purpose libraries end up doing a lot of things I do not need or want, while single-purpose components typically do exactly what you need.

Being user friendly is why we build these libraries, and yet I couldn't find a single library that I would've used over a simple <input type='text' /> and telling my humans to enter tags separated by a single space. The vast majority of these presented inconveniences such as being unable to walk around the input like we do in an input tag, insert tags in any position, or not even allowing humans to edit tags once they receive the "this is a tag" treatment.

Human-facing interface elements must be sensitive to the needs of the human. Sometimes we have to wonder if a component is even worth the trouble. Wouldn't a simple <input> be more amicable than an inflexible "tag input" solution? Is the component more useful to your humans?

Finally, most of these libraries tie themselves to a dependency. If I really liked one of them, I probably would've needed to commit to jQuery myself. Or Angular. Or React. It doesn't matter what their "big dependency" is, the point is that it constraints the consumer from being able to easily port the component to different projects with other assortments of frameworks or libraries.

The fact that most of them count jQuery among their dependencies leaves much to be desired.

This article will explore the approach I took to build Insignia in just one day, as I think you may apply some of these concepts to any development you do on a daily basis.

Read the full article

Cross-tab Communication

reading time: , published

The upcoming SharedWorker API allows to transmit data across iframes and even browser tabs or windows. It landed in Chrome years ago, and not so long ago in Firefox, but it's nowhere to be seen in IE or Safari. A wildly supported alternative exists that can be used today, but it's largely unknown. Let's explore it!

I wanted an elegant solution to the following scenario: suppose a human walks into your website, logs in, opens a second tab, and logs out in that tab. He's still "logged in" on the first tab, except anything he touches will either redirect them to the login page or straight blow up in their face. A more inviting alternative would be to figure out that they're logged out and do something about it, such as display a dialog asking them to re-authenticate, or maybe the login view itself.

You could use the WebSocket API for this, but that'd be overkill. I wanted a lower-level technology flyswatter, so I started looking for cross-tab communication options. The first option that popped up was using cookies or localStorage, and then periodically checking whether they were logged in or not via setInterval. I wasn't satisfied with that answer because it would waste too many CPU cycles checking for something that might not ever come up. At that point I would've rather used a "comet" (also known as long-polling), Server-Sent Events, or WebSockets.

I was surprised to see that the answer was lying in front of my nose, it was localStorage all along!

Read the full article

Second Year in Review

reading time: , published

I started this blog two years ago, at a time when nobody seemed to care about blogging anymore. It turned out to be one of the best decisions I took back then, and it has helped me develop an online presence that's now the cornerstone of my business. Roughly a year ago I posted "A Year In Review" as I looked back on my first year of sustained blogging. Today I want to expand on that review, compare this year to the last one, and see how I did!

JavaScript Application Design

It's kind of funny how natural blogging feels. I guess that passion is what drove me to write JavaScript Application Design, which is due to come out in January. (fingers crossed!) I initially conceived it as a "Getting Started" guide for Node.js containing best practices and tips, but eventually steered towards a more "JavaScript all the things" kind of book, where I wouldn't take Node.js for granted and instead focus on quality, regardless of the platform.

It's also humbling how I figured it'd come out way earlier than it did: I thought September was a reasonable release date, but it turns out writing a well-polished book takes a lot of effort and a heap of patience. That being said, I'm happy the book got to a place where I'm not scared of publishing it. Publishing is a scary thing. Once your words become ink in bookshelves, there's no turning back. The idea of getting nasty reviews certainly haunts me from time to time, but I guess it's just something I'll have to learn to live with. Hopefully I get the nice kind of reviews, though.

Read the full article

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
Pony
Foo
Pony
Foo
Pony
Foo