Unless you’ve been living under a rock, you’ve used one of Julian Shapiro’s projects by now.
From Velocity.js -the fast animation engine that makes motion design manageable for developers and designers -to the Libscore open analytics project, he’s helped shape the web development world over the last few years.
How did you get into web development?
I was born in Montreal, Canada. At 12, I moved to a city a few hours outside of Vancouver. There wasn’t as much to do in the new city (at least, so my narrow-minded 12-year-old self thought)! So, I spent a lot of time on the computer, which led to tampering with the computer as much as possible to see if I could make it do new things.
It turned out that you had to learn how to code to make it do anything interesting. I started developing role-playing games in Visual Basic 6, which was the “hardest” language I could wrap my tiny brain around at the time.
I soon went from teenage creative to teenage entrepreneur once I realized I could also make money with the computer. As with other tech-savvy teens of my generation, I began consulting, creating websites for local businesses, including the Duke of Edinburgh’s Award’s local chapter. I thought that was pretty cool. The truly cool part, though, was how much I was being paid. At 14. I learned that I had skills that were in demand; I felt valued. I felt like a specialist. That motivated me to be the best I could be and to reach for the biggest impact I could with what I was doing.
Before you created Velocity, you were a full-time founder. Tell me about that.
I still am very much a tech entrepreneur, but now I focus more on having a positive impact on the industry than I do on being a “businessman.” Being a businessman primarily optimizes pursuits for yourself, but -once you have enough base financial comfort- the most important thing is optimizing for your long-term happiness. Having an impact on those around you is the best way of doing that.
The most interesting thing to come out of my entrepreneurship days (prior to Velocity) was NameLayer. Its founding story is what makes it so interesting: I’ve always been fascinated by domain names. I’ve always loved the idea of “owning” your very own piece of the Internet. Julian.com, for example, is 100% mine. It’s a unique piece of the web carved out just for me. And, because it’s short and memorable, it’s doubly exciting: It’s easy to remember and it’s easy to share with others.
These types of realizations developed into an interest in the intersection of company naming and domain names. I knew that a lot of companies had difficulty choosing a good name that had a matching domain available for purchase, didn’t sound silly, sounded unique, and nicely reflected their product. The proof is out there: A lot of company names are less-than-good.
I set out to build two sets of tools (using my good but not great web development knowledge at the time): The first set would analyze the roughly 50,000 domain names that expire on a daily basis, and determine which were the most worthwhile to acquire based on their suitability for a premium company names. The second set would do the job of actually acquiring those domains that were deemed worthwhile. This latter process was much like bidding on eBay auctions in the sense that people “snipe” a domain (or an item at auction) at the right moment, just after the domain expires but before other people get a chance to register it.
Both sets of tools took a lot of work. The former -the analyzing portion- entailed manually going through the entirety of the English-language dictionary to build algorithms that could help pinpoint word combinations and word formations that “sounded good.” The latter -the sniping aspect of the toolset- involved piggybacking off of the third-party domain registration power given to developer-users of registrars. I would group together the registration power of multiple registrars to direct as much registration bandwidth as possible to the desired expiring domain at the exact right time.
All of this amounted to a neat system that would alert me when I woke up every morning: The system would tell me which 100 domains of the roughly 50,000 were the most worthwhile to focus the registration power on. I would then manually approve the best 15 domains, which would go into a queue for sniping later in the day.
I would usually wind up getting about 45% of the domains I sniped.
After 6 months, I had amassed millions of dollars worth of domains (from a retail perspective). I was acquiring them for only $9 a pop, but was selling them for a few thousand dollars each. Soon enough, I built out an inventory with all these domains (NameLayer), which began selling names to startups and large tech corporations. Because of the volume we were pushing, we naturally had a significant impact on naming trends in the startup and tech world.
NameLayer later sold to Techstars, the famous startup accelerator. How did that exit affect what you spend your time on next?
After NameLayer, I gave myself time to pursue whatever I was most interested in whimsically toying around with. It was clear that I most wanted to get back to that early state of tinkering with computers for the sheer sake of it.
As I began developing web projects, it occurred to me that web animation remained painfully slow, and this lack of performance was preventing professional developers and designers from building motion design into their sites in the same way they were doing it on mobile apps.
I did a tremendous amount of full-time research over the course of the next several months tweaking and optimizing my code to find the perfect set of values to create the fastest Web animation engine I could. I loved the challenge.
When that was done, I wanted to solve one more problem before I released the animation engine (which became known as Velocity): I wanted to make the web animation workflow processes much better too. The reality was that so many aspects of web development tooling had improved over the last few years, but not web animation. Tools badly needed to exist that would allow professional front-end dev teams to design, manage, and improve the animation of their UI’s. Because these tools didn’t exist, designers were getting fairly lazy and were avoiding complex motion design sequences and intricate transitional animations between UI views, and so forth.
As Velocity’s success has demonstrated, animation is too important to be cast aside. We've come a long way since the old days of spammy banner ads and animated paperclips mascots. Animation is now routinely used to greatly improve the utility, intuitiveness, and elegance of our favorite websites and apps. Sites without subtle interface animation cues now feel antiquated. This distinction is important because products with higher levels of detail feel superior to users today. Users are becoming increasingly discerning. You want them to have the impression of, “Wow, this is cool” instead of “Yeah, this is like that other app.”
You could argue that, from a features perspective, Facebook was worse than Myspace when it came out. The difference was in the implementation details: Facebook was clean, it was organized, it was calculated, and it was ultimately more effective. These things matter, and programmers and designers alike have realized the huge role animation plays in great web experiences today.
What did the trajectory of Velocity’s success looked like?
I like to think that the degree of thought and love I put into Velocity is why it was successful from day one. All I did upfront was tell a few people about it and write a few blog posts explaining its value, and then it just took off like wildfire. Within weeks, Tumblr was using it. Within a couple months, WhatsApp was using it. Within a few more months, so was Microsoft (on Windows.com), Samsung, Uber, and thousands and thousands of other companies.
As I talk to companies, it’s evident that Velocity’s broad adoption has led to a notable expansion of the tech market’s demand for talented front-end designers that understand animation’s utility on the Web.
The adoption of the fruits of my labor is really gratifying, partly because it has justified my pursuit of improving web development without ambitions of productization.
We haven’t even touched upon Libscore yet!
I wrote extensively about the project here on Medium. I’ll kindly defer readers to that post. The short it it this: Most developers contribute to open source in a vacuum; they develop, hoping —but never knowing— whether their library is being used at-large. Libscore’s data substantiates this hope with facts, resulting in a tighter feedback loop between a project’s development and its user adoption. This feedback loop, in turn, works to motivate a much higher frequency of open source project maintenance, which ultimately leads to greater life spans for open source projects and thereby potentially much greater long-term impact on the web development world.
WhatsApp and Tumblr are using Velocity and they reach a minimum of 1.3 billion combined individuals every month.
I built Libscore because I only had a sliver of a view into who all was actually using Velocity. Once Libscore was ready, and I ran a search for Velocity. Seeing how Velocity was being used to power the web experience for more than a billion people around the world was tremendous. Two Velocity users alone, WhatsApp and Tumblr, reach a minimum of 1.3 billion combined individuals every month. (That’s not pageviews, those are actual individual persons!) This further motivated me to continue working full-time on the project to expand its impact further and to continue empowering the developers using it.
What does the future of web development look like?
I can only speak to what my ideal future of web development looks like, and how I plan to play a small part to get us there. It comes down to this: Developers like being specialized. They like being people who “know it all.” This comes with the territory because there really is a lot to learn, and the field changes constantly. The downside to this attitude, however, is that developers don’t do a good enough job routinely making things easier on themselves or for people newly coming into the development world. In some ways, they think to themselves, “Because it was tough for us, it’s only right that it remains tough for others.”
This thinking sheds light on why projects like Velocity didn’t exist until recently. Or why it took Facebook’s tremendous React project so long to exist (after all, the technology has been here this whole time!). We developers get stuck in our ways, and we narrowly focus on the end goal: getting the business’ product out the door. But sometimes we need to rethink the way we’re getting the product out the door to begin with.
A reality of developer tooling, however, is that it doesn’t really pay. No one paid me to build Velocity. Few people in open source are paid at all. In fact, it took a massive company like Facebook to be the ones to build something as game-changing as React.
Point being, I don’t blame developers very much for going along with the status quo; we have to perform our day jobs and open source takes a tremendous amount of effort. And development is only step one! After you make a project, there’s also marketing it so that people actually use it so it has a shot of having an impact.
The good news is that we developers are becoming increasingly aware of this reality, and the industry is starting to devote much more resources to making web development faster, more manageable, and -ultimately- more enjoyable. That’s the most important thing that has to happen in the near future, and that’s what I want to continue playing a role in.