We use Around in such cases - it can put original method call to callback of asynchronous method.

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.

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?

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.

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".

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.

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.

I scoped my blog just to unit tests, because it's short note rather than article. DI can be useful on integration and acceptance level too - for simple apps you should be able to configure whole app or its parts as easy as you run it on production. Without DI you have to do some magic with class / module constants, which can populate on other parts.

I think the basic difference between library and framework is that if you use framework it's responsible for bootstrap of your application, and library does not.

But also framework drives structure of result codebase - filenames convention, directory structure, maybe way you implement your features.

Thanks, as I mentioned in other comment - I plan to digg deeper and share knowledge, so be patient :)

Oh, I must have missed that in the comments. I really appreciate that! Keep me posted, would love to see that article! Thanks! :)

That's the next topic I want to digg in playing with Google Analytics. When I have some results I'll post them.

This is awesome. Thanks!!

Thanks for your comment.

I really try to find which part of this post could alienate any of our customers and I can't. I just described why we decided not to use ORM and I find it quite interesting for others - they can disagree, show why I'm wrong. They're (and also you) smart guys, know what to choose and if ideas are worth to apply.