[alexgrigoryan]

Internally, we do have a set of blessed libraries to keep the site and teams unified. To ensure we don't go stale, we usually have a team or so experimenting with something that we can bring into "Electrode Core".

Externally, for the "Electrode Core", we will continue to maintain a set of libraries that play well together, but I expect to see people doing their own thing. I see what we are doing with core as more of a jumping off point for your app and setting you on the right path for managing many apps/components (with our notion of archetypes that manage your dependencies instead of top level app) and than people will mix technologies that they want.

We will continue to maintain our list though and manage dependencies through archetype (I think archetype is a powerful idea).

"Electrode Modules and Electrode Tools" are independent to the rest of Electrode. You can use these modules/tools independently of Electrode Core.

[marccantwell]

I'll grant this is a subtle point, but why did you choose to use the word "archetype", borrowing a term to describe what most understand to be generated boilerplate code? Why not call it a framework, or an app generator? Why did you, collectively I will assume, choose to assign a new term to an existing concept?

[exogen]

The archetype terminology comes from the use of Builder; you can get a rundown of what an archetype really is here, independently of its usage in Electrode: https://formidable.com/open-source/builder/

Framework and app generator are really quite far off from what an archetype provides. An archetype is like an npm module template, but not one that is used to generate code files and then discarded, but more like a live "superclass" of a module; think inheritance but for npm modules.

The basic idea is that if you have dozens or hundreds of similar modules (for, say, React components), with similar build + testing needs, you can use the same archetype for all of them. A generator like yeoman could spit out boilerplate for you, but then what if your boilerplate changes? Your packages quickly get out of sync with your latest best practices. Having some components on Babel 5 and some upgraded to Babel 6, for example, was a real pain. You have to go through your dozens of packages and bring them up to date. Archetypes on the other hand are intended to be encapsulated boilerplate that packages basically "inherit" from at runtime.

Hope that helps!

[marccantwell]

That was really well crafted, thank you. Much easier to digest than some of the docs. Though, I'm still not convinced it warrants a new way of describing a collection of patterns for various concerns, e.g. a framework.

[alexgrigoryan]

Thanks for the feedback about the documentation. We will work on improving it, especially around archetype.

Exogen, hope we can use what you wrote :D