Write a Chapter: "Framework & Library Choices" about engineering-handbook HOT 7 CLOSED

I think the most important thing here is framing the choices we make based on our overall software requirements. Things like:

• Low/no bandwidth users
• Localization
• Low-end devices
• Distributed contributors

I'm happy for the first stab at asserting the choices to simply be a bullet list and the bulk of the effort be an app that we can collaborate on.

from engineering-handbook.

I also wonder if there are some "philosophical" things we can address here too, or heuristics that help us determine whether a tool is worthwhile to use?

For example:

• Stability. Even if it's doing something really awesome, a quickly-evolving tool that's currently at v0.1 could mean we get tripped up on lots of paper-cuts, and our code could constantly break against its latest version. I'm not saying we shouldn't depend on such tools, I'm just saying a tool's maturity should factor in to a decision on whether to use it.
• Developer Ergonomics. If making mistakes in the tool results in cryptic error messages that are hard to trace, this could affect developer productivity and morale.
• Cognitive Load. Does a tool require taking a lot of time to learn its ins and outs? While this is just a one-time cost for small, stable teams, it could mean a long on-boarding process for community and new contributors. I think an ideal tool is one that introduces a small number of new concepts, with each concept providing tons of leverage to make the developer's life easier.

from engineering-handbook.

@toolness, totally.

We had some other crappy notes that we worked on before, worth noting and maybe extracting:
https://wex.etherpad.mozilla.org/stack

from engineering-handbook.

So I'm stubbing this, but there's a lot of placeholding at the moment.

from engineering-handbook.

Filed as #23

from engineering-handbook.

@jbuck the more I read up on Hapi, the more it seems it's merely "better by convention", not better by design. I can't really find anything that isn't just as loose as in Express, and something that even if we switch over, still requires implementation-approach review when we do development work. There's also preciously few tutorials/examples/docs available that give "how to Hapi" rundowns, so I'm not really sold on it.

Can you list some of the things you would say Hapi is a better choice here?

from engineering-handbook.

Wanted to make sure that @Pomax and @jbuck knew about http://koajs.com/ as well. I haven't tried it, but I love the use of generators to make the middleware elegant, and the Context as a thing that lives for the duration of the entire HTTP transaction. Requires --harmony.

from engineering-handbook.