JeffreyBarke.net

My live notes from John Hann’s 25 August 2010 presentation on modern JavaScript frameworks to the New York JavaScript meetup.

Modern JavaScript frameworks rock! Dojo, jQuery, MooTools, Prototype… alleviate us from browser quirks so we can concentrate on coding awesome web sites. But none of these offer any guidance whatsoever—and hardly any tools—for building enterprise-worthy, ultra-rich web applications. It’s just too easy to create inflexible, unmaintainable spaghetti code.

A few Javascript-based, in-browser Model-View-Controller endeavors have popped up to help provide solutions. Most of these are simply rehashed server-side MVC frameworks. They just don’t get it. MVC sucks for web development. The bigger the project, the worse it gets.

Cujo.js was specifically designed to eliminate these inter-dependencies. Yes, it’s an MVC framework, but it’s different…

The above slides are from a presentation on Cujo.js, but are not the slides to this presentation.

cujo.js: A sneak preview

John Hann
@unscriptable
lifeIMAGE, Inc.

cujo is about building ultra-rich web applications.

What is an ultra-rich web app?

• Feature-rich
• Single-page app (“spa”)
• Desktop-like
• You “live” in the app

Examples: lila^™ Inbox, meebo, Gmail, Google Docs, Facebook

Why would anybody want to build a spa?

• Responsiveness
• Mobile (HTML5 apps, Phonegap)
• Cross-platform
• Vendor-agnostic
• Auto-update
• Offline
• More responsiblity to client (more clients), less for server (fewer)

The rise of the JS libraries

• Prototype
• Dojo
• jQuery
• Mootools
• Mochikit

Why JS libraries?

• Browser abstraction
• Language abstraction
• Plugins, components, widgets

All the node-wrangling tools to build all ultra-rich applications.

However, 5,000 lines of tangled JavaScript later, what the heck happened?

It’s your nodes, dumb-ass. Stop fiddling with your nodes! Building an ultra-rich app requires software engineering.

We’re building desktop applications on the web.

Why can’t I just fiddle with my nodes?

• Bigger app
  • More complexity
  • More code
  • More coders
• Complicating factors:
  • Customization
  • il8n/L10n
  • Authorization
  • Animation

How to uncomplexify?

• Modularization: “Think tiny”
• Encapsulation: Don’t touch my coadz
• Loose coupling: I won’t touch your coadz
• Reuse: Don’t repeat yourself
• Separation of labor: Mind your own biz

Does $() help?

It doesn’t

3rd-party solutions help Dojo and YUI do more than jQuery, but not enough.

Don’t believe me?

Does $().fn help modularize my CSS?
Does dojo.connect() protect my code?
Does $().live respect my widget’s personal space?
Does $.extend help me reuse HTML?
Does $.animate coordinate nicely with my CSS designer’s CSS files?

Animation is not behavior—belongs with designer (CSS3 transitions)

Cujo is built on Dojo.

Dojo MVC?

models, views, controllers…

Why is cujo.js moar?

Data flows magically between nodes & server.
Template languages disappear (and so does the ID attribute!)
Views invoke the …

Dojo 1.6 data stores are hawt!

Data stores are data models. Most handle client-server communication so you don’t:

• json
• json-rest
• couchdb
• flickr
• google
• csv
• xml
• atom
• etc

Data binding provides the “last mile.” (Dojo 1.6 will provide data binding). The end result: “live” data. As live as you want it, anyway.

What template language?

Why use a {{template language}}? HTML5 data-* attrs FTW!

inheritance: data-cujo-override
loop*: data-cujo-iter
conditional*: data-cujo-if

“oohtml,” anyone?

The “holey” web trinity

oojs + oohtml + oocss => cujo.mvc. View complete module, yet still overridable.
my/HawtWidget.js (aka “view-controller”):
dojo.provie(‘my.HawtWidget)
cujo.requireCss()…

Ancient browsers grok CSS2.1 & CSS3

Once you take control of the stylesheets, the sky is the limit.

Ever wish this worked in IE6?

• Two selectors (chained) on an element: .myWidget.selected
• child selectors
• Transitions

Moar modularization

JS, CSS and HTML as a single unit is easier to create, test, maintain and extend.

dojo.provide('mgp.view.logo');
cujo.requireCSS('mgp.view.Logo');
cujo.requireHtml('mgp.view.Logo');
dojo.require('cujo.mvc.View');
dojo.declare('mgp.view.Logo', cujo.mvc.View, {…

Moar encapsulation

Self-contained, “black boxes”

Minimize cross-dependencies.
cujo.js mixins FTW!
cujo._Connectable limits dojo.connect()
cujo._Settable limits dijit’s set()

Moar loose coupling

It’s good to be loose and ignorant of your own parents! Cujo emphasizes:

• doj.connect
• dojo.publish/dojo.subscribe

Moar reuse

Just say no to copy-and-past coding practices.
Increase maintenance
cujo.js embraces OOJS and OOCSS.
Adds OOHTML
OOHTML enables OOCSS (automatically applies inherited classes)

Jon Hann gives a strong endorsement of OOCSS. Learn it

Moar separation of labor

$.css() and $.animate are the CSS designer’s job. Layout is also the CSS designer’s job.

Get over it.

Moar about view state

Classical OO inheritance: Descendant classes inherit attributes and behavior.

Pure prototypal inheritance: Descendant objects inherit attributes and behavior.

OOCSS: Descendant objects inherit attributes and run-time state.

When can I haz Cujo.js?

Cujo.js is in stealth mode while we test moar browsers, finish features, document and clean-up code. Release 0.1 on Github around 15 September 2010

http://cujojs.com/
http://twitter.com/cujujs

Q&A

Q: Some people think these frameworks proscribe too much.

A:Possibly went too far the other way. Can define and extend. Theming. Don’t want to use the templating language, can pull in your own.

Q: What is the performance overhead?

A: Two aspects: load-time. Actually processing CSS at load-time. Do a lot of feature detection, not browser-sniffing, so difficult to do that build time.

Q: You mentioned how Facebook was different in the beginning?

A: FB only loads 3KB of JS and that 3BK is responsible for loading and running the rest.

Notes from John Brooks’s (The Knot) presentation on the HTML5 WebSocket API to BK.js, the Brooklyn JavaScript meetup.

HTML5 WebSockets

Full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in HTML5 compliant browser.

• Stuff will change
• I want stuff to change
• I want changed stuff to be cheap

So it’s like Comet and Ajax.

Unlike WebSockets, Comet and Ajax are not native to browser and rely on maintaining two connections—one for upstream and one for downstream.

WebSockets are really simple.

Well, technically XHR is native to the browser, but with WebSockets, avoid headers and multiple requests.

Current state of things:

• Polling

WebSockets will reduce traffic and overhead.

var webSocket = new WebSocket('ws://172.16.3.86:8080/time');
webSocket.onopen = function(event) {
     document.getElementById('element;').innerHTML = 'Waiting for socket';
     webSocket.send('start');
}
webSocket.onmessage = function(event) {
}
webSocket.onclose = function(event) {
}

What do you do when a browser doesn’t support WebSockets? Can fake it with Flash and Silverlight.

Current browser support for WebSockets: Chrome

Things are a little different on the server-side; server will need to become event driven. Node.js.

Questions and Answers

Chrome 6 broke backward-compatibility with Chrome 5 WebSocket support. Chrome 6 seems to be the reference implementation.

What is security? Port? Same origin policy? Port 80.

Firewall issue is why some people are pushing for TLS.

Google SPDY protocol brought up. Similar to HTTP, but a different protocol. Will it be blocked or dropped?

SPDY permits multiplexing, but faces the same problem as all protocols based on TCP/IP.

HTTP permits six connections and is faster on page load. SPDY gains performance on other issues (multiplexing and …)

Notes from Andreas Grabner’s (dynaTrace evangelist) presentation on the new features of the upcoming dynaTrace AJAX Edition (DAE) 2.0. dynaTrace AJAX Edition is a free tool that provides full JavaScript, network, rendering, DOM and XHR tracing for Internet Explorer 6, 7 & 8. With the latest version, the Ajax Edition automatically analyzes best practices in the areas of browser caching, network resources, server-side activity, JavaScript/Ajax and also provides additional key performance metrics that are essential for tracking the end-user perceived performance of a web site such as time to first impression, time to onload or time to fully loaded.

NY Web Performance Meetup page

Please note these are my live notes and were published immediately after the presentation. Hopefully I’ll have a chance to clean up them up at some point in the future.

Presentation bottom-line: Coming ASAP.

dynaTrace was founded in Austria five years ago. Headquarters in Boston. Started on the server-side. Large clients moving to Web 2.0, so developed dynaTrace Ajax Edition as a free tool. Version 2.0 is in beta, but that is the one that should be downloaded.

Currently works with IE 6, 7 and 8 exclusively. Will hopefully support FF by the end of the year.

Mike Taylor from Tunecore's presentation on using JavaScript to give older browsers new fancy. Mike discussed the tenets of regressive enhancement and then demonstrated how to apply them using HTML5 forms and three jQuery plugins he wrote.

This talk is about the future of HTML and front-end development and ways in which we can plan for the future.

HTML5 (and friends)

• New semantic elements
• Canvas 2D context
• Microdata
• Cross-document & channel messaging
• Forms
• Web workers
• Gelocation

Talk is not about progressive enhancement, but regressive enhancement. This "philosophy" embraces:

• Build native experience
• Feature detection
• Back-port functionality for crappy browsers
• Wait for your code to become obsolete

What's problematic about the new semantic elements?

Won't render correctly in older versions of FF and IE (6–8). There's a solution for this, but it relies on JavaScript (Remy Sharp's HTML5 shiv.

Print style sheets won't work in IE. The solution is IE Print Protector. This has been included in Remy Sharp's shiv.

What's problematic about the new HTML5 form elements?

[Mike does a quick demo of the new form elements. You can see that demo here.]

Mike shows the new placeholder attribute: <input placeholder="Ye olde placeholder" />. No need to do hacky script work-arounds anymore.

On to the presentation

Modernizr FTW!

A way to extend Modernizr [I missed the URL].

Mark Pilgrim's Dive into HTML5 has a "guide to detecting everything."

Back to the placeholder attribute. Mike shows some code he wrote to regressively enhance browsers that don't support the placeholder attribute. Uses jQuery to create and position labels off-screen. This does not replace the existing label element, but it adds another label element. The spec clearly states that placeholder is not a replacement for labels. [Would like to actually examine Mike's code (it's a jQuery plugin); I think he's going to post it or send it to the list. It's at Github]

A discussion about styling HTML5 elements. Some people think it's good to be hands-off here. A return to the debates around the file input.

Then Mike turns to the autofocus attribute. Simply a boolean attribute. <input autofocus /> He has a nice jQueyr plugin for this as well.

The last thing we'll be looking at is the datalist element. There are some interesting things necessary to make this work cross-browser. Webkit freaks out on naked option elements, so you have to wrap the options with a select. However, this causes IE to render a select. Gecko doesn's care either way.

Mike created a cool jQuery plugin for this as well. However… Safari 5 lies, because it says it supports the list element when it doesn't. This has broken Mike's working, cross-browser plugin.

But…

Regressive enhancement is kind of a hack. Things can get broken.

Mike's code is at Github

Dean Edwards has a JS library for HTML5 forms that does all of this. It's beta, so we're not supposed to talk about it, but it's a public link on Google Code, so I'm blogging it. Remy Sharp is working on a JS work-around for local storage.

A discussion ensues

Is this good in terms of code maintainability? Is it worth it to invest in this? Why not wait for all the browsers to natively support these things? Where are the big wins? Multiple background-images are win, but are the new semantic elements really worth it?

Actually, have to be careful with some of the libraries and some of our existing "hacks." Some CMS or framework hijacked the required attribute awhile ago and didn't do feature detection. Now that the attribute is part of the spec and is getting implemented, that CMS or framework has produced a broken website in modern browsers.

One advantage of using native browser functionality is that you don't need to test the new form elements in the new browser. The date picker input will just work.

Back in August, Dave Shea came up with the CSS Sprites2 technique in A List Apart No. 266. He chose to implement it in jQuery, but added "consider this article an open invitation to port this technique to your library of choice." I intended to immediately port CSS Sprites2 to Prototype and script.aculo.us, but finally got around to it this weekend.

My version of CSS Sprites2 is almost exactly the same as Dave Shea's: it requires the same HTML, the same styling and includes a similar pre-built function used to invoke it. However, my version also includes keyboard support: there's a matching focus, blur, keydown and keyup event handler for each mouse event handler.

Get CSS Sprites2 for Prototype and script.aculo.us.

The New York Web Standards Meetup Group will meet this Thursday (28 August 2008) at theMechanism at 7:00 pm.

Margaret Michele Waldman (Sovereign Sites L.L.C.) will briefly discuss Ajax and present a number of coding variations, including rolling your own, using a JavaScript library and using Xajax. The examples will demonstrate how to consume XML, HTML and JSON.

Prior to the discussion, there will be a brief period for announcements. Afterwards, there will be an optional "show and tell" session. Show off sites you’re currently working on and get design feedback and technical assistance.

28 August 2008 . 7:00 pm
theMechanism
440 9th Avenue 8th Floor
New York, NY 10001 [map]

RSVP now!

Please contact theMechanism if you'd like to present at the October or November meetup.

Notes and links from last night's Google I/O review at the New York Web Standards Meetup Group. Thanks to everyone who made it!

Note—There's a "curated" selection of Google I/O videos on this blog tagged io2008.

PowerPoint presentation

Demos/tutorials

• Gears
• Google AJAX Feed API

Advanced Gadget and UI Development Using Google's AJAX APIs. Derek Collison (Google)

The Google AJAX APIs can be used to build sophisticated Gadgets and UI controls for your website. For instance, you can by-pass complex server-side proxies and mash up feeds directly with a few lines of JavaScript using the Feed API. In this session, we'll dive into advanced uses of the raw Feed and Search APIs. We’ll also show you how to use Google's new Language API to broaden the global reach of your web applications.

Participants should be familiar with JavaScript and dynamic Web applications.

Presentation slides (PDF)

Source: YouTube

The New York Web Standards Meetup Group will meet this Thursday (24 July 2008) at theMechanism at 7:00 pm.

Google I/O was a two day developer gathering in San Francisco, 28–28 May 2008, which covered building the next generation of Web applications with Google and open technologies.

I attended and will talk about what I learned there, specifically focusing on Gears, Google App Engine and the Google Ajax APIs. Prior to the meetup, you can read a bit about my experience at theMechanism's blog and watch some of the videos I've gathered here.

24 July 2008 . 7:00 pm
theMechanism
440 9th Avenue 8th Floor
New York, NY 10001 [map]

RSVP now!

Please contact theMechanism if you'd like to present at the September or October meetup.

State of Ajax: The Universe is Expanding. Dion Almaer (Google) and Ben Galbraith (Ajaxian.com)

The Ajax revolution is complete: sophisticated JavaScript user interfaces are nearly ubiquitous. Yet, the innovations in the Ajax community continue. In this session, Dion Almaer and Ben Galbraith, the founders of Ajaxian.com, discuss the latest Ajax developments, including multithreaded JavaScript technology-powered UIs, robust offline storage, choosing the right Ajax/JavaScript technology framework, Ajax outside of the browser and more. They use plenty of examples and a bit of live coding for dramatic effect. Come and learn how to use the latest technology to make your web applications sizzle. And, see if your heckling can throw them off balance!

Presentation slides (PDF)

Source: YouTube