7 ms·

Non-framework approach to JavaScript apps - hexagonal.js

30 points by andrzejkrzywda 14y ago

bestest 14y ago
I'd love to check it out, but I had too much coffee. Pun intended.
ganarajpr 14y ago
When I went ahead and had a look at one of the examples of hexagonal.js, Misko Hevery's answer in quora http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-js-is-the-better-choice http://www.quora.com/Ember-js/Which-one-of-angular-js-and-em... immediately came to my mind. He notes that there are 3 ways to bind data to view. 1 ) in the code - jquery way 2 ) In html bindings - angular way 3 ) in a metadata file.. which is the glue that is professed in this library.
- andrzejkrzywda 14y ago
  Thanks for the link. I wasn't aware of this discussion. Yes, it seems that hexagonal.js uses the third approach - a metadata file.
skywalk 14y ago
According to the page, it's neither a framework, nor a library - isn't that a bit counterintuitive? That makes it sounds as if it is beyond any of the existing styles of code reuse in software development, which is not the case. I'm sure many would identify it as a library in the classical sense, since it is a bundle of code you include in your application and make calls to.
- andrzejkrzywda 14y ago
  We were struggling with this problem for months. What would you suggest to bundle into this library?
- gcao 14y ago
  It's probably a design pattern, or a flavor of AOP (Aspect Oriented Programming).
bjfletcher 14y ago
Is hexagonal.js basically a very simple state machine framework? :) E.g., https://github.com/pluginaweek/state_machine https://github.com/pluginaweek/state_machine
warfangle 14y ago
Don't call something .js if it's all in .coffee.
- andrzejkrzywda 14y ago
  We're going to include pure JavaScript examples. I understand the confusion that comes with the fact that most examples are CoffeeScript. There's nothing that makes this approach impossible to use with JS. The code samples are Coffee, because that's what we write our production apps in.
  - __herson__ 14y ago
    So, name it "hexagonal.coffee" instead.
    - irickt 14y ago
      If a version of hexagonal targeted java then it would be "hexagonal.java". But .coffee and .js target the same "binary" so .js is the correct designation. It's about the runtime not the language.
      - laurent123456 14y ago
        Following this logic, they could have called it hexagonal.asm since it's eventually run as binary code.
  - laurent123456 14y ago
    It would be interesting to see at least a simple Hello World example in JavaScript, but I suspect the library is too dependent on CoffeeScript, and a compatible JS code would be too convoluted (I'd be glad to be proven wrong though).
MatthewPhillips 14y ago
Maybe I'm not "getting it", but what is the difference between: After(@useCase, "askForName", => @gui.showAskForName()) vs. @useCase.askForName() @gui.showAskForName() ?
- andrzejkrzywda 14y ago
  In runtime, this is exactly the result. As code modules, those two things are separated. The usecase doesn't need to know about the gui and vice versa. In theory, they can even be reusable. We combine those two things in the glue code. Thanks to the glue code, it's the usecase which drives the other things. The usecase makes sense even without thinking about a specific GUI solution. I'm not sure where we could put the second piece of code you mention. Any suggestion?
  - vidarh 14y ago
    I find it amusing that you are trying so hard to avoid naming this MVC. The "glue code" contains the code that would typically be a controller. The difference is that you do it by modifying the model and view, and that is the problem to me: You are making non-local modifications to the code, which means that while you are separating it in source, you are not keeping a separation in the running code. You make it extremely hard to reason about the system. This is already a problem in large event/notification driven systems, but this takes it to the extreme by removing the hint to look for non-local behaviour by having the equivalent to the notification imposed by an external actor. If you want to improve on a notification driven system, in my opinion you don't do that by making the extension points less obvious. And if you first are going to do that, at the very least do it in very obviously named functions, and don't modify passed in objects by make copies. But to me, those are workarounds to ameliorate a situation that's already undesirable. E.g. if you're making copies and modifying the copies and keeping those internal to the glue class you might as well go back to implementing an actual controller.
- vidarh 14y ago
  The difference is that After() modifies @useCase to that gui.showAskForName() always gets called after askForName on that object. Putting that kind of behaviour in a constructor in that way to me reads like a horrible anti-pattern.
irickt 14y ago
Previous discussion: http://news.ycombinator.com/item?id=5237977 http://news.ycombinator.com/item?id=5237977

I'd love to check it out, but I had too much coffee. Pun intended.

When I went ahead and had a look at one of the examples of hexagonal.js, Misko Hevery's answer in quora http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-js-is-the-better-choice http://www.quora.com/Ember-js/Which-one-of-angular-js-and-em... immediately came to my mind. He notes that there are 3 ways to bind data to view. 1 ) in the code - jquery way 2 ) In html bindings - angular way 3 ) in a metadata file.. which is the glue that is professed in this library.

andrzejkrzywda 14y ago
Thanks for the link. I wasn't aware of this discussion. Yes, it seems that hexagonal.js uses the third approach - a metadata file.

skywalk 14y ago

According to the page, it's neither a framework, nor a library - isn't that a bit counterintuitive? That makes it sounds as if it is beyond any of the existing styles of code reuse in software development, which is not the case. I'm sure many would identify it as a library in the classical sense, since it is a bundle of code you include in your application and make calls to.

andrzejkrzywda 14y ago
We were struggling with this problem for months. What would you suggest to bundle into this library?
gcao 14y ago
It's probably a design pattern, or a flavor of AOP (Aspect Oriented Programming).

bjfletcher 14y ago

Is hexagonal.js basically a very simple state machine framework? :) E.g., https://github.com/pluginaweek/state_machine https://github.com/pluginaweek/state_machine

warfangle 14y ago

Don't call something .js if it's all in .coffee.

andrzejkrzywda 14y ago
We're going to include pure JavaScript examples. I understand the confusion that comes with the fact that most examples are CoffeeScript. There's nothing that makes this approach impossible to use with JS. The code samples are Coffee, because that's what we write our production apps in.
- __herson__ 14y ago
  So, name it "hexagonal.coffee" instead.
  - irickt 14y ago
    If a version of hexagonal targeted java then it would be "hexagonal.java". But .coffee and .js target the same "binary" so .js is the correct designation. It's about the runtime not the language.
    - laurent123456 14y ago
      Following this logic, they could have called it hexagonal.asm since it's eventually run as binary code.
- laurent123456 14y ago
  It would be interesting to see at least a simple Hello World example in JavaScript, but I suspect the library is too dependent on CoffeeScript, and a compatible JS code would be too convoluted (I'd be glad to be proven wrong though).

MatthewPhillips 14y ago

Maybe I'm not "getting it", but what is the difference between: After(@useCase, "askForName", => @gui.showAskForName()) vs. @useCase.askForName() @gui.showAskForName() ?

andrzejkrzywda 14y ago
In runtime, this is exactly the result. As code modules, those two things are separated. The usecase doesn't need to know about the gui and vice versa. In theory, they can even be reusable. We combine those two things in the glue code. Thanks to the glue code, it's the usecase which drives the other things. The usecase makes sense even without thinking about a specific GUI solution. I'm not sure where we could put the second piece of code you mention. Any suggestion?
- vidarh 14y ago
  I find it amusing that you are trying so hard to avoid naming this MVC. The "glue code" contains the code that would typically be a controller. The difference is that you do it by modifying the model and view, and that is the problem to me: You are making non-local modifications to the code, which means that while you are separating it in source, you are not keeping a separation in the running code. You make it extremely hard to reason about the system. This is already a problem in large event/notification driven systems, but this takes it to the extreme by removing the hint to look for non-local behaviour by having the equivalent to the notification imposed by an external actor. If you want to improve on a notification driven system, in my opinion you don't do that by making the extension points less obvious. And if you first are going to do that, at the very least do it in very obviously named functions, and don't modify passed in objects by make copies. But to me, those are workarounds to ameliorate a situation that's already undesirable. E.g. if you're making copies and modifying the copies and keeping those internal to the glue class you might as well go back to implementing an actual controller.
vidarh 14y ago
The difference is that After() modifies @useCase to that gui.showAskForName() always gets called after askForName on that object. Putting that kind of behaviour in a constructor in that way to me reads like a horrible anti-pattern.

irickt 14y ago

Previous discussion: http://news.ycombinator.com/item?id=5237977 http://news.ycombinator.com/item?id=5237977