Live data from Hacker News

Introducing hexagonal.js

blog.arkency.com

21–30 of 43 posts

Re: Introducing hexagonal.js

#21

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?

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.

Re: Introducing hexagonal.js

#22
post #6
post #4

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

Re: Introducing hexagonal.js

#23
post #21

Earlier quoted context omitted.

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'…

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.

Re: Introducing hexagonal.js

#24

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.

Because it is javascript, to be used by javascript projects. Not having JS examples is just a problem in the docs, not the library.

Re: Introducing hexagonal.js

#25
post #14

Earlier quoted context omitted.

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…

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

Re: Introducing hexagonal.js

#26
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.nameProvided

Re: Introducing hexagonal.js

#27

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 confirm…

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

Re: Introducing hexagonal.js

#28
post #14

Earlier quoted context omitted.

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…

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.

Re: Introducing hexagonal.js

#29
post #4

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.

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.

Re: Introducing hexagonal.js

#30

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++.
Post reply on HN