> Why call something a "blade" when you could call it a component or module for instance?it's just confusing and dont help understand what the framework is about. Naming things the right way is important.It means you got your domain logic right.
"component" and "module" are vastly over used in software development so we went with something that was unique and works well with the unique concept we'd developed (~3 years old now). "framework" suffers the same over-use problem so we're probably going to remove that from the intro paragraph.
We specifically went for "Blade" as it works well. Blades represent a vertical _slice_ of application functionality, from UI to interaction with a service layer. Blades contain all the assets (JS, CSS, HTML, config, images) for a single feature grouped together on disk.
BRJS is much more about structuring your application and enabling a workflow that ensures a large and complex JavaScript application is maintainable. It's primarily an extensible toolkit with some core conventions e.g. scaffolding, Blades, Workbenches, Aspects, code dependency analysis for bundling for all asset types etc.
Right now we support writing code in a Node.js-style similar to that which Browserify enables (CommonJS + addition export support) but in the future the toolkit will allow us to move to something like ES6 or maybe TypeScript. We presently have Knockout as default in the Blade templates but we plan to add support for other template types such as Angular, Ember and Web Components (with Polymer). Until we add custom template support it's a small manual step to use these instead of Knockout.
We're only at v0.5 so many things are still evolving, including refining how we describe what it does and the benefits.
This is all useful feedback. So, thanks.