Non-framework approach to JavaScript apps - hexagonal.js

http://andrzejonsoftware.blogspot.com/2013/02/non-framework-approach-to-javascript.html

by andrzejkrzywda • 13 years ago

30 21 13 years ago

andrzejonsoftware.blogspot.com

bestest• 13 years ago

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

ganarajpr• 13 years 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-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.

andrzejkrzywda5• 13 years 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• 13 years 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.

andrzejkrzywda5• 13 years ago

We were struggling with this problem for months.

What would you suggest to bundle into this library?

gcao• 13 years ago

It's probably a design pattern, or a flavor of AOP (Aspect Oriented Programming).

bjfletcher• 13 years ago

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

warfangle• 13 years ago

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

andrzejkrzywda5• 13 years 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__• 13 years ago

So, name it "hexagonal.coffee" instead.

laurent1234562• 13 years 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• 13 years ago

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

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

vs.

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

?

vidarh3• 13 years 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.

irickt3• 13 years ago

Please explain the anti-pattern you see and the pattern your prefer.

andrzejkrzywda5• 13 years 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?

vidarh3• 13 years 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.

irickt3• 13 years ago

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

Non-framework approach to JavaScript apps - hexagonal.js

Related Stories