Something I thought was very interesting was the thoughts (augments) around pure single page apps vs. progressive enhancement. I think Yehuda almost flat out said its too much work to do progressive enhancement. (rendering views / view partials on the server)
Progressive enhancement I think has really become a law of moses in recent times, probably mainly due to the speed in which browsers have progressed, and the powerful browsers on all modern phones - it just isn't practical.
To be honest, I think having your app work without javascript these days is a little naive view about the future of the web. Javascript is here to stay and not that many people will be on non javascript powered browsers.
Which also persuades me to really care even less about the semantic web. Twitter bootstrap is a good example - it really is DIVitis, but really who cares? its rapid application development, it make the web look and act far nicer and more consistent, and it progresses the web as a platform.
Having your web app still work (through non Ajax'd GET, POST etc) for the 7 seconds it takes to download the javascript just isn't worth it - especially with html5.
Unless your web application happens to actually be a series of <form>s, your JavaScript probably starts to become your content. To use an example from today, how would one go about building this without JavaScript? Without losing the heart of it in the translation to static HTML?
@jashkenas: Could you expand a bit about your thoughts on the growing ecosystem of community made patterns and modules on top of Backbone and how it might help direct [edit: 'help direct' is the wrong phrase, can I change this to shape?] the future of Backbone?
Backbone has always been intended to give you the smallest possible set of functionality that you reach for every time you work on a JS-powered web app. Model and Views and events to bind them together, collections with powerful functions for filtering and aggregating data, and shareable URLs.
There are lots of other directions and other needs that JS apps may have, but unless it's something that you're going to use pretty much every time, it doesn't belong in Backbone itself -- it belongs in an extension, or better yet, another standalone library. I'm talking about things like write-through localstorage caching, pushing data over websockets, TreeViews, query syntax for complex JSON, special cross-domain communication, specific HTML-generating strategies, or "mobile" widgets that mimic iOS controls.
Fact is, JS apps are still the wild west when it comes to patterns that work well -- there are plenty of fertile experiments to go around. You want a library that gives you a foundation, so that your app can rise up to meet it and extend it in new directions. I think that pretty much all of the apps in this list fit that description -- going far beyond what Backbone provides out of the box:
For folks who don't have time to listen: The general topic was JavaScript Web Apps, as viewed through the lens of what Backbone and Ember agree and disagree about, specifically:
* Source of truth.
* MVC / MVVM / MVP / The model-ui spectrum.
* JavaScript pipe dreams.
* Arbitrary code vs. structured templating systems.
* Everything-is-public APIs. +Hooks
* Client Side Models are not mirrors of Server Side Models
Well, if you get a bunch of nerds talking about javascript MVC frameworks for an hour, there is bound to be some pedanticism. Despite that, I love this podcast.
[+] [-] lukeholder|14 years ago|reply
Progressive enhancement I think has really become a law of moses in recent times, probably mainly due to the speed in which browsers have progressed, and the powerful browsers on all modern phones - it just isn't practical.
To be honest, I think having your app work without javascript these days is a little naive view about the future of the web. Javascript is here to stay and not that many people will be on non javascript powered browsers.
Which also persuades me to really care even less about the semantic web. Twitter bootstrap is a good example - it really is DIVitis, but really who cares? its rapid application development, it make the web look and act far nicer and more consistent, and it progresses the web as a platform.
Having your web app still work (through non Ajax'd GET, POST etc) for the 7 seconds it takes to download the javascript just isn't worth it - especially with html5.
[+] [-] jashkenas|14 years ago|reply
Unless your web application happens to actually be a series of <form>s, your JavaScript probably starts to become your content. To use an example from today, how would one go about building this without JavaScript? Without losing the heart of it in the translation to static HTML?
http://www.nytimes.com/interactive/2012/02/13/us/politics/20...
[+] [-] patrickaljord|14 years ago|reply
[+] [-] _harry|14 years ago|reply
(referring to your thoughts around 38:00-42:00)
[+] [-] jashkenas|14 years ago|reply
Backbone has always been intended to give you the smallest possible set of functionality that you reach for every time you work on a JS-powered web app. Model and Views and events to bind them together, collections with powerful functions for filtering and aggregating data, and shareable URLs.
There are lots of other directions and other needs that JS apps may have, but unless it's something that you're going to use pretty much every time, it doesn't belong in Backbone itself -- it belongs in an extension, or better yet, another standalone library. I'm talking about things like write-through localstorage caching, pushing data over websockets, TreeViews, query syntax for complex JSON, special cross-domain communication, specific HTML-generating strategies, or "mobile" widgets that mimic iOS controls.
Fact is, JS apps are still the wild west when it comes to patterns that work well -- there are plenty of fertile experiments to go around. You want a library that gives you a foundation, so that your app can rise up to meet it and extend it in new directions. I think that pretty much all of the apps in this list fit that description -- going far beyond what Backbone provides out of the box:
http://backbonejs.org/#examples
[+] [-] jashkenas|14 years ago|reply
* Source of truth.
* MVC / MVVM / MVP / The model-ui spectrum.
* JavaScript pipe dreams.
* Arbitrary code vs. structured templating systems.
* Everything-is-public APIs. +Hooks
* Client Side Models are not mirrors of Server Side Models
... and so on.
[+] [-] zalew|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] wavephorm|14 years ago|reply
"Handlebars is a compromise between logic and logicless views... ladda ladda ladda"
[+] [-] doubleconfess|14 years ago|reply