The New Framework Discussion (Part One)

mikeal posted "A new direction for web applications" And I left the following comment.

I agree about MVC is not the right fit. For me it breaks down even for Rails with JavaScript on the client. Model is database term that does not fit async data. RESTful is certainly part of the mix as are other HTTP inputs and IP streams. These don't fit the model analogy either. 

The "new" framework is probably much more of a mosaic than a flow (or flowchart). Not certain how well the neighbors (parts of the mosaic) know each other. Probably some zoning laws, but everyone is able to do their own thing (except after midnight) so long as certain ordinances are not broken. 

My other thought is that these new apps are much like a room full of people. Conversations between a few people are great. Lectures work. But getting a room to act together requires something like Roberts Rules of Order. 

Writing internet code is certainly has a long way to go.

I wanted to expand on that post and comment about the New Framework. I think there are several influences shaping its development.

1. Async. The first big push was Ajax. The latest is node.js. Data no longer has a flow or a sequence, it is more quantum. REST is the structure for async.
2. Speed. Look at the popularity of Steve Souders and Nicholas Zakas talks and books on speed. I hope the new framework fits the techniques they and others are discussing. For example, fewer requests doesn't always play well with frameworks that generate lots of directories and files.
3. Events. Even a small app has a population of events. The new framework must provide a logical structure to these events.
4. CSS, HTML and JS. Most of us work with all three. For example, what use to be in JS is now often in HTML5. The new framework will have to consider all three.
5. History. Presenters are going back and looking at the development of other technologies and looking for good patterns. Douglas Crockford was looking at the transition from manuscripts to books in his talk at CapitolJS. This search is common for any new technology. Marshall McLuhan showed that a new technology retrieves an older technology. It will be interesting to see what is retrieved by the new framework.
6. Testing. Of course.

You can probably argue that there are other forces at work here. For example, I could argue pro and cons of templating. 

I'm sure someone is working on the new framework right now, it is "just now well distributed" yet.

CapitolJS 2011 [#JSConf East and #capjs]

One attends a JavaScript conference to learn how to use the language better. The conference is not intended to teach the beginner. There are assumptions of a working knowledge of the language, probably extensive experience in coding and an interest in node.js. However, I think there were themes or lessons in the presentations at this conference that would help any JavaScript developer.

The future of the language is amazingly bright. Mike Taylor showed that even though the browser Navigator has very unreliable properties that the future new properties (e.g., online, geolocation, etc.) hold great promise. Pamela Fox had example after example of APIs that JavaScript can access for functionality, public data and user data. And Brendan Eich demonstrated the work that Intel has done to access parallel-processing power with an engine called RiverTrail (on github) [Infoworld article][http://www.infoworld.com/d/application-development/intel-river-trail-adds-parallel-dimension-javascript-173347].

Performance in JavaScript is now in the hands of developers now. Nickolas Zakas promoted the use of both defer and async for script loading. So testing must include performance testing with no action taking longer than 100ms. This is the max for a responsive system. Alex Seston also emphasised the need for non-blocking code while on the topic of third party JS. Alex Russel went deep into working web engines in browsers so coders know what is behind some simple DOM changes.

JS, the programming language of the web, is amazingly rich. Douglas Crockford looked at how we code from the viewpoint of Head and Gut (see book Science of Fear) and how the Gut often gets in the way. Using tools and the good parts of the language (language subsetting) we can use our Head more and produce less errors. "Programming requires more precision than writing in English." Language conventions take time. For example the line breaks and spacing introduced by Medieval manuscript copyists. This language history perspective was echoed in Mike Taylor's talk and emphasized by Brendan Eich in noting how young the language is. It is mindblowing what the JS community can code in 140 bytes on Jed Schmidt's site (http://140byt.es.com).

Growth is in mobile and it effects all. Rebecca Murphey showed the new toura mulberry framework for creating content rich mobile apps built atop phonegap. http://toura.github.com/mulberry/ Joe McCann works in the mobile area and provided a comprehensive view of both coding and using node.js with Express, Stylus, Smoosh, and Commander as tools for creating any app. it is clear for the Head to win over Gut that automating tools are needed.

Node.js is still growing. Mikeal Rodgers ran down the most popular packages for node including npm, optimist, request and of course socket.io. But there is still room for improvement, especially in debugging. And again, node was mentioned by most presenters. Ben Combee showed how to access the node running in webOS and stated that webOS will soon be updated to version 0.4.11. Paolo Fraqomeni talked about how the design of node is especially suited for the enterprise and the event emitter.

As I see them available, I'll link to the decks for each presentation.

Douglas Crockford
Ben Combee
Nicholaz Zakas
Mikael Rogers
Jed Schmidt
Mike Taylor UPDATED
Rebecca Murphey
Alex Sexton
Alex Russell
Joe McCann
Paolo Fragomeni
Pamela Fox
Brendan Eich UPDATED

The conference was terrific not only because of the speakers but thanks to the work of my friends Laura and Chris Williams. Also because of sponsors there was time to network at parties both before and after the event.

Thanks. A wonderful community.

UPDATE: Group Photo

Distinction between sites and apps is RSS

James Pearce wrote a substantial post about the distinction between sites and apps. He says the distinction matters only to developers and not for users. I think there is another measure of the distinction than his fat versus thin client. This is my response. 

The distinction is only relevant, as you say, for developers. The reason is simply because "interface is content." Or perhaps put another way "interface is the message."

Take some content and provide a simple HTML interface. Put the same content in a JS/CSS3/HTML5 interface and the message is different. People will "read" it differently and have a different user experience.

So the distinction becomes blurred in my view as soon as you cross the pure HTML line. Ask yourself at what point does adding JS/CSS3/HTML5 take the content from site to app? I suggest there is not a brightline using that (ie. fat client) as a measure.

However, there may be another measure. Again, it may not be a brightline, but it does help.

Sites can support an RSS feed while apps don't. 

---

Let me add to the comment that I left.

The post argues that the distinction fat versus thin, that the code resides on the browser versus the server. It also argues that users don't care.

First, take the New York Times or any newspaper or news source. Does it really matter if I read the story in an app or off their site? They support RSS so I can read the story on other sites, in RSS readers and apps that support RSS.

Then take an app like Pulse or other news apps. I can read an MSNBC story with the app or on the MSNBC site. But I don't find Pulse stories on MSNBC. Pulse cannot support an RSS feed because it does not create stories.

So I would argue that the user experience between the Pulse app and the New York Times app is substantially different because the users know the source of the content. Therefore, as a developer, you'd design the app to the user expectation.

Now that is a simple, legacy example.  Let's add some web features. Many sites, not just news sites, all users to comments. Comment systems support RSS feeds or other notification methods (e.g., email).  Certainly comments are not an app.

More modern day are sites like Quora. The content is not news stories but there is new, relevant content. They use the headline of "Feed" on the main page. Clearly Quora is a site.

And finally, let's look at the classical app: the todo app. Put a todo app on any smartphone for personal use and all of the generated content can stay on the phone. It would be a useful app without any interaction with the internet. Even if you sync the todos with other devices which would require servers somewhere, the bulk of the app in on the phone. But more importantly the data source is on the phone. You could sync with RSS (or a JSON equivalent) but is that feed really useful for the public? It is core to the purpose?

In summary, you've got a site when the content supports a RSS feed. The purpose of an app is confined to the device. The distinction my not matter to developers, but user know when a site can support an RSS feed, even if they don't know what RSS is.