

Non-framework approach to JavaScript apps - hexagonal.js - andrzejkrzywda
http://andrzejonsoftware.blogspot.com/2013/02/non-framework-approach-to-javascript.html

======
ganarajpr
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-em...](http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-
js-is-the-better-choice) 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
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
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
We were struggling with this problem for months.

What would you suggest to bundle into this library?

------
MatthewPhillips
Maybe I'm not "getting it", but what is the difference between:

    
    
        After(@useCase, "askForName", => @gui.showAskForName())
    

vs.

    
    
        @useCase.askForName()
        @gui.showAskForName()
    
    ?

~~~
andrzejkrzywda
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
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.

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

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

~~~
andrzejkrzywda
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__
So, name it "hexagonal.coffee" instead.

~~~
irickt
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
Following this logic, they could have called it hexagonal.asm since it's
eventually run as binary code.

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

------
irickt
Previous discussion: <http://news.ycombinator.com/item?id=5237977>

