Introducing hexagonal.js(blog.arkency.com)
blog.arkency.com
Introducing hexagonal.js
http://blog.arkency.com/2013/02/introducing-hexagonal-dot-js/
8 comments
Why not call it hexagonal.coffee? Why do CoffeeScript libraries get a .js extension? Yes I realize it works for JavaScript too, but it's weird to go see a library with *.js in the name and then to find only CoffeeScript in the documentation.
You read my mind, and I couldn't agree more; might as well call it hexagonal.cpp because hey, eventually it'll get run as C++.
We'll try to deliver new examples in pure JS.
That was an honest question more than a complaint. Why do CoffeeScript libraries not use the coffee extension? For broader appeal? Even if you had JavaScript documentation, I would see the source was written in CoffeeScript and realize I can't easily evaluate the quality of the source. Choosing CoffeeScript must mean you prefer it over JavaScript, so why use the extension of a language you do not prefer over one you do?
Ok, now I see what you meant. So basically we don't want to limit audience of that idea to just CoffeeScripters. Also: maybe we'll switch to JS some day - if community show the need.
You can look at the source just like any other js project. It might not look totally clean as a hand-written project, but there are absolutely worse things than looking at compiled coffeescript (cough lodash https://github.com/bestiejs/lodash/blob/master/lodash.js#L38...)
To be fair, that's a template you linked...
Also, why go out-of-your-way to bash another project? Why didn't you link the hexagonal source you mentioned, which would have been productive, instead of lodash?
Also, why go out-of-your-way to bash another project? Why didn't you link the hexagonal source you mentioned, which would have been productive, instead of lodash?
That template is source code for a function, it becomes the body of many lodash methods using eval. It's not out of my way, it sits right on top of my personal "ugly code" list; couldn't think of a better (worse?) example.
As I understand it there is no hexagonal source, it's just an architecture.
As I understand it there is no hexagonal source, it's just an architecture.
Because it is javascript, to be used by javascript projects. Not having JS examples is just a problem in the docs, not the library.
No, it's not JS.
> class UseCase
SyntaxError: Unexpected reserved wordOf course the point is it's not clear what it means to "be JS". Is it more important for the name to express what syntax the source code is in or what platform the code can run on? I think for your average developer who just wants to consume a library, they care more that it is a javascript-based library that they can use.
Of course CoffeeScript code won't run as javascript, it's not a superset. But it operates on the same global scope, the same object model, with similar semantics, so it "is" javascript, unlike other compile-to-js languages.
After reading more about it, I agree that it shouldn't have .js in it's name, or any other language extension, since it's not a framework/library. The fact that the examples are written in CoffeeScript is incidental.
After reading more about it, I agree that it shouldn't have .js in it's name, or any other language extension, since it's not a framework/library. The fact that the examples are written in CoffeeScript is incidental.
Hexagonal uses Raganwald's metaprogramming ideas. Follow the links from the dependency at https://github.com/gameboxed/YouAreDaBomb.
This shows the beauty of Coffeescript syntax for functional programming. For a deep understanding read Raganwald's new book http://ristrettolo.gy.
This shows the beauty of Coffeescript syntax for functional programming. For a deep understanding read Raganwald's new book http://ristrettolo.gy.
This.
I'm one of the people behind hexagonal.js. Raganwald's work enabled us to implement one of the main components - the glue code.
I'm one of the people behind hexagonal.js. Raganwald's work enabled us to implement one of the main components - the glue code.
Ok, I was thinking the idea behind this sounded a lot like the M.O. of Aspect-Oriented Programming, and it wasn't until I followed your github link that I saw that it was an "AOP library for JavaScript".
Not to take anything away from Raganwald, but there are other AOP JS projects (meld[1] would be an example).
1. https://github.com/cujojs/meld
Not to take anything away from Raganwald, but there are other AOP JS projects (meld[1] would be an example).
1. https://github.com/cujojs/meld
Isn't that glue going to fall apart when you start working with asynchronous methods? I might be suffering from tunnel vision, but IMO this is asking for an evented model:
class Glue
constructor: (@useCase, @gui, @storage)->
@useCase.on
askForName : @gui.showAskForName
nameProvided : @gui.hideAskForName
greetUser : @gui.showGreetMessage
restart : @gui.hideGreetMessage
@gui.on
restartClicked : @useCase.restart
confirmName : @useCase.nameProvidedWe use Around in such cases - it can put original method call to callback of asynchronous method.
This looks very cool, I've recently finished a Javascript application that used AOP for connecting the View to the Model and it rocked. I think I implemented up more or less this framework, but less generic.
The name is an issue though, hexagonal.js doesn't seem to have to do anything with what this framework does. If it is a framework that applies AOP to MVC, why not pick a name that relates to that? There isn't even a mention of AOP anywhere in the introduction.
The name is an issue though, hexagonal.js doesn't seem to have to do anything with what this framework does. If it is a framework that applies AOP to MVC, why not pick a name that relates to that? There isn't even a mention of AOP anywhere in the introduction.
This looks quite neat and the Rails example (https://github.com/hexagonaljs/rails-example) is interesting. I'll definitely have a play around with it later in my never-ending quest to find JS libraries that don't make me want to snap my computer in half.
Woaah, it's a cool idea, but I wonder how productive one would be in it. Will have to give it a shot later.
So the switching your mindset to hexagonal.js is quite hard at the beginning and I think it's the most time consuming part. Then you are very productive - gameboxed.com developed > 20 small and large apps using hexagonal.js last year.
How can it be a good thing to follow the MVC framework on both the client side and the server side, as it says in it's philosophy, when the client side is the V in MVC?
Good question. In hexagonal.js approach client side is full app - so there's model part (use case is part of model), glue ~ controller and views are GUI and other adapters.
Thanks for letting me know. I'll not be rushing out to add hexagonal.js to my Rails app, but if one of my friends who likes js wants to try building their own full app I'll mention this as a possibility.
To be honest most of project I developed with hexagonal.js have Rails as a backend and it's really powerful with sprockets on board. So give it a try, maybe in toy project.
Cool, I'll give it a shot, buddy. Thanks for the advice.
Why can't MVC be compositional? The model of the client can come from the server's view. For example, a server could follow MVC, where the view is responsible for forming the data (such as in JSON or XML). In turn, that could form the model for the client's use of MVC.
"Why can't MVC be compositional?"
Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
The web world really needs to get over its juvenile idea that MVC is the One True Architecture and if something isn't MVC it isn't good and therefore if we want to present a new library with a new design it is Mandatory to explain how "No, really, it's MVC! Even though it isn't, here's how it is!". It's not MVC. That's fine. It's probably better. Many designs are. MVC is fine in its niche but that niche doesn't cover Every Web Application Ever very well.
Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
The web world really needs to get over its juvenile idea that MVC is the One True Architecture and if something isn't MVC it isn't good and therefore if we want to present a new library with a new design it is Mandatory to explain how "No, really, it's MVC! Even though it isn't, here's how it is!". It's not MVC. That's fine. It's probably better. Many designs are. MVC is fine in its niche but that niche doesn't cover Every Web Application Ever very well.
I agree with your latter point. MVC isn't the last word in architectural patterns.
However...
> Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
I fail to see why the example I gave does not follow MVC. You have MVC on the server (as people have been familiar with for a very long time. Nothing new here). In turn, that data produced by the view on the server (could be HTML, XML, JSON, whatever) can form the model of a second MVC architecture on the client side.
What exactly isn't MVC in either the client or server? The only thing I can thing you might take issue with is consuming the model from the data sent from the server, but I couldn't explain why. This is still in keeping with the MVC pattern, which in no way prescribes that the data has to come directly from a database (or whatever else the server's model's state is formed by).
Or is the problem with the server's view not generating output that is necessarily HTML to be looked at, but data to be further consumed? Again I don't see how that doesn't fit in with the MVC framework.
However...
> Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
I fail to see why the example I gave does not follow MVC. You have MVC on the server (as people have been familiar with for a very long time. Nothing new here). In turn, that data produced by the view on the server (could be HTML, XML, JSON, whatever) can form the model of a second MVC architecture on the client side.
What exactly isn't MVC in either the client or server? The only thing I can thing you might take issue with is consuming the model from the data sent from the server, but I couldn't explain why. This is still in keeping with the MVC pattern, which in no way prescribes that the data has to come directly from a database (or whatever else the server's model's state is formed by).
Or is the problem with the server's view not generating output that is necessarily HTML to be looked at, but data to be further consumed? Again I don't see how that doesn't fit in with the MVC framework.
MVC doesn't have anywhere in it for a client-server relationship. This is because MVC is actually a desktop app model, designed for things like CAD programs. Client-server connections are too important to gloss over, because you can't gloss over the Fallacies of Distributed Computing: http://www.rgoarchitects.com/Files/fallacies.pdf And your architecture must actually handle those issues, which means it's not going to be MVC.
MVC makes sense for a pure Javascript app that uses the server only as a DB server (if that). It can at least be jammed into a classic old-style pure server application. But if your app actually spans the two, you haven't got MVC anymore... or you've got an app scoring 8 out of 8 on the network fallacies, probably by virtue of trying to wrap all network access behind an "RPC" interface, which tries to represent network interaction as local function calls, which one of the easiest ways to score an 8 out of 8 on the fallacies list.
Because of the way MVC tends to afford glossing over the network fallacies, I tend to consider it an inferior design for almost any web application. It's a lot of code busywork to try to sort of kind of (probably not actually, assuming the MVC one is starting with is even MVC in the first place and not just "vaguely MVCish in name only") conform to a particular architecture, requiring at least three moving pieces to do anything (one in each letter of the acronym, in practice, often a view on the server and on the client) mandating that your application be flung out all over the place, and it gives you... hardly anything in return, really. Certainly nothing that a direct application of DRY couldn't have given you. It isn't necessary for most web apps and it's a terrible default for a new web framework to impose on its users.
While I'm not a fan of the "hexagon" name (the number "six" doesn't seem to have any meaning, except this guy once drew a diagram in a hexagon), it's a much better way of looking at things. I tend to think of it as a celluar design; there are the cell innards, then surrounding it is a cell membrane that is responsible for cleaning up the innard's view of the outside world, and exposing well-defined capabilities to the outside world. (The metaphor is not perfect; biology is messy, and there's no compelling reason to copy that aspect. But the general idea of cells, or hexagons, is quite powerful.)
One of the interesting aspects of Haskell is that it tends to enable the creation of a lot of very fine-grained cells, where the type system is helping you build a very strong and very well-defined membrane; it allows you to see even things as simple as "map" as fitting in to this model, at the smallest level.
MVC makes sense for a pure Javascript app that uses the server only as a DB server (if that). It can at least be jammed into a classic old-style pure server application. But if your app actually spans the two, you haven't got MVC anymore... or you've got an app scoring 8 out of 8 on the network fallacies, probably by virtue of trying to wrap all network access behind an "RPC" interface, which tries to represent network interaction as local function calls, which one of the easiest ways to score an 8 out of 8 on the fallacies list.
Because of the way MVC tends to afford glossing over the network fallacies, I tend to consider it an inferior design for almost any web application. It's a lot of code busywork to try to sort of kind of (probably not actually, assuming the MVC one is starting with is even MVC in the first place and not just "vaguely MVCish in name only") conform to a particular architecture, requiring at least three moving pieces to do anything (one in each letter of the acronym, in practice, often a view on the server and on the client) mandating that your application be flung out all over the place, and it gives you... hardly anything in return, really. Certainly nothing that a direct application of DRY couldn't have given you. It isn't necessary for most web apps and it's a terrible default for a new web framework to impose on its users.
While I'm not a fan of the "hexagon" name (the number "six" doesn't seem to have any meaning, except this guy once drew a diagram in a hexagon), it's a much better way of looking at things. I tend to think of it as a celluar design; there are the cell innards, then surrounding it is a cell membrane that is responsible for cleaning up the innard's view of the outside world, and exposing well-defined capabilities to the outside world. (The metaphor is not perfect; biology is messy, and there's no compelling reason to copy that aspect. But the general idea of cells, or hexagons, is quite powerful.)
One of the interesting aspects of Haskell is that it tends to enable the creation of a lot of very fine-grained cells, where the type system is helping you build a very strong and very well-defined membrane; it allows you to see even things as simple as "map" as fitting in to this model, at the smallest level.
The OP likens the technique to DCI, which is contrasted to MVC by the inventor of both techniques in this article:
http://www.artima.com/articles/dci_vision.html
http://www.artima.com/articles/dci_vision.html
There's far too many typos for me to have any amount of confidence in the code itself.
Sorry, but I can't trust my business with people who cannot even be bothered to write proper English for their introduction.
Sorry, but I can't trust my business with people who cannot even be bothered to write proper English for their introduction.
I'm sorry for my angry comment. I guess I didn't hit the proper tone. I'm leaving it here for my eternal embarrassment, but here's what I meant to say:
I have had many bad experiences with incompetently-written libraries. A bad library can cost you days/weeks of productivity lost in fighting its idiosyncrasies and/or straight up bugs. A really-good indicator of the quality of a lib is the attention to detail in "minor" details like documentation.
Obviously if the docs are littered with typos they will be less useful, but there's another layer to it. English isn't much of a problem for sufficiently-skilled programmers, even if they are of foreign descent.
So, when I see a lib written in broken english like this, I make my conclusions about the attentiveness and skill of whoever wrote it. I'm not saying it's always right, but in the long-term this has saved me a lot of headaches.
Sorry for raining on everyone's parade, though. This really isn't the proper way to start a conversation.
I have had many bad experiences with incompetently-written libraries. A bad library can cost you days/weeks of productivity lost in fighting its idiosyncrasies and/or straight up bugs. A really-good indicator of the quality of a lib is the attention to detail in "minor" details like documentation.
Obviously if the docs are littered with typos they will be less useful, but there's another layer to it. English isn't much of a problem for sufficiently-skilled programmers, even if they are of foreign descent.
So, when I see a lib written in broken english like this, I make my conclusions about the attentiveness and skill of whoever wrote it. I'm not saying it's always right, but in the long-term this has saved me a lot of headaches.
Sorry for raining on everyone's parade, though. This really isn't the proper way to start a conversation.
Although I broadly agree with your point about significant details, it's absolutely not the case that English 'isn't much of a problem'. English is an extraordinarily hard language for a foreign learner: the grammar is idiosyncratic and subtle, our use of prepositions is frankly bizarre, the orthography is about as difficult as they get, etc. etc. etc.. English is a dominant language for historical reasons, but it would be hard to choose a worse one on linguistic grounds.
English is a dominant language for historical reasons, but it would be hard to choose a worse one on linguistic grounds.
Strongly disagree. Flexibility in a language leads to flexibility of the mind. The English language's incredible variety, massive vocabulary, and huge range of idioms is of great benefit to those that speak it (while also making it difficult to learn). Subtlety in a language is a virtue, not a vice.
For maximum linguistic impact, people should also learn languages that read right-to-left.
If you really want a more-or-less linguistically "simple" language, Spanish is a decent choice (and is also the second most widely used language, after Mandarin).
Strongly disagree. Flexibility in a language leads to flexibility of the mind. The English language's incredible variety, massive vocabulary, and huge range of idioms is of great benefit to those that speak it (while also making it difficult to learn). Subtlety in a language is a virtue, not a vice.
For maximum linguistic impact, people should also learn languages that read right-to-left.
If you really want a more-or-less linguistically "simple" language, Spanish is a decent choice (and is also the second most widely used language, after Mandarin).
> Flexibility in a language leads to flexibility of the mind. The English language's incredible variety, massive vocabulary, and huge range of idioms is of great benefit to those that speak it (while also making it difficult to learn). Subtlety in a language is a virtue, not a vice.
Indeed, but I think we're talking about language in two different ways: all your points are completely correct, but mainly of value to those who understand the language fairly well; my points were implicitly from the POV of a foreign learner trying to pick the language up.
As a native Anglophone, I love our freaky language, orthography and all. However, I try to keep reminding myself how horrible it is for new learners.
Indeed, but I think we're talking about language in two different ways: all your points are completely correct, but mainly of value to those who understand the language fairly well; my points were implicitly from the POV of a foreign learner trying to pick the language up.
As a native Anglophone, I love our freaky language, orthography and all. However, I try to keep reminding myself how horrible it is for new learners.
I think that's a really nasty way to begin a conversation. It wasn't that bad at all.
It's a pitch from dedicated folks. Treat it as such?
On topic: Looks like an interesting collection of ideas, and as I've never heard of hexagonal architecture I'll definitely have to look into this. Always researching better ways of doing structure.
It's a pitch from dedicated folks. Treat it as such?
On topic: Looks like an interesting collection of ideas, and as I've never heard of hexagonal architecture I'll definitely have to look into this. Always researching better ways of doing structure.
Unintended humor alert:
x1024's criticism is not idiomatic English. "... can't trust by business with ..." should be " ... can't trust my business to ..."
Sorry for my poor english, I'm still learning :(
While there are some errors on your page, don't worry too much about it. It is fully possibly to understand and make sense of it.
As someone else said, he was being a dick about it, and the implication that English skills are somehow related to coding skills is obviously nonsense. (And he still managed to make mistakes of his own while criticising your language)
To be a bit more constructive, here's a slightly rewritten introductory paragraph that I believe reads more natural (though English isn't my native language either):
"There's an idea we have been working on for more than one year so far. As backend developers we were thrown into the mysterious world of frontend (client-side) apps without any good pattern for creating Single Page Apps. So we (GameBoxed + Arkency) invented one - hexagonal.js."
But the most frequently occurring English mistake on your page appears to be missing "the"'s. This error is very common with speakers of slavic languages. Based on the admittedly limited example of your English on the linked page, I think one of the biggest improvements you can get with relatively little effort would be if you spend some time reading up on how to identify where/how to use "the".
As someone else said, he was being a dick about it, and the implication that English skills are somehow related to coding skills is obviously nonsense. (And he still managed to make mistakes of his own while criticising your language)
To be a bit more constructive, here's a slightly rewritten introductory paragraph that I believe reads more natural (though English isn't my native language either):
"There's an idea we have been working on for more than one year so far. As backend developers we were thrown into the mysterious world of frontend (client-side) apps without any good pattern for creating Single Page Apps. So we (GameBoxed + Arkency) invented one - hexagonal.js."
But the most frequently occurring English mistake on your page appears to be missing "the"'s. This error is very common with speakers of slavic languages. Based on the admittedly limited example of your English on the linked page, I think one of the biggest improvements you can get with relatively little effort would be if you spend some time reading up on how to identify where/how to use "the".
No need to apologise; he was being a dick. Your english isn't bad and his comment is totally uncalled for.
it was fine, perfectly readable. thanks for the cool library.