Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it".

One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.

And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough.

Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: http://www.paulgraham.com/avg.html

Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else.

I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that.

It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.

EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.

More like, developers change jobs that often. So it's no longer your problem.

I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.

[0] 3% based on how many people will abandon a page that takes more than 1 second to render: https://blog.kissmetrics.com/loading-time/?wide=1

This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake.

There is a lot to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that technically uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen.

Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

>> if they all want to use it - let them use it

>> they use the framework they are most comfortable with.

> Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

I never said I did.

Amazon is an example, but there are many others.

I totally disagree, and not because of performance; choosing a framework based on its performance would be premature optimization. Your argument breaks down here:

> I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly

But that's exactly what a lot of projects using a framework end up doing. Between Ember, Angular, React, Backbone, Dojo, Prototype, and GWT, there is a ton of competition in this space, and you would have a hard time finding a team of professionals who all know the same framework. So at least some of your team will be learning the framework, and that learning will not pay off compared to just using vanilla JS. You can't argue that familiarity outweighs the complication added by a framework because people aren't familiar with the same frameworks.

Vanilla JavaScript is the lowest common denominator: almost everyone is familiar with it.

Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument.

It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".

I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.

I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two.

Of course, I've seen development languages chosen that way, NoSQL databases chosen that way, "which Linux variant do we base our company on" chosen that way, bug trackers chosen that way, chat systems chosen that way, devops management chosen that way, VM and/or containerization chosen that way (or, indeed, people just declaring "we need containers" for what appears to be "because we aren't cool if we don't have them")... you know, this may not really be just a "web" thing....

It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.

I suppose it depends on what you consider "significant" to mean. I have found close to 100% correlation between new technologies where I can understand the basic use cases and structure within a few hours and be moderately productive within at most a few days, and new technologies that have proven to be worth the effort in the long term when I've tried them. I can't immediately think of any exception to that rule within the field of front-end web tools I've tried so far.

I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! Of course, you need to learn how to balance the hype vs. the "sucks" options. The question is not whether somebody has something bad to say, the question is what bad things they say. Are they clearly using it wrong? Are they clearly using it in a use case the software doesn't even claim to support? Or... are they using it in exactly your use case in exactly the way you wanted to use it and encountered fundamental problems?

Even once you think you've settled on a choice, what other choices are there? The existence of a "good" choice does not preclude better choices.

If you do do a test deployment, don't fall into the trap of deploying at a radically smaller size than you need. If you're going to need the tech to work in clustered mode, for instance, don't deploy it to a single server and deploy three records to it. Deploy it in a cluster mode and load it up with 10-100x times the data you think it's going to have. You can't practically test the complexity of the app you wan to write without actually writing it, but you usually can test the size. Test your most complicated case; if you've got a web app and you want a framework to help you out, don't make the simple "user prefs" page, as soon as you can start working on the most complicated page in the site, which is probably the one that's the payload. Easy things being easy isn't an interesting test; check the hard things.

Find someone with a experience-hardened intuition to do this with you. Realize that any tiny issue you experience and can't get through now will become a large issue later. Realize that you generally always end up with some of those issues anyhow, so it's a question of picking which you go with. Don't underestimate the established choices. They're big for a reason, especially if they've been around for years. The new hotness will play up the old guard's flaws while minimizing their own. You can make anything look good by only considering the positives, you can make anything look bad by only considering the negatives. Always look at both for all options. Get that experienced person to help you through it.

For whatever task it is you are looking to do, figure out which problems you are most likely to have, and prioritize your analysis to focus on those. Do you know you need total CP consistency? Then you can quickly eliminate entire choices by whether they even claim it, and further eliminate more by checking whether they actually maintain it in the field on their user fora. Do you have price constraints? Bam, entire choices knocked out. I've never personally been in the situation where I got to the point where I needed to start kicking tires and I had a dozen equally-good choices; there was always a clear hierarchy.

And, in the end, do consider the joy-of-use of a tech... just don't make it your only consideration. An fun-to-use tech that completely fails to solve your problems rapidly becomes a nightmare-to-use tech anyhow. Ask around you about framework regret; anybody with a few years in should have at least one story of when they expected something to be awesome and it wasn't.

Even putting a week into something as important as "what database will we choose" can pay off huge, easily being the difference between project success or failure. You don't necessarily need to work everything out for months.

That's great advice. It's what I do. Helps find the trouble spots before I run into them.

It isn't just a web thing, but it is way worse in the web world. How many of the cases you described were for web shops?

If you're going to apply that standard, since to a first approximation everything is hooked up to the web, everything is web. In that case, it does no good to claim that "web people" are particularly prone to anything when "web people" are to a first approximation everybody.

Where's Backbone gone? Or Knockout? Or Handlebars? Is it NPM, Bower or a mix of the two? Or etc. etc. Are you writing coffeescript still, why not typescript? Did you make an app in Durandal? Haha! Time for Aurelia!

Angular 1, one of the longer lived projects, is literally just being turned into a non-standard after a whole lifetime of about that of the family hamster.

So they're not standards, they're all today's hotness that won't be used on tomorrows projects.

It takes a couple of years for coding standards in new languages and libraries to even evolve, no-one knows how to use it properly to begin with and everyone makes a mess in a different way as they deal with the quirks and build non-trivial projects, but eventually a consensus is born.

In JS frameworks, just as that is happening, the whole thing is abandoned rapidly for the new hotness.

The JS community is massive and very good at publicising their tools, so there are lots of (very visible) options, and it can give the impression that everyone is constantly switching tools, but that doesn't mean you actually have to.

So it's useful for young, inexperienced developers. Do you kids really not have in-house coding standards anymore, or do you rely on your toolsets to provide that for you?

Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own.

So I agree with your overall point of "don't just blindly adopt something", but the case can be also made for not naively doing everything your own personal way (including at the team/company level).

For example, "go fmt" exists for a reason.

If your own in-house developers, with full knowledge of the nature of their project and the kinds of requirements they're trying to meet, and with full control over their choice of tools and standards, really can't ever do better than some external organisation that is building a generic tool to cater to generic requirements and writing to general coding standards, then you should probably question the competence of your in-house developers.

This is not to say you shouldn't use existing material from outside your organisation if it's a good enough fit for what you're doing and saves time or otherwise has some tangible benefits, of course. However, your in-house team will normally have a huge advantage in terms of knowing specifics compared to almost any external equivalent. This is true whether we're talking about frameworks, coding standards, tools, or almost anything else used in programming.

The meme that anything written by a larger group of people outside your organisation is somehow inherently superior for your purposes to anything you could write in-house, and that any reluctance to use those external resources is inherently a case of NIH syndrome, just doesn't make any sense to me. There is no logical reason to believe it should be true since you're almost never comparing like with like, and I see very little empirical evidence that it is true in practice either, assuming reasonably competent and experienced in-house developers.

You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.

If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)

That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points.

> But you drew a distinction between "in-house standards" and "the framework's standards"

One is used in-house for all things relevant, one applies to a framework. In that, they are distinct.

> (which are by definition probably taken from widely adopted standards).

Probably.

> If you were implying that those two things might be identical then you did a bad job of conveying that.

sigh. Two things can be true at the same time. I give up.

I was making a generalized statement that likely applies to a large number of places (but indeed not all places), and you were providing a specific but not really comparable counter-point in return.

So yes, we were both right, but then again I ask "why reply?" if you're not replying in a similar context.

That's like me saying "the oceans are vast and dangerous" and you saying "but a pond is relatively safe"... You're technically correct, but what does it have to do with my initial statement?