A year later, I have some more refined ideas. The fragmentation of mobile platforms means that open web technologies are the only way to deliver applications across the spectrum of telephones, tables, televisions and what have you, without incurring the pain of multi platform development. The types of applications that are most interesting to me are highly interactive with low latency user interfaces – note that I am intentionally avoiding the use of the word “native”. Demand for these applications is going to raise the bar on the skill sets of web developers. I think that we will see more applications where the bulk of the interface and logic are in the browser, and where the server becomes a REST API endpoint. The architecture of “New Twitter” is in this vein. API endpoints have far less of a need for HTML templating and server side MVC frameworks. But those low latency applications are going mean that servers are doing more asynchronous delivery of data, whether that is via existing Comet like techniques or via Websockets (once it finally stabilizes). Backend systems are going to partition into parts that do asynchronous delivery of data, and other parts which run highly computationally intensive jobs.
I’ll save the discussion of the server parts for my Nodeconf writeup, but now I’m ready to report on JSConf.
Here are some of the talks that I found interesting or entertaining.
It’s been a while since I looked at Bespin/Skywriter/Ace, and I was pleased to see that it seems to be progressing quite nicely. I particularly liked the Github support.
Unfortunately I missed Andrew Dupont’s talk on extending built-ins. The talk was widely acclaimed on Twitter, and fortunately the slides are available. More on this (perhaps) once I get some time to read the slide deck.
Mark Headd showed some cool telephony apps built using Node.js including simple control of a web browser via cell phone voice commands or text messages. The code that he used is available, and uses Asterisk, Tropos, Couchbase, and a few other pieces of technology.
The big topics
The last two talks of the conference were also focused on the topic of JS.next.
The last talk was given by Alex Russell, and included a triple head fake where Alex was ostensibly to talk about feature detection, although only after a too long comedic delay involving Dojo project lead Pete Higgins. A few minutes into the content on feature detection, Alex “threw up his hands”, and pulled out the real topic of his talk, which is the work that he’s been doing on Traceur, which is Google’s transpiler for experimenting with JS.next features. Alex then left the stage and a member of the Traceur team gave the rest of the talk. I am all in favor of cleverness to make a talk interesting, but I would have to say that the triple head fake didn’t add anything to the presentation. Instead, it dissipated the energy from the Brendan / Jeremy talk, and used up time that could have been used to better motivate the technical details that were shown. The Traceur talk ended up being less energetic and less focused than the talk before it, which is a shame because the content was important. While improving the syntax of JS.next is important, it’s even more important to fix the problems that prevent large scale code reuse and interoperability. The examples being given in the Traceur talk were those kinds of examples, but they were buried by a lack of energy, and the display of the inner workings of the transpiler.
If your interests are different than mine, here is a list of pointers to all the slides (I hope someone will help these links make it onto the Lanyrd coverage page for JSConf 2011.
Hi Ted, thanks for the writeup. One thing I wanted to record, which is in my blog post on JSConf:
Ecma TC39 is *not* doing “design by committee”. We are codifying (with cleanups) _de facto_ standards where we can. Where the language needs new semantics, e.g. modules, the designers are individuals and pairs of TC39 members.
More important: browser vendors prototype the draft standards that reach “Harmony” status and are slated for inclusion in ES.next, so you will not have to wait three years to use these features.
This is how HTML5 and many modern CSS and Web API (DOM) features rolled out — as draft standards with coopetition-driven implementations among the agile browsers.
Yes, IE was slow to catch up. We’ll see how that plays out with rolling IE10 preview releases and Microsoft’s diminished browser market power.
Between transpilers and rolling prototype-to-final implementations, JS changes should come out quickly. Not as fast as Python evolution on the best days, but comparable.
The debugging hardships of cfront (I remember it too well) and similar translated languages are being addressed. CoffeeScript is “just syntax” so it lines up line numbers where it can.
And more important, we at Mozilla are working on primary-source line and column number mappings for debuggers. I think the V8 folks are interested too.
CoffeScript libraries are unlikely in the wild, but Rails 3 bundles CoffeeScript and makes building super-convenient, and IINM also makes view-(primary-)source work (fetching the .coffee file instead of showing you the compiled .js).
Actually I am clear that TC39 is not doing design by committee – I’m sorry that my wording makes it sound like that.
On the whole I am happy with the direction that things are going in.
Pingback: JSConf and NodeConf - 2011 | Adam Christian