3 ms·

2010 was, for me, the year of JS-related technologies. (I'm actually rather disappointed I haven't had more time to check out Clojure and to use Haskell and Sca

by samdk 16y ago

2010 was, for me, the year of JS-related technologies. (I'm actually rather disappointed I haven't had more time to check out Clojure and to use Haskell and Scala more--I was doing quite a lot of front-end web stuff.) 1. Socket.IO (http://socket.io/ http://socket.io/) It lets you use websockets and automatically fall back to flash sockets, long polling, or several other real-time communication methods if websockets aren't supported by the client. There's a JS client and node-compatible server, as well as in-progress server implementations in a few other languages. Node is nice by itself, but it's with things like Socket.IO that it really shines. 2. Coffeescript (http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/) Coffeescript is a nice-looking and nice-to-type syntax on top of JavaScript. It's made JS development a lot friendlier, and I now miss things about it every time I'm programming in Python and Ruby. I now use it whenever I'm doing any significant amount of coding in JS. 3. Node.js (http://nodejs.org/ http://nodejs.org/) Node should, by this point, need no introduction. Server-side JS. Plays very nicely with websockets thanks to Socket.IO, making it very easy to write the server-side part of real-time webapps. I've also found it very useful when trying to quickly prototype simple non-webapp things that have to communicate over a network. I haven't had a chance to check out Backbone.js (http://documentcloud.github.com/backbone/ http://documentcloud.github.com/backbone/) yet beyond a very quick look, but I expect to use it (or something like it) next time I'm developing something that uses a significant amount of client-side JS. I'm also very excited by the continued development on (and Yehuda Katz's participation in) SproutCore (http://www.sproutcore.com/ http://www.sproutcore.com/).

hasenj 16y ago
Thanks for #1, never heard of websockets before.
jashkenas 16y ago
I'm looking forward to seeing someone combine Backbone.js with Websocket-based persistence. It's a bit out of scope for DocumentCloud to tackle, but the building blocks are there. One client makes a change to a model -> changes are synced to the server -> other clients that currently reference that model have its attributes updated -> all the UI that displays the model is automatically re-rendered. It's not critical for most applications, but is a really nice, nice-to-have for any JS app that displays the same editable data to more than one user at a time. Built-in conflict resolution mechanism for bonus points.
- datapimp 16y ago
  I started work on this a little while ago, and shared a starter template on https://github.com/datapimp/backbone-express-mongoose-socketio https://github.com/datapimp/backbone-express-mongoose-socket.... I am starting a new job in 2011 where we will be using this template heavily, so expect major updates in the first couple weeks of January.
- nsm 16y ago
  I'm doing something pretty similar to rumpetroll (it is fully functional rumpetroll now, but we will add more features) using Backbone Model View Collections as my 'Sprites'. The code isn't public yet, but me and a friend have some plans for it. The only thing different is that we've completely dropped use of Backbone.sync, for the sole reason that the method based approach does not fit very cleanly into what we are doing and websockets. So we have one model as a 'dispatcher' instead, to which all models send messages which are transmitted over websockets. All sprites communicate via attribute change events which is a really good use of Backbone. On the server a tiny node.js wrapper uses Redis pub-sub to relay messages out to other clients. The code is 'out there' but private, so if you want to take a peek at it, please contact me directly. Thanks for a great framework.
  - jashkenas 16y ago
    I'd love to take a peek, if you want to mail an invite to jashkenas at gmail. Replacing Backbone.sync is totally legit -- and is indeed what having Backbone.sync in a single place is intended for. There are many good paths to data persistence: REST/CRUD, RPC, aggregated JSON, CouchDB or Mongo, LocalStorage, and so on. Backbone.sync is just the default implementation for the common case. I think that one of the more exciting things about JS development these days, is how open and flexible the patterns still are.

by samdk 16y ago

hasenj 16y ago

Thanks for #1, never heard of websockets before.

jashkenas 16y ago

I'm looking forward to seeing someone combine Backbone.js with Websocket-based persistence. It's a bit out of scope for DocumentCloud to tackle, but the building blocks are there. One client makes a change to a model -> changes are synced to the server -> other clients that currently reference that model have its attributes updated -> all the UI that displays the model is automatically re-rendered. It's not critical for most applications, but is a really nice, nice-to-have for any JS app that displays the same editable data to more than one user at a time. Built-in conflict resolution mechanism for bonus points.

datapimp 16y ago
I started work on this a little while ago, and shared a starter template on https://github.com/datapimp/backbone-express-mongoose-socketio https://github.com/datapimp/backbone-express-mongoose-socket.... I am starting a new job in 2011 where we will be using this template heavily, so expect major updates in the first couple weeks of January.
nsm 16y ago
I'm doing something pretty similar to rumpetroll (it is fully functional rumpetroll now, but we will add more features) using Backbone Model View Collections as my 'Sprites'. The code isn't public yet, but me and a friend have some plans for it. The only thing different is that we've completely dropped use of Backbone.sync, for the sole reason that the method based approach does not fit very cleanly into what we are doing and websockets. So we have one model as a 'dispatcher' instead, to which all models send messages which are transmitted over websockets. All sprites communicate via attribute change events which is a really good use of Backbone. On the server a tiny node.js wrapper uses Redis pub-sub to relay messages out to other clients. The code is 'out there' but private, so if you want to take a peek at it, please contact me directly. Thanks for a great framework.
- jashkenas 16y ago
  I'd love to take a peek, if you want to mail an invite to jashkenas at gmail. Replacing Backbone.sync is totally legit -- and is indeed what having Backbone.sync in a single place is intended for. There are many good paths to data persistence: REST/CRUD, RPC, aggregated JSON, CouchDB or Mongo, LocalStorage, and so on. Backbone.sync is just the default implementation for the common case. I think that one of the more exciting things about JS development these days, is how open and flexible the patterns still are.