Allen Pike 2015-03-03T13:29:59-08:00 Allen Pike A JS framework on every table 2015-02-28T18:00:00-08:00 Allen Pike <p>Most programming languages support a small number of popular, stable application frameworks. Objective-C and Swift apps use Apple’s excellent Cocoa framework. Ruby apps more often than not use Rails. Java has a handful of established web app frameworks, and they come and go relatively slowly.</p> <p>In the meantime, the latest and greatest JavaScript framework comes around every sixteen minutes.</p> <p>Studies show that a todo list is the most complex JavaScript app you can build before a newer, better framework is invented. Luckily, there’s an excellent site called <a href="">TodoMVC</a> dedicated to comparing JavaScript frameworks by way of todo sample projects. There, you can see how 63 JavaScript app frameworks’ todo examples compare to just jQuery or vanilla JavaScript. If you think 63 frameworks are a lot, you ain’t seen nothing yet: the TodoMVC team <a href="">gets multiple pull requests weekly</a> from people flogging new JavaScript frameworks. </p> <p>For example, <a href="">the most recent TodoMVC pull request</a>, as of this writing, wants to add Riot.js 2.0. What is Riot.js 2.0, you ask? Apparently, it’s the second version of something called Riot.js, an app framework that’s like React.js, but better in some ways that are definitely important. “But wait,” you may ask, “didn’t React like just come out and isn’t even 1.0 yet? How can a thing based on it be 2.0 already?!” The answer, my friend, is JavaScript.</p> <p><img style='max-width: 100%' src="/images/2015/javascript-guy.jpg" /></p> <p>Why is the JavaScript framework environment so unstable? What is driving this insanity? Why are Ruby developers using Rails 4.2 but client-side developers are hyping boron.js 0.2.1?</p> <p>The problem is, as always, the browser. The modern web browser is an incredible feat of engineering, especially considering its humble roots as a way to display simple documents. There is definitely a substantial amount of framework turnover in the node/io.js community, but it’s nothing compared to the zoo that is the browser app framework world. The wild instability of the client-side JavaScript landscape is a product of the browser: both its historical limitations and its incredible rate of improvement.</p> <p>The browser is the most ubiquitous app runtime in history by a wide margin, and to write applications for it you need to write JavaScript. As a consequence, JavaScript is the least elective programming language in the world – most people who are writing client-side JavaScript applications are not doing so because they chose JavaScript, but because they chose client-side web development. These people come from a wide variety of backgrounds, and have a wide variety of goals. This constant inflow of new ideas and interests has made the JavaScript community unusually diverse.</p> <p>Meanwhile, the browser itself changes far more rapidly and unpredictably than the underlying languages on which other frameworks are built. The browser has changed more since Backbone.js debuted in 2010 than Objective-C has changed since Cocoa debuted all the way back in 1988. Browser improvements that inspire new generations of frameworks happen constantly.</p> <p>These inputs fuel an incredible amount of experimentation, excitement, and adaptation. Every day new frameworks, new approaches, and new tools <a href="">erupt from the geyser we call Github</a>. Every year there are more instant-classic JSConf talks about <a href="">crazy new ideas</a>, <a href="">impressive new browser features</a>, and <a href="">rethinking best practices</a>. This beautiful chaos is exciting in a way that I’ve never seen in another developer community.</p> <p><a href="" title="Photo: Adrián Pérez"><img style='max-width: 100%' src="/images/2015/jsconf-eu-banner.jpg" alt="Photo: Adrián Pérez" /></a></p> <p>Unfortunately, while the community is busy driving new features and new frameworks, the browser is is busy killing them.</p> <p>Unlike the frameworks we use in C++ or Swift, the entirety of your app framework must be downloaded, parsed, and turned into machine code before users even see your app. Caching and offline access continue to improve, but the very real constraints on bandwidth, latency, memory, and loading time are a huge challenge for the kind of huge app frameworks that we take for granted in native app development.</p> <p>This is especially true on mobile, where the already problematic constraints of memory, CPU, and network bandwidth can be crippling. While JavaScript is now a remarkably fast language, the ubiquity of the web means that your code and framework can be downloaded and run in some incredibly hostile environments. Frameworks that can take advantage of Chrome Canary’s supernatural powers on a Mac Pro aren’t going to enjoy themselves on “Browser” on an old Acer EvoAMAZE Plus 3G E.</p> <p>The churning seas on which client-side frameworks sail are especially treacherous for large, ambitious frameworks that try to create a rich environment and UI library for building apps the way we do natively.</p> <p>When SproutCore and Cappuccino appeared in 2007, I was totally sold by <a href="">the amazing demos</a>. I’d thought Moore’s law had finally delivered stable, featureful JavaScript frameworks for building beautiful desktop-like apps in the browser. Then I spent two years <a href="">shipping stuff</a> with SproutCore, dealing with megabytes’ worth of somebody else’s JavaScript, wrestling with weird technical choices necessitated by horrible DOM performance on IE7, and somehow cramming the whole thing into the iPad’s 256MB of RAM. Meanwhile, the documentation never caught up to the pace of breaking changes, and performance was a constant battle. Before long, the dream felt more like an evolutionary dead end.</p> <p><a href="" title="&quot;Sharovipteryx BW&quot; by Nobu Tamura ( Yes, this was a thing."><img style='max-width: 100%' src="/images/2015/flying-dino.jpg" alt="&quot;Sharovipteryx BW&quot; by Nobu Tamura ( Yes, this was a thing." /></a></p> <p>While in many ways I still dream of a framework that could deliver on the promises that SproutCore and Cappuccino made, I now have much more respect for how hard such a thing is to build, especially in JavaScript. The same flexible, untyped nature that makes JavaScript fun to write a microframework in makes it kind of unpleasant to learn or maintain a large framework in. While the strong typing of native app frameworks can feel like a drag on tiny projects, it makes their often-massive APIs easy to explore and use effectively: just tab-complete your way to victory.</p> <p>A deprecated API in the Cocoa framework just means that a warning comes up when I open my project, and sometimes I can even right-click to replace the old way of doing things with the new way. Meanwhile in JavaScript, poking around in the Webkit REPL to find APIs you might make use of is a good way to find unsupported accidentally public APIs that will blow up your app at runtime after some point update of your framework.</p> <p>All these forces – the rapid changes, the diverse needs, the hostile environment, and the loose language features – make large, feature-rich JavaScript frameworks slow, lumbering prey. A horde of young, nimble <a href="">microframeworks</a> swarm them, take them down, and fight over the meal. Modularity and componentization reigns.</p> <p><a href=""><img style='max-width: 100%' src="/images/2015/tar-pit.jpg" alt="Evolution's a bitch." /></a></p> <p>A world dominated by endless tiny frameworks actually works okay for JavaScript experts and consultants. We become skilled at mixing and matching components, are able to spend time keeping up to date on the latest options and their relative strengths, and gain a lot of fodder for our conference talks. Yet for those who are new to JavaScript or who aren’t full-time client-side developers, any given tiny framework can’t possibly solve the wide range of problems that JavaScript developers struggle with. Product companies building large, long-lived client-side apps need to settle on some framework, and live with the consequences for years as they discover its limitations.</p> <p>The well-regarded <a href="">Mithril.js framework is only 5kb</a>. That’s great for load and parse time, but it necessarily can’t solve a rich array of problems. Rails, by contrast, has more than 100x as much code. <em>Just ActiveRecord is 1274kb!</em> In the browser, you can’t sanely use a 1.2MB framework, and so the proliferation continues.</p> <p>Neck deep in frameworks, <a href="">choosing one we’re actually happy with</a> becomes virtually impossible. The Paradox of Choice means that knowing you’re probably not using the right framework causes endless cognitive dissonance. Ironically, this dissatisfaction drives even more people to create their own frameworks.</p> <p><a href="" title="Cube Drone by Curtis Lassam."><img style='max-width: 100%' src="/images/2015/cube-drone-angular.jpg" alt="Cube Drone by Curtis Lassam." /></a></p> <p><a href="">Framework</a> <a href="">fatigue</a> has driven down the number of frameworks that JavaScript developers actually try. Who is going to actually build a non-trivial application with Dojo, YUI, ExtJS, jQuery UI, Backbone, Ember, Cappuccino, SproutCore, GWT – oh man remember GWT? – Angular, Sencha, jQuery Mobile, Knockout, Meteor, Ampersand, Flight, Mithril, Polymer, React and Flux? Seriously?</p> <p>Nobody can try all the popular options, but everybody wishes for consolidation and more wood behind fewer frameworks. As such, a lot of developers have fallen into a pattern: avoid learning a new framework until it seems like one is finally ascending to the throne as the widely popular, exceptionally capable, “won’t get you fired” choice for building JavaScript frameworks. While Google Trends is no double-blind study, it seems clear that interest in Angular has far surpassed that of any historical web app framework. After a decade of chaos, it finally looks like one we’ve found the chosen one!</p> <p><img style='max-width: 100%' src="/images/2015/rise-of-angular.jpg" alt="Composition of Google Trends searches of &quot;%s tutorial&quot; for 9 frameworks." /></p> <p>Yes, Angular,js, the framework that I initially described in 2009 as “unreasonably weird” seems to have achieved a level of popularity that no JS app framework ever has. Between serious support from Google, an easy ramp-up path, and a rich community, Angular looks poised to finally settle the…</p> <p>Wait, what’s that? The Angular team has decided that <a href="">Angular 2 will not be compatible with Angular 1.x</a>, and there will be no easy upgrade path?</p> <blockquote> <p>Developers familiar with the Angular 1.X will encounter a drastically different looking framework and will need to learn a new architecture.</p> </blockquote> <p>Oof.</p> <h2 id="is-this-forever">Is this forever?</h2> <p>Perhaps we should just resign ourselves to it always being this way. While I’ve long argued that creating your own JavaScript framework out of a microframework and a DOM library is madness, maybe it’s the least bad option. Maybe the quirks of the language and the constraints of the browser make a sophisticated but bulletproof framework like Cocoa or Rails just kind of impossible.</p> <p>Maybe I should just call off the hunt. Though, people do seem pretty excited about React.js. They have some smart developers and exciting ideas, at least from what I’ve seen.</p> <p>You know, maybe I should build something new with it and see what it’s like. Maybe… maybe it’s the one.</p> <hr /> <p><em>Special thanks to Henrik Joreteg, Angelina Fabbro, and Nigel Brooke for their feedback on the ideas behind this piece.</em></p> When used properly 2015-01-21T09:00:00-08:00 Allen Pike <p>It is well known in the tech world that <a href="">to be successful, you need a fussy way to make coffee</a>. A couple years ago, after seeing some great recommendations, I thought I might finally try the legendary <a href="">AeroPress</a>. Next time I was down at our local <a href="">fancy coffee shop</a>, waiting for a fancy coffee, I took a look on their fancy shelves, and found the box. It was not what I expected. </p> <p><img style='max-width: 100%' src="/images/2015/aeropress-box.jpg" width="300s" /></p> <p>An AeroPress box is hexagonal, cheap, and ugly. Enough people had recommended it that I’d expected AeroPress may be <em>the best coffee maker</em>. Holding a flimsy box that declared <em>“The best coffee maker”</em> in 200pt bold italic Frankfurter, I was less sure. </p> <p>The box seemed to anticipate I might be doubtful, and as such it sought to reassure me. Flanking the unappealing product photo, it was covered nine long customer testimonials from notable coffee luminaries such as “Margie Gray, Milburn, NJ” and “David Maier, Brush Prairie, WA.” One glowing testimonial starts like this:</p> <blockquote> <p><strong>When used properly, AeroPress produces a remarkably good espresso-<wbr />style coffee</strong></p> </blockquote> <p><em>When used properly?</em> I felt awkward, as one does in the pharmacy when they’re trying to read a package they don’t want to be seen reading. I put the box back down gingerly, collected my fussy coffee, and fled.</p> <p>In the months that followed I kept hearing <a href="">recommendations</a> for this thing, so I eventually asked for one for my birthday. Karen got me one, but she had to ask: “Is that the one you wanted? It seemed like it, but the box looked…” Yeah, I know. It looked like infomercial junk.</p> <p>Since then, I’ve fallen in love with AeroPress. I use one at home and one at work, and make AeroPress coffee almost every day. It’s clean, it’s simple, it’s durable, and it makes good coffee. I’ve since learned its quirky origins as <a href="">a whiz-bang invention by an inventor of whiz-bang things</a>, which explains the “As Seen On TV” style packaging. I now concur that it is indeed <em>the best coffee maker</em>. Still, while the box’s quote was true in the end, its Five Guys testimonials-in-random-fonts approach made it hard to believe.</p> <p><img style='max-width: 100%' src="/images/2015/five-guys.jpg" width="100%" /></p> <p>In recent years, coffee aficionados, a group that rarely agrees on anything, seem mostly in agreement: AeroPress is the easiest, cheapest way to get started making good coffee. At only $27, it should be a strong seller in every department and housewares store in the country. Instead, it’s mostly sold online.</p> <p>Side by side on a shelf with a more familiar coffee machine or french press, our beloved plunger is going to lose out. It’s unattractively packaged, strange, and its price seems too good to be true. I suspect the testimonials are intended to make it seem less weird, but beside the clean lines of a Bodum’s box they do the opposite. Shoppers looking for a gift are so turned off by AeroPress’ package that there is a market for <a href="">aftermarket gift boxes</a>. A sad state for a great product.</p> <p>One might argue that crafting an attractive design to promote a plastic plunger tube is an insurmountable task. Look no further than the <a href="">AeroPress World Championship</a> for proof that it can be done well. In recent years, the competition has inspired an array of excellent AeroPress-themed graphic designs.</p> <p><img style='max-width: 100%' src="/images/2015/aeropress-posters.jpg" /></p> <p>All of these posters are an order of magnitude nicer than the AeroPress box. After my own heart is the one that depicts the destruction of an AeroPress box.</p> <p><strong>So, my unsolicited business advice to the AeroPress team at Aerobie is this.</strong> Get in touch with one of the talented folks who design the AeroPress Championship posters, and offer them what may be their dream job: design AeroPress some high quality packaging. Commission something that’s worthy of <em>the best coffee maker</em>, and conveys it instead of just claiming it. Sell your great product in something that feels like it will contain something great, and give your customers a complete experience. Then, raise the price by $10 and you’ll sell more AeroPresses than you ever dreamed.</p> <p>Oh, and let me know if you need a testimonial.</p> Maximal Products at Çingleton 2015-01-06T16:00:00-08:00 Allen Pike <p>In October I had the privilege of speaking at the final Çingleton conference. I’ve now given this talk, titled “Maximum Viable Products,” in six cities in three countries, but the Çingleton version was my favourite.</p> <div class="videoWrapper"> <iframe src="//" width="500" height="281" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe> </div> <p>You should also watch <a href="">Laura Savino’s talk on language and self improvement</a>. Then, go ahead and watch <a href="">every other Çingleton talk ever</a>. The mix of small audience, round tables, and wonderful speakers that Guy, Luc, and Scott pulled off is truly a recipe for a great event. The format really shines, though, for more personal topics like surviving being indie, telling meaningful stories, and <a href="">leading by example</a>.</p> <p>In the afterglow of the last day, after the announcement that they wouldn’t hold another, I was overwhelmed with the desire to pick up where Ç left off. As it happens, Vancouver has <a href="">its own geodesic dome</a> - what better place for Çingleton to live on? Since then, however, I’ve felt more and more that trying to reproduce somebody else’s show is a fool’s errand. If you start something thinking of it as a sequel, it’s never going to be truly special.</p> <p><a href=""><img style='max-width: 100%' src="/images/2015/cingleton-pano.jpg" /></a></p> <p>We have no specific plans for an event in Vancouver at the moment, but I can say that if we do ever do something, it’ll need to be unique. The Çingleton team realized the value of doing something special when they started in 2010, which is why they decided to host a one year conference. Sure, they later changed their minds and did it three more times, but the spirit of doing something unique ran through it all.</p> <p>Although Ç is behind us, there are many more great events ahead. We have <a href="">Úll</a>, <a href="">CocoaLove</a>, and now <a href="">Release Notes</a> in the indie app world specifically, and many more in the web and game dev worlds. I’ll be at as many of them as I can manage, hearing others’ stories and, when I can, sharing my own.</p>