That is simply not true. To write fast JS you need to understand the basics of the engine, like what a hidden class is, what exactly garbage collector does, how to keep your methods monomorphic or how types work in arrays. I was stunned when recruiting people to see how many just didn't understand why the prototype chains they build are actually creating a separated method instance per each object they allocate. You can see that easily when serious people suggest that an object constructor should return another object with methods on it. Sure, it's valid JS, it has it's advantages and compiler MAY be able to optimize it (last time I checked it didn't), but there will be a limit in what it can do and performance will be impacted.

You should perhaps not optimize trivial things like methods vs function, because there is no good underlying reason for them to be much different. You should know when to optimize and what. I love the longer version of Knuth's quote - "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.". The overall architecture, the way you write and organize your code, in my opinion, and in case of JavaScript is likely to be in the 3%.

But I also agree not caring too much about it improves productiveness. Most applications really don't need to worry about performance in such depth. Even when they do, it often boils down to keeping one or two core components optimized.

The only worry I always have about it, is that when you notice your code style and architecture doesn't play well with JS engines, it's often too late to change it. A friend called me a day before a prod release asking what to do about his program taking a huge chunk of memory for what the profiler described as a "compiled code". It was a large corporate application, with dynamic code loading. We digged into the framework internals just to notice there was no built-in way of deregistering a class once it's created. Since it didn't play nicely with the JS engine, there were many more hidden classes than business models in the system, and most calls were polymorphic. All this compiled code had to be kept somewhere. At this point there was no way he would replace the framework and even quickly fixing it was a challenge.