Building Decoupled JS Applications With Postal.js | Hacker News Reader

Building Decoupled JS Applications With Postal.js

jcreamerlive.com

33 pointsjcreamer8 comments

A similar thing can be done in Backbone by having a bare bones instance of the Event class that all other views and objects can listen and trigger events on. Postal probably does a lot more than this, but if you are already using backbone this is a simple way of decreasing coupling with very low overhead.

The backbone object itself now extends Events, so you can use

    Backbone.on('got_weather', function...)
    Backbone.trigger('got_weather', {})

You can also accomplish the same effect in Angular by creating several "controllers" with focused responsibilities, then communicating via events with $rootScope.$broadcast (publish) and $scope.$on (subscribe). I've been using this pattern a lot recently and have found it does a great job encouraging separation of concerns.

I've fallen in love with Knockout (http://knockoutjs.com) -- it's even simpler than this.

Completely abstracts away events and updating the DOM. It even tracks all the dependancies for you.

We've been using Knockout with pretty decent success so far at my company.

It's not a full-blown web framework, but that's part of the reason why we chose it instead of something like Angular.

I have been evaluating several Javascript frameworks recently and have been leaning towards Angular for the same reason (it's a very "prescriptive" framework, i.e., "here is the Angular way to do such-and-such...").

I am curious to hear more from your perspective -- was your reason to avoid Angular for this reason based on disagreeing with Angular's philosophies, or do your use cases not require this sort of "full-blown" web framework? Or something else entirely?

Sort of similar to what Zelphyr was saying. We liked the idea of sort-of building our own framework out of component parts, rather than something like Angular, mostly for the flexibility.

For example, we use Sammy for client-side routing. However, if we decided to ditch it and use something else in the future, it wouldn't be a huge effort to do that, theoretically. With something like Angular, though, it's their way or the highway, usually - you couldn't use a different routing system if you even wanted to.

This lets us pick and choose with the style we want instead of having to 'fight with' a tool trying to work around parts we don't like.

I don't know, I've also felt like recently we've been re-inventing the wheel to get all this stuff to work together anyway, so I'm not 100% sure of the value of our choices, but it's a conscious choice we made early on in any case.

I don't have any experience with Angular in particular, so take this with a grain of salt, but in my experience most frameworks, especially the ones who say, "here's the [framework] way to do such-and-such" are very tightly coupled.

They do a great job of getting you to 80% of your goal REALLY fast. The next 10% takes some work but is doable. But that last 10% is so hard you inevitably want/need to throw away the framework and write it from scratch.

Think of the Unix philosophy. Many small tools that do one thing but do it really well. Use those small tools in conjunction with each other and you have a very flexible, loosely coupled, and powerful system.

Reply on news.ycombinator.com