Substack (James Halliday)

It'd all be so much easier if people just stuck to what's already there. If you use NPM (which, if you're doing modern JavaScript, you should be using) you already have a task runner. If you can write shell scripts (whether actual shell scripts or just arbitrary scripts with a hashbang) you can write tasks. What's more, you can combine existing tasks and everything that has a CLI is already a task:

http://substack.net/task_automation_with_npm_run

Seeing all these grunt-* and gulp-* wrappers makes me sad. Unless your project is very complex, all you need can fit in your package.json (and, maybe, some scripts if you can't find anything that already does what you need it to do).

There are some projects that benefit from using dedicated build frameworks like Grunt, Gulp and so on. But the vast majority of projects using them just use them to run one or two tasks that already have a CLI. In those cases it's over-engineering a non-problem.

I agree that AngularJS is needlessly complex. It hides a lot of straightforward ideas behind confusing terminology ("this is a service, this is a constructor, but a constructor isn't actually a constructor, it's a function that creates a service, no not that kind of service, that one's just a function called service because reasons"). But I don't think that's representative of all libraries and frameworks.

jQuery for example, though ridiculed by many at this point, still exists and is still a go-to solution for conventional web pages. If…

SHOW NOTES:

Ryan Dahl
- How it all started.
- http://twitter.com/ryah

Matthew Podwysocki
- Node at Microsoft
- http://twitter.com/mattpodwysocki

Matthew Eernisse
- Node at Yammer
- http://twitter.com/mde

Isaac Schlueter
- Node at Node
- http://new.npmjs.org
- http://twitter.com/izs

Visnu Pitiyanuvath
- Node Knockout, Nov 10-11, 2013
- http://nodeknockout.com/tell-me-a-story
- http://nodeknockout.com
- http://twitter.com/visnup

Guillermo Rauch
- Story of Socket.io and Socket.io 1.0 announcement.
- Socket.io came out of wanting to implement operational transforms ala Etherpad.
- http://twitter.com/rauchg

Daniel Shaw
- “More Realtime” - RedisStore Docs, Socket.io-Announce, Redis Monitor
- http://dshaw.github.com/2012-07-nodeconf
- http://twitter.com/dshaw

Mikito Takada
- “Real time at larger scale”
- http://mixu.net/slides/nodeconf
- http://twitter.com/mikitotakada

Bert Belder
- libuv
- http://twitter.com/piscisaureus

Fedor Indutny
- Candor
- https://github.com/indutny/talks/
- http://twitter.com/indutny

James Halliday
- http://substack.net/doc/nodeconf_2012/
- http://twitter.com/substack

Voicebox Party
- Top 5 songs: Bohemian Rhapsody, Never Gonna Give You Up, Fresh Prince, Sabotage, Don’t Stop Believin’
- http://voiceboxpdx.com/nodeconf-2012-aftermath/
- http://voiceboxpdx.com/api
- http://search.npmjs.org/#/voicebox-karaoke

Tim Caswell
- Luvit (Lua + libUV + jIT)
- https://github.com/creationix/nodeconf2012
- https://twitter.com/creationix/

Marco Rogers
-…

I wanted to cross post this here as I already posted it in the comments.

-----

I am glad you wrote about this, but I feel you are missing the real 'magic' that can be done with node.js and Backbone, or any client code you choose. Socket.io is great, fantastic even, and I think it is something that really shows the power of node.js; there is something built on top of socket.io that is even more wonderful, and it is called dnode[0]. It is really simple to use, but has a lot of potential for server process to server process and server to client communication. It is in effect RPC, and I really can't do it justice.

For the example you give up here, you could easily overwrite the Backbone.sync function and have it instead send the appropriate objects you need to fetch models on the server, while having the server call back to the client with said models. Not only that but you could easily remotely invoke the model changed functions in Backbone directly from the server. There is so much more you can do, but I lack the knowledge at this point to put it in play just yet.

[0]: https://github.com/substack/dnode & http://substack.net/posts/85e1bd/DNode-Asynchronous-Remote-Method-Invocation-for-Node-js-and-the-Browser

I highly recommend this road as well.

Three exercises along the lines of the parent that I found particularly valuable:

1. Compare VanillaJS TodoMVC to your framework of choice

http://todomvc.com/

https://github.com/tastejs/todomvc/tree/gh-pages/examples/vanillajs

What does the framework buy you? Is the framework-powered code easier to read? Easier to understand for a newcomer to the code base?

2. Read every line of Effective Javascript (it's short and eminently practical) and write out every code example.

http://www.amazon.com/Effective-JavaScript-Specific-Software-Development/dp/0321812182/

There are about a dozen small errors in the code in the book, see if you can find them.

3. Read substack's alternative Javascript build flow:

http://substack.net/task_automation_with_npm_run

Think about the possibilities and limitations. (I personally love his approach at the beginning of projects when I could care less about fiddling with gulp and want to get into exploring the guts of a problem)

What about something like this?

http://substack.net/offline_decentralized_single_sign_on_in_the_browser

Edit: This article describes a solution that uses an appcache manifest with a far-future max-age that stops the browser from refetching the application code. It then uses an alternative mechanism to load updates presumably with a future option capable of verifying the legitimacy of the code with some sort of public key infrastructure ala Microsoft's Authenticode.