[pkozlowski_os]

I'm yet to see a non-trivial (100+ screens, 10+ devs over 10+ months) production-level app written in "vanilla JS" without any framework (popular open-source or home-grown "monster"). You need _something_ to structure your code and take care of repetitive / boring details.

[nostrademons]

Google Search, from when it first got Javascript in 2008 to when it adopted Closure in 2012.

[dubcanada]

What most people don't understand is even if you don't use a framework you end up building your own.

[nostrademons]

The flip side of this is that you end up building your own that is tailored to the particular requirements, users, and resources available to your product. That can be a huge advantage, given that differentiation is the only thing that will make your product stand out in the marketplace.

Are you in a latency-critical domain, which Google Search is? Then optimize to minimize the number of bytes shipped to the user and startup time. Do you have 100+ screenfuls of information? Then optimize so that making new screens is easy. Do users load your app once, leave it open in the background, but then need to perform a number of interactions quickly? Then ship down the initial interface quickly and progressively lazy-load bundles of functionality that are just a JS function away on click, like GMail does.

Incidentally, one of the main reasons Google Search finally adopted Closure was because it had to integrate with Google+, which was all done using Closure. So again, the choice of a framework was driven by product concerns.

It's not a failure when a company builds a home-grown framework that is carefully tailored to the product needs that they've discovered over the last few years. Indeed, having the resources and domain knowledge to build your own framework is a far bigger success than building an app with the hot framework of the month and failing because you look just like every other app out there.

[pkozlowski_os]

How many apps in the World require a specialised framework that GMail might require? 10? 100? 1000? Sure, everyone can invent their own framework to be very "specialised" and "tailored" to a given app needs but is it going to give a competitive advantage for a given app? Probably sometimes. Probably not most of the time.

Constructing your own framework has cost. Sure, you will acquire a lot of knowledge doing it, but is it going to help the bottom line? Maybe.

Once again, are you seriously advocating that _everyone_ should do "vanilla JS" without any frameworks?

[nostrademons]

I'm advocating that everyone start with vanilla JS without frameworks. See how far it will take you. Once you've built a simple prototype, put it in front of users, made a few changes, and have a sense of how the product will evolve to satisfy those users, then you can choose a framework. And you can choose it with a lot more knowledge about what your needs will be than if you tried to guess ahead of time, and you won't be steered away from particular customer desires because the framework makes them difficult and other stuff easy.

Rewriting your product is not failure, particularly when done at the very early stages where it only takes a week or so anyway.

As a nice side benefit, this also avoids all the holy wars about which framework is best, since you can put off the decision until you have hard data about which is best for you.

[lhorie]

If you're going to rewrite it anyways, then why not just pick a random framework? "No framework" is still a set of trade-offs, and for better or for worse, most teams aren't made of super star devs. A lot of them appreciate the hand-holding through the where-to-put-what drudge at the beginning of a project and the presence of a community to ask questions.

[wwweston]

I think almost everyone actually understands that. What I'm not sure about is whether most of the people who say that are clear on the fact that may not be a bad thing.

Frameworks can have their own complexity and developer overhead, they can demand you spend more time solving the problems they impose (cough AngularJS), they can be ill-suited to the requirements and/or problem domain you're working in.

Building your own isn't always the sensible choice, but it can be.

[wbsgrepit]

This. A large codebase without a framework almost always becomes a defacto framework; else it becomes too much technical debt and is rewritten in a framework. =)

[pkozlowski_os]

Right. I was more after examples of apps in the wild done by "average" (whatever it means) group of developers in an "average" dev shop. A group of rock-star developers will do "right thing" most of the time, regardless of the technology. The question is: can we scale this experience for majority of web applications that most developers keep on coding?