Mile
Zero

We came very close to using WebGL for a Seattle Times special report that will come out next week. Now that iOS 8 has shipped with support for WebGL, albeit in an unstable and slightly buggy form, it's common enough that I felt comfortable using it (with a scaled-down 2D fallback) for our audience. In the end, we went with a different design language and shelved the WebGL experiments, but the experience has left me very excited about the potential for mainstream usage.

It's probably easier to understand why WebGL is exciting by looking at what the regular 2D canvas does badly. 2D canvas is terrible at combining or masking its rendering functions (globalCompositeOperation in particular is dog-slow in Firefox). It doesn't give users easy access to the image data directly, which is frustrating in a bitmap-based drawing API. It doesn't like changing colors or styles frequently. But its biggest weakpoint is actually that it's tied so closely to JavaScript, which is a single-threaded language running in the browser event loop. The more pixels you touch in detail, the slower it gets.

WebGL, by contrast, is great at blending, filtering, and masking. But most importantly, WebGL code moves most (if not all) of the math-heavy graphics code you'd normally write in JavaScript — scaling and transforms, patterns, and color — over to the GPU. Your graphics card is a massive parallel-processing machine, so all your drawing occurs simultaneously, not sequentially. You can alter every pixel in the frame, if you want, and it'll barely take any more time than if you change only a few.

Once I spent a little time writing some simple shaders, I realized that there's a whole range of experiences you can write in WebGL that simply aren't possible on a 2D canvas. I could shift the colors or custom-filter an image on a per-pixel basis. I wrote a dust simulation that simulated thousands of motes on a low-end machine, even with the physics still running in JavaScript. I even created a faux-3D effect a la Depthy, by displacing each pixel by the value of a second texture's lightness and the mouse position.

None of these experiments involved 3D math in any way. They're not spinning teapots, or Unreal Engine demos, or elaborate parallax effects. I suspect that the real value of WebGL isn't going to be from any of those things. It's going to be the fact that it gives the web platform the free-drawing capability of canvas, but uncoupled from the JavaScript execution model that it's been shackled to.

There's an obvious parallel here, which is the first two major versions of Android. Because it was designed to run on low-end hardware, Android drew all its UI via software until 3.0 (and hardware acceleration didn't become widespread until 4.0). The resulting lag was never as bad as critics claimed, but it did mean that a lot of Android looked and felt a bit utilitarian. You wouldn't see something like Material Design emerge until the system supported using the GPU for rendering ordinary UI.

It's not a coincidence that Google's moving to Material Design on both Android and the web. Its design language — a smoothly-animated world of flat, geometric shapes — is attractive, but more importantly it's well-matched to the kinds of flat, geometric shapes that can be animated fluidly in a browser, using the 3D acceleration that's already built into the composition layer. Web Components will give developers a way to package those elements up, and make them reusable. Flexbox makes their layouts scalable and responsive.

But for the web platform to move forward, we need more than just a decent look and feel. We need the ability to write the kinds of applications that people insist that it can't run. WebGL is a step in that direction: graphics with near-native speed and capability, instantly deployed and paired with a surprisingly powerful UI toolkit. The kinds of apps and experiences we can write othe web, for a mainstream and mobile audience, just got a lot bigger. And I for one am looking forward to pushing those boundaries as much as I can.

Paul Kinlan's post, Add-to-homescreen Is Not What the Web Needs, is only the most recent in a long-running debate surrounding "apps" on mobile, but it is thought-provoking. Kinlan, who cheerleads for the Web Intents integration system in Chrome, naturally thinks that having an "add-to-homescreen" option misses the point:

I want to see something much more fundamental. The web offers something far richer: it encourages lightweight usage with no required installation and interaction with on-demand permissions. I never want to see an install button or the requirement to understand all the potential permissions requried before trying the app. The system should understand that I am using an app and how frequently that I use it and it should then automatically integrate with the launch points in the OS.

Kinlan has a great point, in that reducing the web to "just another app" is kind of a shame. The kinds of deeper integration he wants would probably be prone to abuse, but they're not at all impossible. Mozilla wants to do something similar with Firefox OS, although it probably gets lost in the vague muddle of its current state. Worse, Firefox OS illustrates the fundamental problem with web "apps" on mobile, and it's probably going to take a lot more than a clever bookmark to solve the problem. That's because the real problem with the web on mobile is URLs, and nobody wants to admit that.

As a web developer, I love URLs. They're the command line of the web: a powerful tool for organizing information and streaming it from place to place. Unfortunately, they're also like the command line in other ways: they're arbitrary, much-abused, and ultimately difficult to type on mobile. More importantly, nobody who isn't a developer really understands them.

There is a now-infamous example of the fact that people don't understand URLs, which you may remember as the infamous Facebook login of 2010. That was the point at which the web community realized that for a lot of users, logging into Facebook went a lot like this:

1. Search Google for "facebook login"
2. Click the first link
3. Look for the password box

As a process, this was fine until ReadWriteWeb actually published a story about Facebook's unified login that rose to the top spot in the Google search listings, at which point hundreds of people began commenting on the article thinking that it was a new Facebook design. As long as they got to Facebook in the end, to these people, one skinny textbox was basically as good as another. I've actually seen people do this in my classes, and just about ground my teeth to nubs watching it happen.

In other words, the problem is discovery. An app store gives you a way to flip through the listings, see what's popular, and try it out. You don't need to search, and you certainly don't need to remember a cryptic address (all these clever .io and .ly addresses are, I'm pretty sure, much harder to remember than plain old .com). For most of the apps people use, they probably don't even scroll very far: the important stuff, like Facebook and Candy Crush, is almost certainly at the top of the store anyway. Creating add-to-homescreen mechanisms is addressing the wrong problem. It's not useless, but the real problem is not that people don't know how to make bookmarks, it's that they can't find your web app in the first place.

The current Firefox OS launcher isn't perfect, but it at least shows someone thinking about the problem. When you start the device, it initially shows a search box titled "I'm thinking of...". Tap into the box and even before you start typing it'll instantly start showing a set of curated sites sorted into categories like "social" and "games." If you want isn't there, you can continue to search the web as a whole. Sites launched from this view start in "app mode" with no URL bar, even though they're still just web sites and nothing's technically been installed. Press the bookmark button, and it's added to your homescreen. It's exactly as seamless as we've always claimed the web could be.

On top of this, sadly, Mozilla adds the Marketplace app, which can install "packaged" apps similar to Chrome OS. It's an attempt to solve the discoverability problem, but it lacks the elegant fluidity of the curated results from the launcher search (not to mention that it's kind of confusing). I'm not wild about curation at the best of times — app stores are a personal pet peeve — but it serves a purpose. We need both: an open web, because that's the spirit of things, and a market destination, because it solves the URL discovery process.

What we're left with is a tragedy of the commons. Mozilla's marketplace can't serve the purpose of the open web, because it's a curated and little-loved space that's only for Firefox OS users. Google is preoccupied with its own Chrome web store, even though it's certainly in a position to organically track the usage of web apps via user searches. Apple couldn't care less. In the meantime, web app discovery gets left with the scraps: URLs and search. There's basically no way, other than word of mouth, that your app will be discovered by normal people unless it comes from an app store. And that, not add-to-homescreen flaws, is why we can't have nice things on the web.

After a busy couple of weeks, Seattle went and won the Super Bowl, leading to the world's most polite celebration in our neighborhood:

There was another prize for the weekend: a friend of ours gifted us a Chromecast, which will be much appreciated since there's currently no way to watch HBO on the PS4. On Monday, Google released the public SDK for the platform, so I decided to poke around a bit.

Chromecast has a decidedly-odd way of loading content. The device itself is just a thin shell around a Chrome window, and it loads web pages like any other browser. But there's no keyboard of any kind, so how does it know which page to load? The answer is that each "app" has an ID listed with Google, corresponding to a set of URLs that the developer provides. When a mobile app or a computer running Chrome triggers the Chromecast, it sends the app ID, which the device then sends to Google and gets a URL in return (or, if the app hasn't been listed, it does nothing). From that point on, you can send messages to the page over via Google's cloud, and your page can do whatever you want it to do. Getting your pages linked to an application ID on the Chromecast lookup servers costs $5.

Five dollars is a low price, but it's more than I really want to pay for a glorified DNS. I'm a little dismayed by the restrictions on the open web — I'd like the option to just send a URL directly. I'm also holding out for a pure JavaScript API, instead of piggybacking on the Chrome extension. So I probably won't be writing any Chromecast apps any time soon. But it's certainly not for a lack of ideas. The interaction model that Chromecast uses — where the screen is just a dumb display, but it can receive commands from other web-accessible devices — is strikingly similar to Microsoft's SmartGlass model. And where Microsoft seems to see it as a way to create companion apps for XBox, I think it's interesting to think about how this "distributed I/O" model could be used for standalone applications.

• The Chromecast isn't going to rival any consoles, but it wouldn't have to be for a lot of group gaming experiences. Just having a screen that could be used as a scoreboard, or a trivia question where phones are used as buzzers, would be a cool usage that doesn't require precise controls or rich graphics. Turn-based games could easily use the screen as a board overview, while letting people zoom in and move their pieces from their local touchscreen. It also provides an interesting split between public and private information for players that many video games (excepting the Wii U and Dreamcast) couldn't duplicate.
• I love maps. I think they're the real face of augmented reality, as any regular traveler can attest these days. But they don't have to be mobile. A Chromecast could easily serve as a map up on your wall, updated with whatever information you find interesting. Maybe that's as simple as the weather, but imagine being able to tag it with RFID information or last-known positions for people in your household. Systems like Google Now, which learn from your schedule, could even post notifications for the buses that are coming or traffic problems that you're likely to face.
• Along those same lines, a simple dashboard could be helpful for businesses and individuals. Being able to throw metrics up on the wall with a web browser is not a new thing, but tying it to a smart, feed-aware service would open up all kinds of new tricks, like being able to leave yourself notes via a hashtag on social networks. There's not really any input needed: it's just a passive display of whatever you want to keep yourself caught up on, in an easy at-a-glance format.
• Finally, it's probably just all the public speaking I've been doing lately, but it's tempting to think that a presentation app for Chromecast would be super-helpful for speakers. A lot of times, when I go to a meetup or a new classroom, it's hard to predict what kind of video hookups the projector will have, assuming that they even have a projector. But many times, there will be a big-screen LCD TV, with a handy HDMI input. Being able to carry a Chromecast with me to make my presentations, especially if the speaker notes can be viewed separately, would be awesome.

When we talk about the web being device-agnostic, the Chromecast is a perfect example of what we're talking about. It's radically different from other web clients: low DPI on a big screen, no local input, and unpredictable performance. But that's the power of the platform — as a toolkit, its reach is unparalleled. And the restrictions prove to be exciting inspiration for new uses, just as touchscreens came with their own unique challenges and advantages. I don't know if Chromecast is going to be successful, but the hacks for it are going to be really interesting.

In the time since I last wrote about Caret, it's jumped up to 1.0 (and then 1.1). I've added tab memory, lots of palette search options, file modification watches, and all kinds of other features — making it legitimately comparable with Sublime. I've been developing the application using Caret itself since version 0.0.16, and I haven't really missed anything from native editors. Other people seem to agree: it's one of the top dev tools in the Chrome web store, with more than 1,500 users (and growing rapidly) and a 4.5/5 star rating. I'm beating out some of Google's own apps, at this point.

Belle's reaction: "Now you charge twenty bucks for it and make millions!" It's good to know one of us has some solid business sense.

The next big milestones for Caret will focus on making it better at workflow, especially through plugin integration. Most editors go from "useful" to "essential" when they get a way for users to extend their functionality. Unfortunately, the Chrome security model makes that much more difficult than it is with compiled binaries: packaged apps aren't allowed to expose their internals to external JavaScript, either through script tags or eval(). The only real extension mechanism available is message-passing, the same as web workers.

Caret is already designed around message-passing for its internal APIs (as is Ace, the editing component I use), so it won't be too difficult to add external hooks, but it'll never have the same power as something like Sublime, which embeds its own Python interpreter. I can understand why Google made the security decisions they did, but I wish there was a way to relax them in this case.

I figure I have roughly six months to a year before Caret has any serious competition on Chrome OS. Most of the other editors aren't interested in offline editing or are poorly-positioned to do so for architectural reasons. The closest thing to Caret from the established players would be Brackets, which still relies on NodeJS for its back-end and can't yet run the front-end in a regular browser. They're working on the latter, and the former will be shimmable, but the delay gives me a pretty good head start. Google also has an app in the works, but theirs looks markedly less general-purpose (i.e. it seems aimed specifically at people building Chrome extensions only). Mostly, though, it's just hard to believe that someone hadn't really jumped in with something before I got there.

Between Caret, Weir, and my textbook, this has been a pretty productive year for me. I'm actually thinking that for my next project I may write another short book — one on writing Chrome apps using what I've learned. The documentation from Google's end is terrible, and I hate to think of other people having to stumble through the APIs the way I did. It might also be a good way to get some more benefit out of the small developer community that's forming around Caret, and to find out if there's actually a healthy market there or not. I'm hoping there is: writing Caret has been fun, and I'd to have the chance to do more of this kind of development in the future.

At this point, Caret has been in the Chrome Web Store for about a week. I think that's long enough to say that the store is a pretty miserable experience for developers.

When I first uploaded it last week, Caret had these terrible promo tiles that I threw together, mostly involving a big pile of carrots (ba dum bum). At some point, I made some slightly less terrible promo tiles, stripping it down to just bold colors and typography. Something set off the store's automated review process, and my new images got stuck in review for four days — during which time it was stuck at the very bottom of the store page and nobody saw it.

On Tuesday, I uploaded the first version of Caret that includes the go-to/command palette. That release is kind of a big deal--the palette is one of the things that people really love about Sublime, and I definitely wanted it in my editor. For some reason, this has triggered another automatic review, this one applied to the entire application. I can unpublish Caret, but I can't edit anything — or upload new versions — until someone checks off a box and approves my changes. No information has been provided on why it was flagged, or what I can do to prevent these delays in the future.

Even at the best of times, the store takes roughly 30 minutes to publish a new version. I'm used to pushing out changes continuously on the web, so slow updates drive me crazy. Between this and the approval hijinks, it feels like I'm developing for iOS, but without the sense of baseless moral superiority. What makes it really frustrating is the fact that the Play store for Android has none of these problems, so I know that they can be solved. There's just no indication that the Chrome team cares.

I was planning on publishing a separate, Google-free version of the app anyway, so I worked out how to deploy a standalone .crx file. The installation experience for these isn't great — the file has to be dragged onto the Chrome extensions list, and can't just be installed from the link — and it introduces another fun twist: even though they promised it would be possible for years, there's no way to download the private key that Google uses in the Chrome store, meaning that the two installations are treated as completely different applications when installed.

Fair enough: I'll just make the standalone version the "edge" release with a different icon, and let the web store lag behind a little bit. As a last twist of the knife, generating a .crx package as part of a process that A) won't include my entire Git history, and B) will work reliably across platforms, is a nightmare. Granted, this is partly due to issues with Grunt, but Chrome's not helping matters with its wacky packaging system.

All drama aside, everything's now set up in a way that, if not efficient, is at least not actively harmful. The new Caret home page is here, including a link to the preview channel file (currently 3 releases ahead of the store). As soon as Google decides I'm not a menace to society, I'll make it the default website for the store entry as well.

The problems with Google's web store bug me, not so much because they're annoying in and of themselves, but because they feel like they miss the point of what packaged web apps should be. Installing Caret is fast, secure, and easy to update, just as regular web apps are. Developing Caret, likewise, is exactly as easy and simple as writing a web app (easier, actually: I abuse flexbox like crazy for layout, because I know my users have a modern browser). Introducing this opaque, delay-ridden publication step in between development and installation just seems perverse. It won't stop people from using the store (if nothing else, external installation is too much of a pain not to go through the official channel), but it's certainly going to keep me from enjoying it.

As I mentioned in my Chromebook notes, one of the weak points for using Chrome OS as a developer is the total lack of good graphical editor. You can install Crouton, which lets you run Vim from the command line or even run a full graphical stack. But there aren't very many good pure text editors that run within Chrome OS proper — most of the ones that do exist are tied to hosted services like Cloud9 or Nitrous. If you just want to write local files without a lot of hassle, you're out of luck.

I don't particularly want to waste what little RAM the Chromebook has running a whole desktop environment just for a notepad, and I'm increasingly convinced that Vim is a practical joke perpetuated by sadists. So I built the Chrome OS editor I wanted to have as a packaged app (just in time!), and posted it up in the store this weekend. It's 100% open source, of course, and contributions are welcome.

Caret is a shell around the Ace code editor, which also powers the editor for Cloud9. I'm extremely impressed with Ace: it's a slick package that provides a lot of must-have features, like syntax highlighting, multiple cursors, and search/replace, while still maintaining typing responsiveness. On top of that base, Caret adds support for tabbed editing, local file support, cloud settings storage, and Sublime-compatible keystrokes.

In fact, Sublime has served as a major inspiration during the development of Caret. In part, this is just because it's the standard for web developers that must be met, but also because it got a lot of things right in very under-appreciated ways. For example, instead of having a settings dialog that adds development complexity, all of Sublime's settings are stored in JSON files and edited through the same window as any other text files — the average Sublime user probably finds this as natural as a graphical interface (if not more so). Caret uses the same concept for its settings, although it saves the files to Chrome's sync service, so all your computers can share your preferences automatically.

The current release of Caret, 0.0.10, is usable enough that I think you could do serious editing with it — I've certainly done professional work with less effective tools, including the initial development on Caret itself — but I'm on a roll adding features and expect to have a lot of improvements made by the end of next week. My first priorities are getting the keybindings into full working condition and adding a command palette, but from that point on it's mostly just polish, bugfixes, and investigating how to get plugin support past Chrome's content security policy. Once I'm at 1.0, I'll also be posting a standalone CRX package that you can use to install Caret without needing a Google account (it'll even auto-update for you).

Working with Chrome's new packaged app support has been rough at times: there are still a lot of missing capabilities, and calling the documentation "patchy" is an insult to quilts everywhere. But I am impressed with what packaged apps can do, not the least of which is the ease of installation: if you have Chrome, you can now pretty much instantly have a professional-grade text editor available, no matter what your operating system of choice. This has always been a strong point for web apps anyway, but Chrome apps combine that with the kinds of features that have typically been reserved for native programs: local file access, real network sockets, or hardware device access. There's a lot of potential there.

If you'd like to help, even something as simple as giving Caret a chance and commenting with your impressions would be great. Filing bugs would be even better. Even if you're not a programmer, having a solid document editor may be something you'd find handy, and together we can make that happen.

Once Microsoft announced IE 11 will offer WebGL, that was pretty much the last straw: Apple may drag their feet at enabling it in Safari, but everyone else seems to have decided that it's secure enough and capable enough for production. I still think it's a little nutty, but I don't really have an excuse to avoid it anymore. So when an EaselJS-based visualization at work started having performance issues, I wrote a WebGL shim as a learning project.

I stand by my earlier impressions of the WebGL API--it's clumsy and ill-suited to JavaScript--but the performance is undeniably there. Rendering through EaselGL is often orders of magnitude faster than vanilla Easel, particularly when it comes to mouseover responsiveness. It's worth struggling through the learning process if you find that canvas is becoming a bottleneck for your application. I think a more interesting question is why so many WebGL tutorials are awful. And they are awful:

• They hide the WebGL boilerplate behind library code--say, a function call that loads shaders or does matrix math--and force readers to dig through the source to figure out what mat4mult() or loadShader() does.
• Even when they leave the code all in one place, they treat the often-confusing GL code as boilerplate, and don't explain it. Why do I need to call bindBuffer()? What do the six (!) parameters of vertexAttribPointer() actually control? What's the deal with all the constants, like gl.STATIC_DRAW?
• Since WebGL is not a 3D API, they require a lot of 3D math. Most people teach this badly, assuming they don't double down on the mistakes above and just hide it behind calls to library functions. As a result, it's easy to get lost, and hard to reach the "putting shapes on the screen" feedback loop that keeps students engaged.

Of course, these are not uncommon mistakes in programming tutorials. In fact, they're extremely common--I just haven't had to learn anything from scratch in a while, and had forgotten how confusing the process could be. Anyone writing for beginners would do well to keep these errors in mind.

There are a few walkthroughs that I found more helpful. As I've mentioned, Greg Tavares's series on WebGL was eye-opening, and Brandon Jones provided the only worthwhile explanation of attribute array setup that I found. Between those two, and countless Google searches, I managed to cobble together a basic understanding of how the GL state machine actually works.

As a way of distilling out that knowledge, I've assembled the WebGL demo script that I would have wanted when I started out. It uses no external code--everything's right there on the same page. It explains each parameter that's used, and what each function call does. And it's only concerned with drawing a basic 2D shape--no matrix math is involved. It's stored in a Github Gist, so feel free to file pull requests against anything you find confusing. Also, feel free to look through EaselGL: it's a bit more advanced and I need to add more comments, but as a 2D API I think it's quite a bit easier to understand than the typical game library, particularly for ex-ActionScript developers like myself.

By the time you read this, I'll have been running Weir as my full-time RSS reader for two and a half weeks, starting on July 1. It's going well! Having just added OPML export, so that I can switch if it stops being worth the trouble, I've had a chance to sit back and consider some lessons learned from the project.

1. Eight megabytes does not seem like a lot of data these days, but it adds up. Before I started culling feeds (and before I added Gzip support to the request service), Weir was pulling down roughly eight megs of data with each fetch, at ten minute intervals. That's 48MB per hour, a small amount that adds up to over a gigabyte per day. By default, I get 24 gigs per month of transfer allowance on my server. Something had to go.

   It's interesting to note, by the way, that this is something that RSS services like Newsblur or Feedly don't worry so much about, because the cost of each feed is spread across all subscribers. I didn't cost Google Reader as much traffic as Weir requires on its own.

2. So I started unsubscribing. The majority of my original subscription list in Google Reader came from Paul Irish's front-end feed collection, and while I had already unsubscribed from the crazy people, it turns out most of the other blogs in that collection were dead. Even with 304 support added in, Weir was downloading a ton of RSS, only to discard much of it as being past the configured expiration date. I don't think this means blogging is a thing of the past, personally, but it's clearly down from its heyday in favor of social services, particularly (in the technical community) Google+.
3. That said, using Feedburner seems to be a clear indication that you weren't that interested in blogging anyway, because it makes up a disproportionate amount of the abandoned or simply broken RSS feeds on my list. I suspect this is because it signals a lack of ownership. If you care about your feed, you maintain it yourself.
4. Even with feeds that work, sometimes connections fail, or things break, just because it's the wild and crazy web out there. Taking that into consideration from the start, and tracking the last result for every feed, was one of the smarter things I did. I should probably be tracking more, but I'm too lazy to do real logging.
5. Feeds are messy, and sanitization is hard. People inject all kinds of styles into their RSS. They include height and width attributes that don't play well with mobile. They put things into tables. They load scripts that I don't want to run, and images that I'd like to defer until their containing post is activated. Right now, I'm using document.implementation.createHTMLDocument() to make a functional (but "dead") DOM, then running a sanitization task over that, but figuring out that process--and making it watertight--has not been easy.
6. In fact, working with RSS--ostensibly a "machine-readable" format--tends to drive home just how porous the web can be, and how amazing it is that it works at all. Take RSS date formats discovered by the developer of another reader web app, for example. I'm relatively isolated from the actual parsing, but there's code in Weir to work around buggy HTTP responses, missing feed information, and weird characters. Postel's Law has a lot to answer for, in my opinion.
7. "Worse-is-better" really works for me as a personal development philosophy. My priority has been to get things running, no matter how badly--hacks get added to the .plan file and addressed later on, when I have time to figure out a graceful solution. This has kept my momentum high, and ensured that I don't get bogged down with architecture that I might not even need.
8. The value of open-source software for this project can't be overstated. There's no way I could have built Weir on my own. In addition to Node, of course, I'm using a number of open-source modules for parsing feeds, handling two-factor auth, and storing posts in the database. Because of open source, I can patch those various libraries together, add my own code on top, and have a newsreader application that does everything I need. Weir doesn't stand on the shoulders of giants--it stands on the shoulders of countless other people, each giving a little bit back to the wider community.

I bought a Chromebook (the Samsung ARM model) a couple of weeks ago. It became increasingly obvious that the battery situation on my beloved Thinkpad was going from bad to worse, and trustworthy replacements are hard to find--especially on a budget. I still have lots of uses for the Thinkpad (it may end up serving as a media center if the XBox dies again), but it can't really be portable the way I need it to be when my classes start back up again.

I don't particularly want to get into the question of whether the Chromebook is a good solution for other people. I'm not other people. I can't tell you whether they'll like it. I think it covers a great deal (if not all) of the average person's computer usage, most of which is spent in a browser, but I don't have evidence to back that up, and I'm not going to treat my case as representative. What I can say is how it's working for me so far, specifically as a writer and a web programmer with a heavy emphasis on Linux tools. And the answer is that, for the most part, it's working very well.

My top priority was battery life and portability. I'm on a bus for two hours a day, and one of my goals this year has been to turn that into productive time by working on my textbook, lesson plans, or other projects, preferably with some juice left over for when I get off the bus and walk into my classroom at night. The Chromebook definitely has that covered. I'm not sure the battery meter is 100% accurate, but I tend to run out of energy before it does, and the ultrabook size is easy to carry or slip into a small Timbuktu bag. The build quality seems solid, although I'm a bit uneasy with the idea of cheap, "disposable" laptops like this.

Second priority was a decent browser experience, since (like most people) I spend most of my time these days in a browser. Depending on the page, the Chromebook can be a little slow sometimes, but it handles most things the way you'd expect Chrome to do. It's easy to forget that it's basically a smartphone chip hooked up to a big screen. WebGL performance is surprisingly good: I loaded up the new Google Maps beta, and had no problems panning around a 3D textured version of downtown Seattle. Flash is built-in, so I'm not missing that (the new XBox Music site, like a lot of its competitors, still uses Flash for streaming audio). Tethering works flawlessly.

But my third priority (and still a must-have factor for me) was the ability to develop and write on the Chromebook itself. Being able to log into a server from the Chrome OS SSH client is fine, but a lot of the time I still don't have a network connection. If I can't work locally using the tools I'm used to, it's useless to me.

There's a thing called Crouton that installs a full, semi-sandboxed Linux distribution alongside Chrome OS. The two operating systems share a kernel, but have separate sets of binaries and processes. The result is a complete Ubuntu server stack that I can dip into whenever I need to work offline, including Git, NodeJS, PostgreSQL, and all the other command-line utilities I've gotten used to having. Crouton's totally supported, by the way: you need to be in developer mode, but that's just a keystroke away.

You can even set Crouton to run the graphical interface for the second OS, toggling between them, but considering how much I hate the Linux GUI situation, I haven't bothered. Chrome OS works nicely to manage my terminal and browser windows--the Aura interface that they've added lately does a decent impersonation of Windows 7, including an improved version of Aero Snap. There are some quirks--the dedicated "switch windows" button doesn't seem to quite work consistently--but it's already the best Linux window manager I've used.

The weirdest thing as a developer is the lack of full-powered editors running within Chrome itself. Cloud9 doesn't run on ARM yet, and Brackets isn't available as a packaged app. I'm personally fine using a terminal-based editor--I wrote most of Weir using Nano, and I'm getting more comfortable with vim--but it surprised me that none of the web-based editors have made a serious effort to run on a web-based platform.

The second-weirdest thing is the way Chrome OS distinguishes between "bookmarks" and "applications," considering that (for the most part) they're the same thing. There is a legitimate set of "packaged apps" that get more privileged API access, but most of the products in the Chrome "web store" are just links to web sites, so why can't I add bookmarks (such as the aforementioned XBox Music site, which I prefer to run in its own, chromeless window) to the Chrome OS launcher? I've been using this method to build single-serving Chrome Apps for the few sites where I want this ability, but it really ought to be built-in, and (considering that all you need is a JSON manifest and a .png file) I have a hard time understanding why it's not.

Oddities aside, though, the Chromebook is a great little machine for my needs so far. If I edited photos/audio/video on the go, or wanted a portable gaming laptop, I'd probably feel differently. On the other side of the power spectrum, if I didn't need a keyboard, I'm sure an Android tablet would cover a lot of my needs. My work, however, is almost entirely centered on text-editing in a web-friendly (preferably Linux or Windows) environment, and Chrome OS handles that gracefully and without complaint. It's surprisingly close to being useful even without Crouton. I'm excited to see whether (between Chrome OS and Firefox OS) the web platform can become legitimately self-sufficient in the future.

I'm happy to say that Weir is now in a beta-ready state. You'll need a server capable of running NodeJS and PostgreSQL (for now), and you'll need an OPML file to populate the feed list (Google Takeout will accomodate you nicely with a subscriptions.xml if you're fleeing Reader). But if you pull from the repo and then follow the instructions in the readme file, everything should be in a good-enough state to fetch, read, and mark stories as read. Feedback would be awesome.

The front end for Weir is written using AngularJS, because it's supposed to be great for rapid development and I'm all about failing fast on this project. Indeed, getting the client-side application up and running has gone very quickly, but Angular itself takes some adjustment, especially if you're used to other JavaScript frameworks.

I'm not convinced that this is a bad thing. Predictions are a mug's game, but I suspect that future libraries are going to look a lot more like Angular than its competitors. Before I can explain why, we have to first look at the way client-side JavaScript has been traditionally organized, and then see how Angular works differently.

JavaScript MVC libraries, from Backbone to Ember, find themselves confronted with a language that's very different from the languages where Model-View-Controller philosophies evolved:

• JavaScript has no privacy, and (until recently) no getters and setters. Between the two, it's hard to know if a given object has changed since the last redraw.
• The DOM is not designed to be strongly linked with JavaScript data structures.
• Multi-level inheritance of values is fine, but inheritance of behavior is a mess.

Despite these quirks, libraries are still designed as if JavaScript was similar to SmallTalk. They work around the differences by using manual getter and setter functions on Model classes, registering for DOM events inside View classes, and retemplating using templates when one or the other is changed.

This works--and is certainly a million times better than writing jQuery spaghetti code--but it's not what you'd call "clean." For example, here's some code written in an imaginary (but typical) library, just to update a simple list view: var Song = new Vertebrae.Model.extend({ title: { value: "" }, listens: { value: 0 }, file: { value: "" }, starred { value: false } }); var SongView = new Vertebrae.View.extend({ render: function() { var model = this.get("model"); var el = this.get("element"); el.find(".can-template").html( templates.song(model.toJSON())); var rev = model.get("review"); el.find(".cannot").val(rev); } });

That is a lot of boilerplate just to display a song (and it doesn't even include the templates, or loading the actual data). Heavy object classes are necessary so that the framework can be notified of changes--hence all the extend and get calls, as well as the awkward way of defining default values. In places, we can at least use templates, but we're still having to place them manually into the DOM. It's like a terrible parody of Java's worst bits glued onto jQuery.

In contrast, Angular uses regular JavaScript objects, written with normal JavaScript syntax, for its models. There are no getter or setter functions, unless you really want them: change an object, and if it is attached to the $scope variable, it will be scanned for changes automatically. And while you're not discouraged from using inheritance, you're not really encouraged to do so, either. Angular uses prototypal inheritance to manage values under the hood, but its developer-facing APIs tend to bear more resemblance to AMD or CommonJS modules. It feels like JavaScript, in other words.

On the other hand, Angular is all about augmenting HTML: although templates are available to ease re-use, an Angular page actually gets marked up using custom tags and attributes, then compiled and linked into components that respond instantly to the application's backing data. This is very forward-thinking--in fact, it's not dissimilar from the Extensible Web Manifesto, and I can dig that--but it definitely comes across as "magic" the first time that you use it. After years of logic-less template engines being popular, Angular stakes out a very different position.

Normally, I'm not a fan of magic in programming: it's hard to debug what you don't understand. In this case, the novelty of Angular's approach--and its undeniable effectiveness--overcame my skepticism, to the point where it's really grown on me. Using Angular makes me much more aware of the boilerplate that's required by the traditional MVC frameworks I use in my day job. Simple tasks require less code, and I don't feel like I'm fighting my way through thick layers of abstraction.

If there's a place where Angular still feels awkward, it's anything to do with the DOM. Angular will let you get access to elements of your page, but only reluctantly--it would really prefer that you only alter your model data and let the DOM react. Most of the time, this is fine: the less page manipulation I have to do, the happier I am. But there are some times when it is inevitable, such as when I'd like to perform deferred image loading, and those are definitely the ugliest parts of Weir's client code so far.

But here's the rub: if the web ecosystem teaches us anything, it's that you can always make a simple framework faster and more powerful, but people won't use an API that's clumsy and tiresome (see also: jQuery vs. pretty much everything else). Yes, DOM manipulation isn't great in Angular--they'll have to write some new directives, to cover the edge cases and holes. Yes, the object polling that Angular does is kind of scary, but browsers will add features like Object.observe() to make it faster overnight. Meanwhile, nothing's going to make those heavy Model and View classes any more fun to use.

There has been (and still is) a lot of time in the JavaScript community spent trying to make it work like something more familiar. That's how you end up with Coffeescript, or YUI, or all these MVC frameworks. Those projects have a place, and there are certainly times when I want something familiar, but it's also good to see tools (like Angular, Node, or D3) that are built around JavaScript weirdness. There hasn't been an oddball language with a profile this high in a long time, so let's shake things up while we've got the chance.