JavaScript Jabber: Backbone.js(javascriptjabber.com)
javascriptjabber.com
JavaScript Jabber: Backbone.js
http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas/
6 comments
I think it's about more than just pain vs. gain.
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...
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...
exactly! why should we have that visualization be backed by a html table within the page? Especially when you probably have that data backed by an API anyway that could probably server up json, xml or whatever else.
Why? Because not everybody is a human with 20/20 vision sitting in front of a monitor.
Before I go off on to much of a rant, I do want to clarify - having the javascript be the content is fine for a special 'once off' page like the one in the grandparent post. In this case its probably replacing a flash animation. Its also fine for applications where you have a tight handle on the people and devices which will use it.
However as a general practice its a bad idea. A few very important cases that this breaks:
* The googlebot and archive.org
* Vision impaired users
* Services such as readability and instapaper
All of these could be better served by having a symantec table of data, which is then then enhanced and presented in a different manner by javascript.
Before I go off on to much of a rant, I do want to clarify - having the javascript be the content is fine for a special 'once off' page like the one in the grandparent post. In this case its probably replacing a flash animation. Its also fine for applications where you have a tight handle on the people and devices which will use it.
However as a general practice its a bad idea. A few very important cases that this breaks:
* The googlebot and archive.org
* Vision impaired users
* Services such as readability and instapaper
All of these could be better served by having a symantec table of data, which is then then enhanced and presented in a different manner by javascript.
I can't believe you're being downvoted, this is exactly why progressive enhancement can't be abandoned. As someone with poor vision, I've found most of the crap HN thinks is 'cute' to be completely unusable. The modern web is a huge pain to use, it was actually /better/ in 2005 than it is now, from a usability perspective. This is very scary, considering the renewed emphasis on good UI/UX.
The saving grace is that the 2012 internet has excellent mobile sites (they suck on mobile with user-scalable=0 or maximum-scale=1, but on a desktop browser things flow excellently).
Sadly you're sane understanding doesn't jive with the HN echo chamber, but you're spot-on. The web is more than just tech demos.
The saving grace is that the 2012 internet has excellent mobile sites (they suck on mobile with user-scalable=0 or maximum-scale=1, but on a desktop browser things flow excellently).
Sadly you're sane understanding doesn't jive with the HN echo chamber, but you're spot-on. The web is more than just tech demos.
Good points but I don't think witholding progress to support these services is a good idea.
The solution is to come up with best-practices and tools that allow both interactive and static versions to exist in tandem, with minimal overhead.
Catering to lowest common denominator means technology, for all humans, lags behind. This is a massive issue. Either the tools for consuming static content (e.g. google bot) need to evolve to embrace the modern internet, OR we need to produce simple tools for dynamic sites that transparently serve the static content for services that require it.
That said, there's a lot of simple elegance in a straight html page.
The solution is to come up with best-practices and tools that allow both interactive and static versions to exist in tandem, with minimal overhead.
Catering to lowest common denominator means technology, for all humans, lags behind. This is a massive issue. Either the tools for consuming static content (e.g. google bot) need to evolve to embrace the modern internet, OR we need to produce simple tools for dynamic sites that transparently serve the static content for services that require it.
That said, there's a lot of simple elegance in a straight html page.
Careful, you are arguing progress for the sake of it. If it does not serve a lowest common denominator it's probably not worth it and only fancy.
Slightly interesting in this context: http://www.youtube.com/watch?v=D9_6G8J6VJg (applications of simple sms based services covering Kenya)
Slightly interesting in this context: http://www.youtube.com/watch?v=D9_6G8J6VJg (applications of simple sms based services covering Kenya)
You’re talking about “content” sites rather than interactive applications.
It doesn’t make any sense to present a chat client or a multiplayer game or a data driven map or a vector drawing program as a set of hyperlinked pages. Googlebot, archive.org, instapaper, etc. wouldn’t really get much useful from such applications anyway.
It doesn’t make any sense to present a chat client or a multiplayer game or a data driven map or a vector drawing program as a set of hyperlinked pages. Googlebot, archive.org, instapaper, etc. wouldn’t really get much useful from such applications anyway.
I was expecting an XMPP/Jabber implementation in Javascript using Backbone.js
@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?
(referring to your thoughts around 38:00-42:00)
(referring to your thoughts around 38:00-42:00)
Sure. To expand a bit...
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
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
I think Yehudas point was, why do you want to have just the minimal functionality when you are constantly grabbing for Backbone Addons just to do the standard stuff.
Having a plugable architecture is great, but if rails never considered making a good thing standard (think bundler, or sprockets) really makes moving between rails apps so much easier.
For example I would say nested views, and view layouts is something that should be standard - isn't backbone built for the single page web app idea?
I have seen so many different layout managers, region managers etc.
Having a plugable architecture is great, but if rails never considered making a good thing standard (think bundler, or sprockets) really makes moving between rails apps so much easier.
For example I would say nested views, and view layouts is something that should be standard - isn't backbone built for the single page web app idea?
I have seen so many different layout managers, region managers etc.
I would say that backbone wasn't built for the "single page web app idea". I think of it more as an elegant nucleus for apps that have heavy client side javascript. I think its the same approach that sets a project like node apart from rails. A strong, un-opinionated core with a healthy modules community which allows you to tailor all parts of your project.
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
... and so on.
* 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.
[deleted]
Yikes, that is a whole lot of pedantic argument over the semantics of MVC.
"Handlebars is a compromise between logic and logicless views... ladda ladda ladda"
"Handlebars is a compromise between logic and logicless views... ladda ladda ladda"
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.
apologies, and I'm proving your point, but there's no such word as pedanticism. the word you were looking for is pedantry.
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.