Ruminations on front end-centric webapps

Standard

I’ve been poking around firebase & meteor, and sparkleshare+github and dropbox+site44. I’m a bit disturbed (in a good way) by what feels to me like a sea change that’s happening there, and it seems to me that almost anyone thinking about web developers writ large needs to think hard about what this means for their roadmap.

In particular, a few brief thoughts:

I’ve been, for a while now, using sparkleshare + github pages with CNAME support as a way of making trivial static sites that are real. Sparkleshare is an open source git-syncing-to-filesystem client (with nice ergonomics and design, OMG!). With github-pages and CNAME support, this means that I save in my favorite text editor, and within _seconds_ the thing is live on the web. That’s a disruptive flow.

I’ve been coaching the harp.io team through WebFWD, and they have a service which does similar things on top of Dropbox, including coffeescript/haml processing, CDN, load balancing, push-button deploy, screenshotting for multiple user agents, rollback, etc. In other words, you author your webapp locally on a dropbox folder, and they take care of high-quality, high performance hosting. There is no app-specific server-side logic (which means you need to either have static sites or integrate with hosted services for said features).

I recently ran into site44.com, which does a ‘cheap & cheerful’ version of what harp.io does, with no push-button deploy/rollback, and much more like sparkleshare — instant deploy, with little management capabilities (but instant gratification).

Both harp.io and site44 use Dropbox for syncing, which is a Big Idea in my opinion because setting up Dropbox is so much easier than setting up git credentials (what with SSH keys, etc.). Both assume that the user has write access to local files (which may be a problem in some retrograde environments like enterprises and schools, but which could be solved with web-based editors).

I finally bit the bullet and dig in again into Firebase. Firebase is effectively a key-value store, with Pubsub messaging of data changes. They’ve made some interesting progress in their security and auth models (they include persona support, which is cool). Firebase feels like it makes it trivial to add state and real-time behaviors to previously static sites. The API surface area is quite small, so it should be fairly easy to adopt.

I’m also looking again at Meteor. Since they first launched w/ both fanfare and a bit of ridicule due to overhype, they’ve cleaned up their act significantly: the license is now MIT, they’ve announced $11M in financing from tier-1 VCs, announced an enterprise business plan to complement their open source offering, and build a bunch of APIs. Meteor feels like a steeper learning curve, and another “at-bat” for reactive programming (a topic I’ve been interested in for a decade).

Meteor feels like a solid foundation for a potential full-stack offering, and I like the open source option; Firebase feels like a really compelling basis for demoware and hacks. Regardless, syncing from filesystem to websites without thinking too hard about deployment is a huge benefit of front-end-driven sites.

Single-page apps feels to me like the conceptual next hurdle. Figuring out how to manage history and state management so that the app feels as dynamic as the best webapps, but has good URL support, etc., is an engineering challenge (see e.g. history.js). And it certainly challenges the old mental model of one URL -> one file which pulls down other resources. The newer model (especially on mobile, low-latency devices) needs to be one app -> many URLs, with one core application logic which pulls data-as-JSON and builds most state clientside (with serverside rendering as an optimization for high traffic or slow-CPU environments, as per airbnb’s post).

I’m not sure what this means for advanced webmaker skills. At the very least explaining some of the above to a broader audience is something we could do.

SaaS as a Service?

Standard

If you haven’t been paying attention (and really, most people shouldn’t), there’s what feels like a real trend where startups are breaking down common tasks for web & app development, and solving them through a software-as-a-service model. So, in no particular order, you can see

  • stripe doing payments
  • disqus doing commenting
  • firebase, pusher doing lightweight data & realtime updates
  • newrelic is doing deep resource tracking
  • geckoboard is doing dashboards
  • heroku is doing processs/service hosting, relying on a bevy of partners including many of the above for slices of value

There are lots and lots (and lots!) of new entrants that are following this paradigm, and from a developer’s point of view it’s both exciting and daunting.

Exciting because in the right combination, these services can be combined to deliver incredible scale and agility even to very, very small teams. (I have a fantasy of someday figuring out how large a 10-person project can be. It’s pretty large).

Daunting as well, because while when they can work well together in an app, they really should be thought of as independently moving (and failing) parts. And you’re likely not going to understand them as well as you should, or as you would had you built them yourself.

Which leads me to a friday-afternoon prediction: that there will be, over the next few years, a few companies who become experts at solving the coordination problems that arise from assembling so many disparate slices of value into an offering (whether for developers, or clients, or internally). And I expect that this expertise may not be purely technological.

I’ve seen how deep one has to go to get a real understanding of the security and privacy implications of relying on a third party for handling user data; I’ve seen the horrendous chain of dependencies that emerge out of security vulnerabilities; I’ve gotten a glimpse at the regulatory issues which some (soon more) folks will have to face. Dealing with high availability, geo-distribution, etc. all result in systems whose complexity scales in scary ways.

This leads to two thoughts:

  • If I were a wise investor, I’d look for those folks who look like they’ll find ways to integrate value in coherent larger slices, or mitigate the pain.
  • As a “product person”, I probably want to work on problems that require only a few slices, done well.

Said like that, I do get a “nothing new under the sun” feeling. Oh well, it’s Friday. MFBT.