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.

9 thoughts on “Ruminations on front end-centric webapps

  1. Great articles David. The advent of Dropbox to me was quite profound and I’m not at all surprised to see the surge of publishing platforms that leverage it. The benefits of separating the front-end and back-end of applications is something that has been well understood since the early unix days and it has been somewhat surprising how long the web has gotten away with not following this paradigm in a significant way. In any case, it’s going to be interesting to see how far people push this approach.

    • david

      Yeah, I should have mentioned that the Unhosted folks have been arguing for this kind of architecture for a while, but having the idea for the architecture is less impactful (to me anyway) than having actual real working pieces in play.

  2. This is all great stuff. I’m especially excited about things like Firebase and Meteor that let you set up a single-page site quickly on a static server, but still have a database component. Some of the CouchDB services do this, but not as conveniently, or with update notifications (AFAIK).

    I’m also really happy to see CNAME support happening more widely on platforms like Dropbox, Github, and S3. This list of missing pieces is growing smaller, but I’ll note a couple:

    * SSL Support. If a domain could make this one-click, that would be huge progress for the web

    * Mime Types. If you are serving up mobile webapps, you really want the .appcache file to have the right mimetype, and other uses are equally finicky. Great if github et al Just Work and serve files with the right types by default, but in cases where they don’t (and there are new cases all the time) it is nice to have .htaccess or something like it to provide an over-ride.

    I can’t really think of much else that is missing, at first glance. I wonder what pieces of the web stack other folks will miss.

    • david

      Hi dethe –

      site44 has mimetype handling fairly easily (also note a trick I came up with: by using 404.html instead of index.html you can easily handle all URLs =).

      Firebase requires & offers https; meteor makes it possible (and I assume but don’t know that their hosted service supports it).

      I’ve run into some edge cases w/ Firebase for example where it’s not clear how to get them to support wildcard subdomains, but that’s an esoteric use case.

  3. “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.”

    I think the ease of deployment, making publishing online as easy as saving to a filesystem, means webmaker skills become as important as basic word processing. None of the things you listed are WYSIWYG tools, they’re all targeting skilled webmakers that don’t necessarily have sysadmin chops. People sometimes question web literacy without server admin skills, but tools like these provide a lot of horsepower to people that invest in the core web making skillz.

  4. This new mental model is very exciting. The tools are still a bit too immature for me though (I’m no early adopter). The issue of single-page apps not being readable by search engines is probably the #1 sticking point. AirBnB and Twitter’s frameworks seem to solve a lot of the issues, so that’s very exciting.

  5. Hi David,

    The 404.html trick is great. The History API is great for storing state in various URLs, but I was wondering how a single-page static site would handle those different URLs as targets. Very cool hack.

  6. Mark Surman

    I agree w/ Boris and Chris: there is stuff in here even for people just starting with ‘the basics’. At least, there is if they want to get to making a ‘real thing’ quickly. Ie. a thing that’s ‘sitey’ in that it doesn’t just live in Facebook or YouTube. Also, architecturewise, I think there is alot to learn here from what we do w/ our Webmaker toolset in the realm of storage and publishing. I’ve been saying we should look at Dropbox for storage for a while now.

Comments are closed.