Introducing Juniper: The Annotated Web App

Web apps don’t have to suck. Here’s proof. And here’s the annotated source.

Q Branch’s Vesper is a beautiful, simple, functional note-taking app, with design and attention to detail like I want every app to have. So, obviously, I decided to port it to SproutCore.

Two reasons. First, I wanted to combat the widespread notion that web apps are fundamentally crappy. There are loads of terrible ones, but they’re not bad because JavaScript is (undeniably) slow: most apps don’t need the full computational power of a C-level language. With the right toolkit, web apps can hold their own against most native apps, even and especially those like Vesper whose power is in beautiful design and sterling execution. Bad web apps are bad because they were built badly, with the wrong toolkits. SproutCore is the right toolkit.

Similarly, I wanted to show how great an experience developing with SproutCore can be. The learning curve is definitely steep – it’s a completely different way to write code than that jQuery plugin you put on GitHub. But that jQuery plugin you put on GitHub isn’t a native-caliber application, so that’s a good thing, and once you’re up the curve, SproutCore is tremendously enabling: I built this from sc-init to a fully armed and operational note-taking app in fewer than a hundred hours.

It’s not feature-complete – no image attachments, no dedicated large-screen interface, and of course no back end or sync. But the transitions are smooth and the data persists. It feels like a world-class app and it works like a world-class app, but it’s in your browser.

Second reason. There’s a complete lack of any really complete, open SproutCore codebases. Developers learn best reading code next to running code, to poke at one and dig into the other, but until now there hasn’t been any place to do that.

With this project, I’ve opened the source and written a companion guide, available in the GitHub repo’s README. If you’re learning, or thinking you might want to learn, then fire up the app and dive into the guide. It’s not a flawless codebase – see the above note about a hundred hours – but it embodies a lot of the best practices I’ve picked up over the years. I’ll also highlight some specific features in upcoming posts.

So check out Juniper here; the heavily-annotated source is here. Poke around, and if you want to see how it’s done, now you can dig deeper. If you have any questions or run into any issues, well, there you go.

If you like Juniper and want to try the real thing, just mix in some vodka and Lillet Blanc, head over to the App Store, and try Vesper. Tell ’em the web sent you.

You May Find Useful…

In the process of overbuilding my behemoth business card widget, I put together or otherwise acquired a few well-generalized microlibraries that are now up on GitHub. You may find them useful!

didYouMean.js

If you fat-finger git stats or git comimt, it declines to execute, as you’d expect, but it also kindly suggests some commands that it thinks you might have meant. I wanted a similar effect for my project’s client-side 404 page, so I hit Google. Google led me to Wikipedia, and I settled on Levenshtein Distance, which came with an example implementation in C. I translated it into JavaScript; then I did what I do with cores of impenetrable code that I never want to think about again: I wrapped it in a friendly API.

didYouMean.js is the product, and it makes it incredibly easy to compare a string to a list of strings. There are a bunch of hot-swappable options – a couple flavors of threshold, and a “good enough quit early” flag – and it will happily attach itself to window or to module.exports as available.

MVCObject.js

Whenever I venture out from within SproutCore’s thick, KVO-happy walls, the first thing I do is figure out how to keep disparate layers (ergo objects) in sync and active without having to know about each other. I was part of a VB.NET shop in a previous life, where it was custom class events; in node, everything is an EventEmitter; and of course it’s bindings in Cocoa, where SproutCore got the idea from in the first place.

For my project, I decided to go raw, no frameworks, no nothin’, but it turns out I can’t live without this one piece. Google this time directed me to Google, whose Maps API includes something called MVCObject, and to this project, a standalone implementation. Credit goes to two silent email addresses named “John” and “Mark”, @ an apparently dead website; they’ve apparently abandoned the project, so I’ve moved it to GitHub, added some examples to the README, and softened its habit of throwing cranky errors in otherwise-safe situations. When even Angular is too much, MVCObject.js is your framework-free framework!™

jRespond

This is a simple jQuery plugin to provide JavaScript hooks for your responsive designs, for those times when media queries don’t quite cut it. It monitors window size with a single observer, and triggers your callback whenever it crosses the height, width or aspect ratio thresholds you set. If you’re on a platform that doesn’t support media queries, you can also hook it up to apply classes to selected elements instead of triggering a callback.

The World’s Heaviest Business Card

Four and a half thousand lines of code. Three tangential open-sourced repos. A spaghetti mess of oversized and underdeveloped ideas. And one sexy, modern, interactive business card. TL;DR: it’s at the bottom.

The consultant’s life has a lot to recommend it, but it comes at the cost of stability. Over the winter of 2012-13, I had my first serious drought: for three months, nobody called. It turned out to be the natural ebb and flow, and when work returned in February it returned with a vengeance. But for the darkest months of the year I had nothing to do, and no established coping mechanisms to fall back on. So I fell into node.

The stated goal was a personal website, including standard fare: an About Me section, a blog, some other things. This was in the days before Ghost though, and anyway I was in it to learn, so I bullheadedly started from scratch. I learned the ins and outs of not only node, but mid-decadal CSS3, and web development outside of the rigid strictures of SproutCore, and every social networking API I could get my hands on. (I also taught my dog to follow her leash the right way around trees and signposts, which stands as my proudest accomplishment in life.)

It turns out that, absent rigid strictures, I invent my own, and the project soon swelled to an untenable scale: Before I knew it, each page was a dynamic web app, loaded and launched lazily, aggressively optimized with cacheable parts and preloaded data, full of realtime coordination between the client and the server, and with hooks that suggested the dashed-off, unstable outlines of a platform.

Then February hit, and clients materialized, and 80-hour weeks became normal. The website, half-built, overweight and very much between stable builds, faded.

This winter’s slowdown was less drastic than last, but it did happen. I put some effort into a project (stay tuned) which justified the creation of an honest-to-functional personal website – WordPress this time, like a normal person. I showed the previous winter’s Ozymandian wreckage to a friend over beers, and he suggested wisely that the About section – essentially complete, though ragged and out of date – might be worth salvaging as a standalone widget, embeddable and linkable.

So with the wife out of town and the dog asleep after a long day of tensely staring at squirrels, I set about hiding the unnecessary elements, all of the tentacles of scope blowout, leaving just a modern, interactive business card.

Here it is! (It’s real, you can click on it.)

(If you’re on an iPad, standard weirdnesses with scrolling in iframes apply. For example, if I tap and drag sideways, it scrolls up and down, and why do we even have rules, and Daisy Daisy give me your answer do.)

Here it is. (You can view an embedded version on a larger screen.)

Maybe only a couple thousand lines of code in evidence, but I’m pretty happy with how it came out, all embeddable and linkable and things. Even if there’s no formalized control flow to speak of, even if I only managed a half-baked twitter card (twitter card is now fully-baked!), even if I ran out of steam on the LinkedIn card and just slapped in a base prefab embed.

Along with formalizing and publishing any smaller standalone spinoffs, the plan was always to open the source, because why not, and because I write better code when I think I’m being watched. So, for your amusement, it’s up – minus API keys, and minus Mongo, into whom I got around to transitioning the bare minimum of content – on GitHub. A few things might even be generalizable: once properly scalpelled out, the Ken Burns card should respond to any Instagram API key… the GitHub card will display information for any user and any set of public repos, that is once you get the prerequisites installed, and track down the private environmental variables, and decode the mongoose schema… and… um… look upon my works!….

SproutCore on iPhone: Cocoa-in-JavaScript Comes of Age

Apple’s other iOS app vector, the Open Web, is finally catching up.

There’s a reason that Cocoa, Apple’s flagship set of application development frameworks, is written, essentially, in C.

Cocoa, like any world-class framework, is a beast of abstraction: it exists to make the complex simple. Take Key Value Observing (KVO). This mainstay of MVC and related patterns allows you to bind two properties on two different, disparate objects, together. If one of them changes, the other one updates. This lets you do trivial things like change the background color when the user updates the setting, or crucial things like display data as it loads from a server.

It’s pretty hard to overstate the impact that KVO can have on your code. When values automatically stay synced, different parts of your application don’t need to know about each other. Separation of concerns, code sharing between applications, all kinds of Best Practices become Easy Practices. And, once you’ve set up your binding, triggering that cascade of updates is as simple as this:

[obj setValue:newValue forKey:@"propertyName"];

It’s like magic!

Of course it’s not actually magic, it’s abstraction at work, and it comes with a cost. That one easy line of code wraps dozens or hundreds of internal commands and complex data structures. All of the bound properties that need syncing, all of the observing methods that need calling, they all need to be tracked, updated, and properly disposed of when the time comes. So suddenly one simple command – a basic KVO setter – is triggering an invisible avalanche. Good abstractions come with the danger of allowing developers to run tons of code without the bother of having to write tons of code.

When you’ve got layers of abstraction serving as code multipliers like that, the underlying code needs to be fast. And it needs to be even faster to run on the iPhone, with its memory restrictions and puny CPU. So, with its eyes firmly on speed, Apple has bullheadedly refused to follow industry trends towards heavily interpreted languages. Even its experiment with garbage collection was canceled just a generation after it began. Cocoa remains Objective-C: a speedy superset of C, and as uninterpreted a language as you’ll find. And it needs to be, in order to stay fast when there’s so much abstraction in the air.

Pan over to JavaScript. It’s loosely-typed. It’s garbage-collected. It’s not even shipped around in semi-digested intermediate representations: it’s literally fed to the browser as raw text. For all of its vaunted flexibility, and for all of the billions of dollars that Google et al. have sunk into speeding it up, all of that comes with a healthy performance penalty. And it always will, no matter what the true believers say. But being slower than a speeding bullet doesn’t necessarily make you slow.

SproutCore, the granddaddy of JavaScript MVC frameworks, is Cocoa for the web. KVO and bindings are baked in at the lowest levels, and the SproutCore equivalent of our Cocoa setter from above – obj.set('propertyName', newValue); – triggers its own invisible, sophisticated, expensive avalanche.

That abstraction is extraordinarily powerful: SproutCore uses it to bring sophisticated application development strategies and sensibilities to the web application arena, a space which is often sorely lacking in them. A SproutCore application will have well-organized, well-segregated models, views and controllers, managed by a powerful state machine and tied together with the magic of KVO. In short, a SproutCore application will be an application. It just happens to run in the browser.

The reasons to choose the web for your applications, if you can, are myriad, and well-established: cross-platform compatibility, simple deployment, et cetera.  But note the caveat – “if you can”, and performance was one longstanding barrier. Eight years ago, JavaScript was too slow a language to allow for the valuable abstractions that a Cocoa-inspired framework needs. But Google marched its famous march towards faster JavaScript engines, and we’ve entered a golden era on the desktop.

The mobile space took a bit longer. When the iPhone debuted, its JavaScript engine was pathetic. Keep in mind that the web was Steve Jobs’ first choice for third-party apps, and is the company’s answer to anyone upset by App Store policies. For years, it was a laughably half-kept promise: Mobile Safari wasn’t fast enough to run the New York Times smoothly, much less handle deep layers of valuable, application-y abstractions.

Then came the iPhone 4S and we were almost there, and then came the iPhone 5, and finally Steve’s promise that we would have a non-curated, non-closed, cross-platform avenue to publish our apps on the iPhone came true. Applications, real ones with grownup application architectures, ones that just happen to be written in JavaScript and happen to run in a web browser, can finally run on your phone. And every generation’s CPU bump brings another JavaScript speed bump, handily meeting the performance needs for another swath of application classes.

C is faster than JavaScript, by a lot, and it always will be. But the goal isn’t supercomputer speeds. Most applications are not doing realtime video editing, breaking encryptions, or mining Bitcoin on the side. The raw speed of a line of code, or of a mathematical operation, isn’t now and wasn’t ever the point. The goalpost for most applications – the light word processing, light photo editing, local storage, and animations between screens – is set at the line on the field where performance begets headroom. Real applications need real application frameworks like SproutCore, and real application frameworks need enough performance to abstract, to hide deep complexity behind delightfully simple commands.

It’s 2014, and the iPhone can deliver. Time to start creating.

Hello, world! I am here.

You’re making a blog? said my mother on a recent visit. What about? My life, I replied, maybe a shade too patiently. Stuff I’m working on, whatever. I just need a blog. Well it wouldn’t be social media if it wasn’t completely self-absorbed, muttered my father from the easy-chair, an eyebrow arching up over his bifocals.