This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.

Or one could say that it reveals the fatal flaw in our current system of capitalism:

Automation is desirable because it increases efficiency and lowers costs.

Automation is undesirable because it eliminates jobs and automatons are not consumers.

That was Marx main argument for the inevitability of a socialist revolution: That capitalism will eventually become efficient enough to on one hand create enough goods to make it possible to totally eradicate poverty, but on the other hand become efficient enough to substantially reduce employment.

Indeed.

But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design).

This is yet another instance of Worse is Better.

What is worse? What is better? Often shipping something that is 'Good Enough' is better than getting the 'right' (perfect?) design for a program.

In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have.

So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong.

That may be a testament to my skill, the problems I work on, or both.

I find the difference to be that each developer is now more productive and can add more function in less time.

The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things.

I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.

I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.

I don't know why you were downvoted. I (think) I agree with you.

I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen.

For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that.

However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code.

Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP.

I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.

And yet I haven't seen a convincing web CRUD framework. Have you?

I never did desktop development so don't know about there, but some must have been good.

Isn't that basically what Rails and Django are? Or are you asking for something client-side?

It doesn't commoditize the entire profession, only the 50% of it that is common to every web site or app you ever build. The other 50% is where the artistic license, craftsmanship, business sense, empiricism, and other value-adds of your team comes in.

"then what avenues are left to express technical ability"

I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?

This is not about code golf, this is about the widespread automatic use of frameworks in lieu of an analysis/design/build-one-to-throw-away phase.

Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...

Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.

Frameworks tend to arise in languages with poor composability. Composable languages favour large numbers of small libraries which can be mixed and matched in many creative ways. Composability favours design.

Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.

You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such.

And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.

"And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together."

Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything?

I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".

Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.

Well, sure. When I need something like URL routing, or object-relational mapping, or templating, why not reinvent it from scratch every time? Or, failing that, why not handle things like that with a collection of favorite libraries, each of which has its own calling conventions, its own requirements, and its own attitude toward the world? Reconciling all those differences certainly won't take a significant amount of time, and I'm always happy to spend my efforts on tooling instead of on whatever project inspired the need for tooling in the first place.

More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too.

But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.

Prototypes always end up in production, framework or not.

I've seen this happen over over to the point where work prototypes are not terribly removed from production code.

I prototype slower, but nobody cares.

I just try to write production quality prototypes these days. Django is a godsend for writing maintainable solid agile database applications.