It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support.
However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that.
So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes.
For example:
- encapsulation
- separation of concerns
- interfaces (In JavaScript: arrgghhhh!) - think contracts (function names and signatures). We've had lots of discussions about this but them continue to delivery value when building a maintainable app
- services via an IoC/Dynamic Service Locator (see Angular)
- PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful
All these ring of enterprise. But they're actually just good and simple software engineering practices.
When building large JavaScript apps it's about getting the balance right and we're hoping that as part of this open sourcing project we can do that.
One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.