Future Of Web Apps - Two Themes
Future Of Web Apps
Obviously there is going to be a lot written about FOWA, and there is also a collaborative Google doc for notes from the talks. At smaller events I've been to do a comprehensive write up, here I thought it would contribute more if I picked out what I thought were the two key themes.
App Architecture and reducing barriers to making apps
On the distant horizon, somewhere far off, is the prospect that building a web app might one day be as easy as running a blog is now. At the moment it's still a very technical process, but it's noticeable that the off-the-shelf tools are getting better very quickly. GitHub and Heroku (who were both represented at FOWA) make a professional workflow easy to set up without too much overhead, and I personally absolutely love the Cloud 9 IDE (http://ace.ajax.org) too - though clearly you need some programming skill to make use of them.
On a deeper level, the MVC / ORM / CRUD acronym pile up seemed to be a ubiquitous approach to development in FOWA talks. Google's Alex Russell talked about the future of Javascript and referenced the above ideas heavily, while with Chad Pytel and Alex MacCaws' respective Backbone and Spine libraries had a similar emphasis. Although these talks are about the client side, they are all clearly inspired by Rails (and similar frameworks) on the server side. No matter the environment, everyone is converging on a very similar modus operandi for writing apps.
I think this emergence of a standard structure is potentially extremely valuable. Firstly, it means there is less stuff to learn, and fewer decisions to take. Secondly, I hope that it might be possible for these (relatively intuitive) ideas to permeate into non-technical circles, just as CMSs like wordpress allow websites to run by non-technical users.
I had a great chat with @sjhewitt, who tells me that there are some simplifying graphical solutions for app building using Unified Modeling Language and the like - he also suggested they were pretty unsatisfactory.
What we came to was the idea of using Sifteo style interactive tiles to represent relationships between data and build your app. You could shuffle them about and link them to indicate models and views etc. I haven't thought much about how plausible that would be, but I do think that handing users the ability to make their own apps could be very powerful - perhaps http://ifttt.com/ is the tip of the app building iceberg. I also love the physical metaphor, any non-nerd would find this a much easier approach, I would guess. (Caveat - graphical programming languages like Max MSP seem to be very difficult to learn, at least to me.)
Another architectural trend that could lend itself to this style of home-spun development is the strict separation between client side and server side. Many of the development strategies that were discussed assumed that the back end worked as an API, delivering JSON data to the client which then builds an interface that a human can understand.
If the owners of these sites wanted, they could allow other people to use their back end API. In theory it would be quite easy to build your own bespoke business software (or the like) that integrated a bunch of existing apps without really understanding very much about them. Imagine all that ball-ache work that takes up half of everyone's day that could be automated away - I'm thinking of the "get the stats from Google Analytics, put them in excel, format them, attach them to an email, send them to the client and save them to the server" type repetitiveness that no one needs to be lumbered with.
If you'll forgive me a hand waving explanation of what I'm thinking about, I'm imagining something similar to the linked data concept only for actions rather than data (as discussed in the bar with @TonyTo85).
I'm not naive about this - I realise there are both problems with the technology and the economics of the this conception of how the web might evolve, none the less it's interesting to think about.
Boring but (possibly) important: the cloud
The cloud and the browser as an operating system also came up a lot. Mozilla talked about their toolbar API which will allow apps to take over more of the browser. Microsoft's Azure platform was heavily promoted (did you know you can run anything you like on it? Like PHP, if you want? I didn't.) There were presentations about building games in HTML 5.
I find it hard to get excited about this stuff. Clearly it's happening, and everyone is moving in the directions of having more in the cloud/browser and less on your local machine. If I'm honest though, I heard very little new on these topics. Moreover, while these are clearly important improvements to the ergonomics of the web, I'm not sure if things like removing the tool bar from the browser window represent a structural shift.
The most important thing that I'll take away from FOWA is the amazing demystifying power of watching someone demonstrate something on stage. SASS, HTML 5 local storage, HTML 5 history API and the backbone javascript libraries are all things that I know of, but I've not bothered to investigate because I've been intimidated by the learning curve. Just seeing someone on stage give a quick demo made all these technologies approachable.
Finally, as someone who's very interested in ubiquitous computing, I couldn't help be impressed with the computerised room scheduling and IP addressable lighting system in the venue. I couldn't help but feel we should have linked the colour of the lights to the mood of the Twitter stream or something.
Compared to other conferences I've been to FOWA is very much focused on practical development issues as opposed to marketing stuff or (too much) on getting funding for your start up. That means I've come away with a load of new tech stuff to look at - so big thanks to the FOWA crew!
Stop Press - Scott Chacon GitHub talk
I wrote most of this before the final talk from Scott Chacon at GitHub. It was phenomenal. Among much else, we learned GitHub have no holidays. They don't have holidays because they don't monitor work hours, if you don't feel like going into work you don't have to. To summerise the essence of the talk, what this means is that everyone who is at work at GitHub is there because they have chosen to be - which obviously means they are very motived and creative while they are there. Egro GitHub has an amazing website. As Scott Chacon pointed out, most people who are good at their jobs wouldn't just down tools if you stopped making them work. There is a natural tendency to want to make great things.
It's bascially how a work environment ought to be, and I think it's model that could be copied much more widely. As I write this Scott has a gaggle of admireres round him.
And. And they have a command line app which delivers beers to empoyees with a robot. I'm not making this up.
