[pluma]

I'm finding that in many cases the old adage holds true: "You're always using a framework. Either you're using an existing framework, or you're building your own." (paraphrased)

Sure, if legacy browser support is not a concern and you don't need to support bleeding-edge features (i.e. unstable APIs), you can go a long way with vanilla JS. But at some point any large system needs abstractions in order to stay maintainable. And if you don't use existing abstractions, you'll have to come up with your own abstractions.

Of course the other option is to simply not build large enough systems to require abstractions.

That said, I do prefer smaller libraries, too. This is why I see React not being a full replacement for all of Angular as a feature rather than a limitation.

I only ever began considering Express as a framework when it dropped the vast majority of its features (mostly middleware) in 4.x, too.

[hrish2006]

Well, a custom framework might evolve when you write everything using just JavaScript, but I've found that when such a thing does happen, it suits your needs perfectly. Even if I screw up, I'll at least know where to look when I'm debugging :)

[andybak]

Time to wheel out another paraphrase of Greenspun's Tenth Rule (http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)

How about:

"Any sufficiently complicated collection of libraries contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a full framework"?

;-)

[hrish2006]

That sounds about right :) . However, you need a great degree of discipline (greater compared to other languages IMO), to write good JS. JS enforces almost nothing, so it's up to the programmer to design an application architecture that suits her, so it might not be as ad-hoc in real life applications after all.