> I don't think engineers use frameworks because they think it makes them look cool.

I've been in this line of work for a long time, and I'll admit its a huge factor. Webdev is a very fad-driven business, and I've seen numerous technologies come-and-go where they were hot, but not they are now super not. And to some degree this is logical, because you want people who can adapt to whatever is latest-and-greatest and not just a particular platform. But when recruiting it certainly helps.

Plus the old chestnut that 50%-80% of software projects are failures, and looking out for number one means resume-oriented development for the next job. You are probably better off with a failed project on a 'cool' framework than a successful project on an uncool one.

I've talked to several really enthusiastic developer advocates about technology in the corridor and when it comes to describing the actual product or use of the technology they tend to mumble, or wave hands, or state some product that HN would argue about (e.g. advertising). All the developer advocates I've met who promote latest tech really don't seem to like their companys product.

I would say that developers try to make it a fad to keep themselves interested and engaged in an otherwise boring, soul destroying or socially harmful job.

Don't forget that a dev may need another job in the future. And it doesn't help finding one when spending the last 2 years building an app with some "oldschool" tech stack that performs well. Most companies are looking for dev's who worked with the cool fancy stuff like react because that's already the tech stack they are using.

And what is so bad trying to make my job interesting? If it's boring I wouldn't care much about the end result. Just another 9 to 5 job then.

Nothing bad about making something interesting. You would be interested in the end result - but for developers who do this the end result is the technology they produce and not the product that the tech is being used for.

I think it would be one of the reasons why "putting devs before users" happens.

Also - look at the HN Who's Hiring threads. Almost all postings don't talk about the product or their users. They talk about the technology.

That's true, in most of the company's I worked (includes the current one) I'm not interested in the product at all. I work there because I can decide which tech stack we use, try and learn the fancy stuff and have some fun building it. Why? Because I can - I am one of the few "good" dev's out there. So many companies are hiring and they take what they can get. And I as a dev can choose where I want to work. And of course I choose the interesting one. In conclusion there are much more companies hiring then good dev's looking for a job. So the company has to make itself interesting for dev's.

But I don't think that's bad at all. With modern devices and Browsers you can't tell the difference between using a framework or not.

> That's true, in most of the company's I worked (includes the current one) I'm not interested in the product at all.

This way of thinking would honestly have never occurred to me. If I'm really not interested in the product a company produces, then I don't think that I'm qualified to work there.

> With modern devices and Browsers you can't tell the difference between using a framework or not.

I sure can!

That was a funny bit of honesty. You should have stuck with it till then end and tell it like it is: It doesn't work on slightly older devices. Or something like: You really notice things don't work when using a slightly older device.

Jokes aside, I cant seem to find data on the age distribution of interneted computers.

You are the kind of person who believes that every app should support ie8 and even before that, right? Don't forget to limit your 500ps car to drive only 25mph...

It isn't your fault they hire people who don't care about the product. That you pick a tech stack that inspires you is a logical [and predictable] follow up.

I think a lot of people still think things are/should be something like: First the product, 2nd the customer, 3rd the company, 4th the investors and the employees last.

But the reality is often more like: First the investors, 2nd the employees, 3rd the company, 4th the customer, and oh we need some kind of product too!

You get the open floor plan so that the investor can see lots of people working. A nice ping pong table to illustrate the lack of employee equity. A fun tech stack to attract and keep the employees happy. Large expensive chunks of plastic with the company name on it. Great customer service to help the customer with their problems and lastly a product that doesn't work.

Again, I'm not suggesting any of this is your fault. On the contrary, one cant teach passion. You either care about the product or you don't.

> Webdev is a very fad-driven business

I think it is like this because it is kind of awful on so many dimensions, and we have hacked the browser to do all sorts of things. It's kind of amazing, but now we have to deal with it.

> I don't think engineers use frameworks because they think it makes them look cool.

Or, management tells engineers what tools to use because they think it makes them look cool.

Our company recently got word from above that "all these old technologies go out the window, you're now all becoming JS devs and we'll use microservices for everything".

The result is that for one project I could probably build entirely by myself with a LAMP stack in one week, we now have 15+ people in 3 teams & 3 different countries each working on tiny parts of a very small simple app barely used by anyone, using a whole shopping list of tech that you simply don't need.

When I asked one of those management "evangelist" guys during an informal dinner "so why all of a sudden JS frameworks?" his answer was something honestly along the lines of "I don't know it seems the thing to do nowadays".

Needless to say I'm job hunting like my life depends on it.

Buisness schools need a new lecture: Management as a Liability: Tech debt, tech insolvency and what one can do to prevent it.

I worked in automation for quite a while now- and seriously, i would be glad by now if management would push for new technology. The tech here is stagnant since the 80s.

They start debates when you talk about object orientation.

I recently graduated and majored in CIS as well as CS, and the CIS classes were in the business school. This is something we talked about a good deal in one of my CIS classes. Unfortunately, it was a specific major class, not something all business majors took. I am unsure if normal management majors were taught similar ideas but I thought the class I took was rather well done.

Yeah, have experienced this also, and I think there are competing interests between "best engineering option to get the product out fastest/most efficiently" and things like "hiring" and "getting investment funding"

Using the latest and greatest buzzwords helps greatly with hiring and getting investment (it's a positive feedback loop that just feeds itself and increasingly adds pressure to make those decisions).

> A major reason applications get bloated is because development time costs the company more than client bandwidth and CPU do.

If development time was really the biggest issue then I think we'd be seeing far fewer SPAs and complicated frameworks along with many more drag and drop VB apps or simple cgi sites, especially on internal tooling for small-medium companies. These also generally perform much better.

But between developers wanting to work on more exciting things and PHBs wanting sexier looking apps we end up with the current nightmare.

> It's a selection made based on weighing the constraints and options and selecting the best one. If poor application performance started costing companies a lot of revenue, I'm sure the result of the calculation would change.

This is not often the case, where even senior level engineers at FAANGs end up selecting tools based on their personal tastes with complete disregard for long term maintenance and operational costs.

I’ve seen projects with 6 different LISPY languages to solve the most trivial problem, including a couple developed in house.

I’ve seen all kinds of complexity from people choosing a random design pattern and using it to solve literally every problem. Recently I came across a code base where every call to every other class uses the visitor pattern... just because.

I’ve seen teams building internal platforms that picked one of most unknown languages for their customer teams to write business logic in... only because the senior engineer is an expert. These folks want other teams who have no background in this language — literally their main customer — to write production quality code, understand its nuances and write idiomatic code.

You’re placing too much faith in PMs or any of these management functions having a worthwhile role technical decisions, especially ones they don’t understand and don’t have time to disambiguate.

I’ve been at three different FAANGs where teams are literally drowning in idiotic decisions of some clown devs before them who invented technical complexity solely for the sake of getting promoted and then moved onto other teams. It’s not just devs... I’ve seen engineering managers sit comfortable and let people make dumbass decisions. They celebrate the new launch with beers or champagne but then leave within a couple months after because they know operational costs and escalations meant they’d get an unlubed pounding with a 2x4.

And it’s not just at FAANGs - I commented on a Ask HN thread a few days ago where the poster asked what’s the best stack for web development. Without a single blink, every other post was some random framework the commenter likes working with - never mind any nuanced discussion of functional or non functional requirements or even beginning to think about support or organizational alignment.

I can attest to this problem. I like to call it, the "architect" who never sticks around. First, this guy gets rewarded for getting a project rolling and showing results as quick as possible. Second, he will get no reward (nor satisfaction) for sticking around. The company also seeks to reproduce point one, long term results are drowned. Rinse and repeat.

Refreshing to see even FAANGs have to deal with this. I guess it's like politicians in the government. Same problems everywhere. I dealt with this in nearly all the companies I worked for.

> I don't think engineers use frameworks because they think it makes them look cool.

They don't. They use frameworks because it reduces the cost of production. Unfortunately, they accomplish this at the cost of the user experience.

> Unfortunately, they accomplish this at the cost of the user experience.

This doesn't follow. At business startup frameworks provide a huge boost in user experience through code re-use.

Perhaps it provides a boost in the initial development. But the applications that I've seen and used that use frameworks almost always provide an inferior user experience when compared to those that don't.

You say unfortunately, I say "lowering the cost of production means lower costs to consumers, and/or more valuable stuff getting created".

Everything is a trade-off.

I say unfortunately because the product quality is reduced as a result. So yes, we have may have more stuff, but most of it is seriously substandard.

This may be a positive thing for some people. It's a negative thing for me, though, because it increases the difficulty of finding good solutions, and reduces the number of good solutions that exist.