I'd hope you'd have something more constructive to say.
I'm not saying enterprisey is good, but, damn, evaluate it based on the actual design, rather than running away screaming because it uses IoC and publish/subscribe.
A small example is usage of XML files for configuration of aliases. Very few people use XML files in the JavaScript world - - while it's almost a standard for Java projects.
In general, the more I look at the codebase the more messy it looks like. They could have built something much simpler that solves the same problem.
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.
The tooling itself is Java since a lot of Caplin's customers still have't adopted Node, in fact some of their ops departments are completely opposed to it, and just because it isn't written in the same language as your front end code does't mean the tooling and principles are any less valid or useful.