The reason why people like building the second layer is because the framework does not satisfy the needs of the application domain. My stance is to use thin libraries, that do few things but do them well without the bloat and the upgrade nightmares.

Making frameworks is relatively easy now days. There are plenty of idioms to choose from, but you can have a good sense of what is out there and what your preferences are. My preference is to not be fighting a framework to get it to do what I want.

In fact, you average experienced developer can quickly build forward thinking frameworks that work for their project, due to the plethora of libraries & articles out there. In my experience, the project is better off because it’s completely self-contained without an outside organization imposing upgrades and other schisms.

A stack that I like and can vouch for is:

* node.js for the app server
* browserify (commonjs for the front end)
* backbone (I have a single app object which keeps the data & events in one place)
* a reactive programming library (I use backbone-signal)
* Handlebars
* jasmine (with black box testing. I also use jasmine-flow to facilitate edge case testing)

The main thing tying it all together the structure is browserify. What is nice is the final javascript download can remain small because commonjs modules greatly alleviate the concern of application structure, since you follow a module directory structure. This allows me to pull in snippets of javascript from the web, or the good parts of libraries, while maintaining structural integrity.

I have a custom two way binding implementation that is < 50 LoC since my current app doesn't need much in that regard and my views have refresh methods which listen to updates changes in the signals.

However, there's rivets.js, if you want a standalone library, or knockout, if you are good with a light-weight framework.

With this stack, I built a light-weight, & relatively transparent, framework that is specific to the application and based off of obvious conventions and some common function calls accessible through commonjs modules.

Since I'm using node.js on the front and back end, I'm can easily share code between the two systems. It's nice, especially for caching.

I prefer to use view objects bound to signals. It is straightforward and it scales with complexity.

DI is a simple pattern of passing arguments to functions. You hardly need a framework for that.

Directives are a need that arise from needing to scale angular’s patten of putting logic in the html. I believe rivets covers that. I prefer not to put logic in my views.

I understand the fear of making yet another framework. However, frameworks are often a simple set of patterns and function calls you use on the project. It’s easy, and quick, to make a good, simple, framework and it feels great to work with code you enjoy. Most of the time is spent on selecting the right patterns to use.

Even in the angular community, people layer their own frameworks on top. Same happens in rails.

Just to make an example, I’m building an app than must send every key the user sends to a bash instance, and you know what? there is no standard way to detect keys in user’s language

Not `event.which`, not `event.charCode`, not `event.keyCode`, not even `event.keyIdentifier`. I had to create an input and listen to `keyup` to make sure the input has the new character and get the character from the input and detect when a special key is pressed as ESCAPE, BACKSPACE, HOME… by it’s key code but as it’s `keyup` if the user presses many keys I don’t know it until the user releases one.

We have lots and lots of MVC and we haven’t a well standarized keyboard control? http://unixpapa.com/js/key.html

I though reasons why double binding is more dry were obvious:

Double binding:
HTML:
{{ user.name }}
{{ foo.bar }}

Signaling:
HTML:
{{ user.name }}
{{ foo.bar }}
JAVASCRIPT:
user.on(“change”, myView.render);
foo.on(“change”, myView.render);

Now in both cases if I change model.name I’ll have the change reflected in the view. Since signaling requires more code it is less DRY as I add models to the view. Why do you say double binding is not composable?

I’m sorry for keep using the term “Unit test”, my fault, I mean testing. I don’t like to mock every component’s dependency it takes so much effort to develop and maintain to really not test compoents intercomunication. But to mock some concrete dependencies can make my test a lot more simpler. For example I always mock timeouts, intervals, ajax, events, and any type of asynchrony from my test, the code than implements the asyncrony is not on my code and when my tests are synchronous they execute a lot faster and are simpler to develop and maintain. Also I mock third parties and dependencies when they are from another business layer and yes, DI makes it simpler in this case.

And more important DI is not only about testing, it’s part of my SOLID test, if a component is adding complexity throught DI it’s usually because it’s coupled. And finally, you can’t compare Spring days DI (In my case WindsorContainer) with Angular’s DI, I think Angular’s DI is a vague approach but WindsorContainer was a huge moster. I think we can think a little bit about it and find a good place between.

I’m not saying directives were a need on Backbone I said they were a need *I* had, you’re free to disagree. Anyway I don’t see why are you mentioning shared logic and browserify here, I have nothing against browserify and shared logic is part of a developer’s job, doesn’t matter if it’s done using CommonJS, AMD or plain javascript. But we were talking about directives, weren’t we?

As I told you on the last comment, it’s not about developing time or adding features, it’s maintaining time what bit by bit takes your time and focus. One thing is true, the tool than fits better to a developer is a tool he made himself, but we can’t keep reinventing the wheel.

Well, we found a possible reason why we don’t agree, I have to do one application for mobile and one for desktop web since they are heavy RIAs Gmail-like and I’m talking about destop web.

I disagree, in my experience every time I or other developers say “I can implement that” we waste more time than learning the right way to use the tool.

As I said I think angular best features are double binding and directives, obviously this makes no sense on backend.

If you say double binding is sugar you can also say C is sugar for Assembler. For me it’s about not repeating my intentions, when I add a value to my templates I don’t have to say in the code “when this changes update the view” it’s implicit.

Angular composes the view using ng-scope, when a binded value change it does not render the entire view but the component’s. I think it’s not about pain, but about productivity, since I use doble binding I can prototype any idea I have in one hour. In fact I tried once to implement the same project with backbone and Angular and in angular it took me 10 hours, on Backbone I quit after 2 weeks (~60 hours) with the project not finished. I can create a alternative, test if I like it and continue my job in the same day. My main project is a huge RIA but I don’t have performance problems yet and I won’t solve them until I have them. “Premature optimization is the root of all evil”.

I don’t know the terms POJF and DSL in this context

I don’t think to test feedback is a overhead, it saves time since bad design decisions tend to propagate through the app.

I still don’t seeing how CommonJS compares to directives. I remember you I said directives help writing view-logic in the view and writing DRY HTML.

I know CommonJS and AMD are different, but it does not matter which one we use, since we make little components and share logic. By the way, AMD is a run-tyme *and* build-time tool while browserify is a build-time only tool. I like AMD because I can code everywhere without a build step and when the project is ready I can ask RequireJS to build my project.