Description
What's really cool is having source COFFEE and SCSS (sassy coffee development, SCD) files as siblings. It's not just the dreaded catch-all of "js" and "css" but also the consequence of "views". Everything is functional groups. HTML files live with their directives, live with their controllers, specs, styles, etc. all in the same folders. Organic CSS is abstract enough to allow for "modules" and "molecules" to live in the same folder. It's freakin' sweet.
I don't want "from below" dictating my naming conventions ("js", "css") but I also don't want "from above" doing so either (folder names like "page" or "section"). I don't need two section folders, and being a page is irrelevant to the module itself — the module has a controller, the page does not have a controller. The controller and the HTML are parts to the module, not the page. They produce the page. Why name them within the app according to their effects, rather than their functionality? That crap is gorram confusing as heck all. I've done this on almost all of my projects. Generally I've promoted it, sometimes begrudgingly. There are higher order concerns I relate as the codebase implements Hypermedia View-based Modeling, where we develop Process Actors via http://schema.org/Action microdata with AngularJS modules specifications to build, style, and test hypermedia components, directives, etc. with U N A E S T H E T I C code.
Hypermedia Modelling Using UML. Peter Dolog, Mária Bieliková.
No "js" folders. No "css" folders. No "pages" here and "controllers" there. No "styles" folder. "Directive" is fine; "Service" is fine; "Component" is fine; "Template" is fine; "Module" is fine Because these concepts bear meaning is a generic sense of application infrastructure semantics, but naming "from below" based on methods or concepts of the framework-in-use is not going to happen here.
Generally if a microservice does not accompany the business object qua service, it will become nebulous, in most projects, what the Presentation model semantics will be. Some choose BEM, most do not.
"Directive" for instance is an older concept found in HTML-land. It makes almost no sense to name a folder "service" when everything inside it is a factory. They typically drive, regardless of role, activities, evolutions, and interactions. Possibly all modular; i.e., client/app/module/orders/index.scss governing client/app/module/orders/directive/index.html, etc. — contra some SASS architectures, which provide @mixins and $variables, etc. within each module, we promote a Unified Atomic strategy that weds nicely with a coherence of molecular interplaying with modular semantics. Someone asked, "Want to write CSS in JS?" Absolutely no. "I want to write JS with CSS side by side not only in my buffers, but in my file architecture. Directives and Classes share real estate in the HTML, so reflecting that agreement in conceptual space at the level of file architecture suggests a parity of Application Layer intermicrolayer semantics. We're just describing microdata, really. SCSS molecules start at the same moment within the scaffolding of the Presentation sublayer as modules: index.scss we could say is an override, but generally it should implement atoms or molecules, as an organelle would. The files sibling to index.scss would express molecular features not unlike those found in the originating molecule folder. Our configuration option may include this "interface" file or it may not, but the goal is to weigh in on @mixins which will be shared throughout the progression of duodependent modular and molecular semantics that each describe Interactions, Activities, and Evolutions expressed in channels of Hypermedia as spatial (enclosure), temporal (start when in tabular contexts, per se), and navigational (prev, next, up or webmention etc.).
"Component" is fine since it essentially means "not directive" (layout, structures, and concepts) in that a directive could live anywhere between a component and standard HTML, or even non-standard HTML, while a component essentially introduces non-standard HTML, and may be littered with special-purpose directives. A component is a configurable element, simply put; while a directive is a configurable attribute. So it's also not clear why AngularJS gets used merely as a system of introducing entry-points into "directive elements" which essentially become nothing more than conveniently constructed "pages as overblown directives". It's the question of the shortest path to doing DOM manipulation, which is fine, but just as controllers have become test beds for all the things, directives also become test beds for all the things — for stuff called "pages," which are generally meaningless in the web context. Meaningless legacy terms being underpinned by abstractions supporting skeuomorphs whose functionality is organized by meaningless groups of already deprecated terms... Even following Facebook's ontology demonstrates anything but a page in the normal sense. Minimally, web pages, not conceptually encumbered by legacy media ontologies and their classical/classist traditions, have cybernetic properties and classifications. When we build such things, we build what is conceptually underscored below in the schema.
So then, we build modules which produce pages. The page is a final cause, and the semantics/terminology centering on the generic procedure of its creation is wedded to the final cause from which web development has inherited its grounding semantics. We call certain things pages because it "fits" to the common understanding of things, but we are not building pages. We are building modules, as efficient cause. The formal cause of a web page is a module, not merely files we coincidentally call HTML, JS, and CSS. We could say that "functional group" are really just Aristotle's "formal causes." Formally, from this perspective, nothing really is a "page" from a web development standpoint; or in Badiouian-speak, we might say that "a page is a situation." Therefore, such a term makes little sense in the context of a web application, whose infrastructure is presumably informed by some rigorous, and other times not-so-rigorous, formal causes. It would make sense to identify where formal causes, or functional groups, can engender new capacities for agreement about the meaning of change qua activity within the evolution of pages as final causes to the initiatives of web development.
A "page" expressed from folders of "controllers" or "directives" where its "templates" are used only once and mean "template" only in that they are bound by data (so they're actually "skeletons" or whatever) or maybe even "views" — but Backbone already has something called a "view"...? So here, template is empty — because we haven't found a need for them. There are no modal windows, but that's where modal windows would go — because you'd like have a "confirm" and "approve" modal window supported by roughly the same template. Yet having a "template" for a site footer makes little sense — it's not a template, it's a skeleton to the site footer. Maybe "skeleton" is too A E S T H E T I C. "Shell," maybe? ¯\(°_o)/¯
So at the outset we want the following request flow:
"Module" is an important term here. It indicates "functional group" — a phrase used often in BA/QA/DEV conversations. The wider discussion concerns how this term relates to Node.js modules, AMD Modules, CommonJS modules, etc. Often times it's not clear why any of the practice of "modularizing" stuff is done at all considering that most projects end up just using jQuery anyway. Why wrap all of your functions AND load a 90K library that's going to be used for everything anyway? If we're going to use jQuery as a 'plugin system' then what the heck does it matter that we pollute global scope? You're going to use jQuery for everything, so everything you do will be closured by jQuery's $.fn.plugin; yet now the entire app is wrapped up to guard against a problem that was solved by namespacing and OLOO JavaScript prototypal development anyway. There's no point in wrapping functions up unless it is granted that they are part of a "module." So we might as well give in and figure out how to organize them as such, because then maybe we can have the liberality of expressing ourselves in module-land; rather than merely guarding against jQuery (which, as we've already observed, is namespacing everything anyway, and almost anything most developers are going to do will inevitably be dependent on jQuery, or some kind of "plugin" system or dependency injection system). So what are modules? They're functional groups. Sometimes they will have pages. Other times they will have forms, yet the page housing the form will need to be thought out. So the module, in such a scenario, will consist of a page and a form. Though often what happens is that the controller lives in one directory that is not of common ancestry as the "page" housing the form. So you'll have a "controller" living in a "controller" folder and some HTML living in a "page" folder that contains a form, all just to produce a form, one has to navigate the entire application where at no place is it expressed that these items are part of a functional group. Clues thoughout the app will clearly reference or mention these items insofar as the functionality must needs reference them at just the right moments, say, at the router, but nothing as part of the application's infrastructure says "these are part of a functional group"; it must be inferred, and is only indirectly expressed in virtue of the mere functioning of the app. So, in order to actually know that one route turns on a functional group, one cannot simply read a folder or read the code — one actually has to put the app together by provisioning it, configuring it, building it, and then deploying it either locally or remotely. Instead of being able to read about the functional groups, one has to hypothesize (about the software) that they are functional — yet nothing names these disparate pieces as a functional group. It becomes a mere coincidence of functioning that they might be considered part of a functional group. So, how do we remedy this lack of explicitness? The goal in this repository is the establish and demonstrate that "module" just means "functional group," along with what that may look like practically speaking. Generally, we avoid "js" or "css" folders, because these are the most meaningless in an environment where everything is ultimately "js or css" anyway. We avoid naming things based on the traditions of print-making (from above), like "page" as well as about naming things according to the mechanics of our technologies (from below). We can agree that some concepts bear homonyms with respect to those theaters of intellectual development: sections, modules, components, and so on, do share meaning between cyberspace and domains that are not cybernetic. We can imagine that in Star Wars the interfaces there were named accordingly as things like "module" or "service" insofar as the user interfaces were concerned. The names identified here seem abstract enough to support generational naming — so calling your application's infrastructure as such will imply, but not necessitate, that it was built to last. Otherwise, if it's meant not to last, call it whatever you want. Go MVVM, MOVE, MVC, whatever — call your "controllers" "cats" for all we care. But if you want to communicate "this application was built with a generational timeframe" in mind, the following names, while superficially likely excessive, pin-point "moments" in the infrastructure of an application that are non-reducible, while the presence of certain files in certain folders may appear to privilege unique file types, the blending into a flattened field of discovery of application aspects organizes the meaning of their names in a way that is significant and engendering of common language. If we can agree that there are atoms, then we can agree to call atoms whatever we like. But "page" (a page's features are referred to by the page itself, even when those features' scope extend, and become littered, beyond the scope of the literal page or pages which were built) or "controller" (400+ SLOC) mean almost nothing when these things become nothing more than catch-all or convenience words for "feature" — "make sure the newsletter works" could involve numerous controllers and pages; so getting closer to a codebase that functionally groups these things into one place, instead of their presence being a matter of conveniences and conventions tending to prefer the practices of unwitting adoptions through preference or bias is preferred. To say the least, we end up configuring apps often because it makes no sense to put HTML files inside of a folder that is inside of a folder named "js" if only for the fact that the boilerplate of the application is also in that folder. So instead of contorting the various workflows and variables to meet arbitrary practices we've adopted, why not name the things accordingly? Maybe we'll find out that we've all been on the same page all along, and our projects' will be flat because we all agreed that the aspects of it were there but simply never decided to agree on what we should call them.
Apps are made of, naming aside (hard problem! — whatever you name these things, they're in your app):
atom/common/component/config/(SCSS and COFFEE files live together here! sometimes built CSS will be called bycss!)directive/vender/(vendors as {{vendorName}}/*)external/(ngload,tpl,text,css)filter/module/molecule/organelle/section/service/template/utils/
Basic files:
boot.jsengine.js(thanks to dualapi)http.jsinterface.jsinterface.scssroute.js
But really it's just boot and interface. The two interface files are different aspects of the same thing. We should not be calling one "app" and the other "styles," or one "app" and the other "main." The files are about the interface. They are two aspects of the same thing.