3 ms·

Building Decoupled JS Applications With Postal.js

33 points by jcreamer 14y ago

phreeza 14y ago
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.
- dgritsko 14y ago
  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.
- ricardobeat 14y ago
  The backbone object itself now extends Events, so you can use Backbone.on('got_weather', function...) Backbone.trigger('got_weather', {})
- RaphiePS 14y ago
  I've fallen in love with Knockout (http://knockoutjs.com 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.
  - spelunker 14y ago
    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.
    - dgritsko 14y ago
      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?
      - Zelphyr 14y ago
        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.
      - spelunker 14y ago
        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.

33 points by jcreamer 14y ago

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.

dgritsko 14y ago
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.
ricardobeat 14y ago
The backbone object itself now extends Events, so you can use Backbone.on('got_weather', function...) Backbone.trigger('got_weather', {})
RaphiePS 14y ago
I've fallen in love with Knockout (http://knockoutjs.com 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.
- spelunker 14y ago
  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.
  - dgritsko 14y ago
    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?
    - Zelphyr 14y ago
      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.
    - spelunker 14y ago
      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.