I think performance simply just isn't on the radar of a big chunk of devs these days, especially self-taught ones. Front-end wise, what with the trend of using frameworks (react/vue/etc) & a billion lines of javascript downloaded from npm, it'd probably be too much of a task to even begin profiling.
IMO it's unfair to blame the developers. Almost every developer I know loves working on performance stories. It's one of the few times we get to use our deeper technical and algorithmic skills and get a clear metric to optimize for. However, businesses are reluctant to prioritize that work and get impatient when they don't see new "features". I worked on a project where PMs would constantly complain to me about a particular admin page being slow. I wrote a ticket for them that would implement some optimizations (simple pagination and SQL optimizations) and asked them to prioritize it. They had time to complain every chance they got, but the ticket never got prioritized. I eventually got so sick of the complaining that I just took a Saturday morning and did it.
I dunno, I run into a lot of devs on reddit/here/etc that argue "who cares about performance just spin up more containers! I just wanna write {insert slow interpreted language here}."
I think you're reading that the incorrect way, though it's hard to say. This is my take on it
Dev: I get paid for writing features. I can write new features faster in {insert slow interpreted language here}.
Also if the company is of any size, whatever they write has to fit in the rest of their CI/CD stack and pass whatever kind of code review the company does or doesn't implement. So yea it's easy to say devs suck (and they do), but without looking at the entire process they are involved in it can be very hard to qualify why they suck and where the suckage comes from.
The slowness of interpreted languages is frequently not the main culprit for slow performance though. Most load times in web apps I've worked on usually were spent doing inefficient or unnecessary DB queries or API requests.
Almost every single time I've had to deal with something being slow in the Python web app I work on, it's been a bad query, or bad ORM usage spawning thousands of additional queries to pull in relations.
I've seen a couple out-of-memory deaths (mostly non-paginated db queries, but compounded with the inefficiency of py2), and occasionally an accidentally quadratic loop (which would be faster in C, but usually can just be made fast in Python with more thoughtful code), but it's almost always the DB—oops, I need to add an index, oops I did a cross join, oops, I'm spawning additional 10 queries for each row returned. The time spent in Python on a slow endpoint is usually negligible.
This is the claim but it isn't necessarily true as often as it is claimed. If it was how would Stack overflow back in the .NET framework days have managed on I think 2 web servers plus a failover on the massive amount of traffic they do while also being responsive. There's 0 chance a python/ruby/etc web app could have done the same thing. And to think they could theoretically use less CPU and RAM on the same workload now running in .NET 6 which is dramatically more efficient than 4.x Framework.
> I think performance simply just isn't on the radar of a big chunk of devs these days, especially self-taught ones
My experience is the opposite of this. It's usually the self-taught devs that care a lot about performance, and the formally educated ones who are willing to trade it away.
I'd almost split it out slightly differently, but I work indirectly with a lot of peoples code problems and this is just my own observations.
People that are formally educated tend to end up in large organizations based because HR like the idea of college degrees. Large organizations are process oriented. Somewhere above the dev the specification of the application is created. The dev typically does not get to choose their tools, instead particular versions of the tools are provided, the versions of the libraries they need to target and so forth. Also after the code is written it needs to pass any number of tools and gates and QA systems and UAT systems before it's ever used in production. In general the last thing the dev is thinking of is 'is this fast' and instead they are thinking "I have 400 things on my to do and I hope this doesn't get bounced back to me"
Some projects have performance as it's core proposition. Notably Solidjs, Astrojs, Qwikjs, among many others.
React has dominated the front end for years now & brought some great innovations, but it's dominance is waning.
> performance simply just isn't on the radar of a big chunk of devs these days
Many devs seek to optimize for career prospects. Since the majority of FE jobs center around React, these devs focus on React. As companies prioritize FE performance, the jobs related to performance follow & the mass of FE developers follow after that.
As a "one of these day devs" I only care about performance when it starts becoming a problem and I see nothing wrong with the way I'm going about this.
> I see nothing wrong with the way I'm going about this.
The wrong part is that you don't measure performance. Which was OP's point. Just measuring the performance is very hard, labor-intensive, resource-intensive task. "One of these day devs" mostly don't even know how to approach this task, but even if they knew, the mountain of infrastructure they sit upon, which is in many cases completely opaque to them will make it impossible for them to be productive (or do anything at all) when it comes to estimating performance of their programs.
Add to this also the fact that most things when it comes to performance are, basically, out of your control. If the problem is in the framework -- maaaaybe you can replace / patch the framework. If the problem is in the browser -- with a 0.1% probability you might convince users use another browser. If that's to do with OS in which the browser is running -- well, you, yourself, probably won't install a different OS only to make your own program happier...
But, the complaint isn't about the "one of these day devs", it's about the infrastructure in which they live that made it, basically, impossible to care about performance.
The problem is that performance and reliability are issues that creep up and by the time they're a problem, they are much more expensive to fix than if they had been first class priorities from the outset. Everyone who didn't care before finds new reasons to put it off because now it's so expensive to address.
Performance issues are also often trivial to head off from the beginning but require a rewrite to remediate later.
To everyone that argues that premature optimisation is bad, that’s like saying we should go to the Moon by building a bus and then fixing any performance issues that prevent orbital insertion after it is moving down the highway successfully.
