You can program efficiently in js. Just maybe drop the fat framework that dynamically checks each and every of your assigned variables to update other hidden functions (and maybe the dom) and avoid dragging things through N functions for "encapsulation" reasons and other inefficient OOP principle application.

what I want to say is: cough javascript developers cough

(for reference: I am a js "fullstack" dev)

In terms of performance, bad code is bad code. There's nothing about OOP that inherently results in non-performant code. Like all things, one needs to know what they're doing and, more importantly, what their compiler/runtime is doing.

For example, anyone that has been using OO in a non-GC'ed language for a reasonable amount of time will know that it's bad news to constantly create and free small objects due to the MM overhead. However, I constantly encounter JS-heavy web sites/apps that a) become slower as you use them and use an inordinate amount of memory, and b) really thrash the GC because they simply don't pay attention to allocations at all and constantly use constructs that result in one-off allocations that then need to be recycled.

The fact is that the browser and the DOM is a UI layer, and UI frameworks fit perfectly when implemented using OO architecture.

It's not that simple. My impression - I'm not very knowledgeable about this - is that JS and others started getting around as fast (in best conditions and a lot of voodoo) as unmanaged C code, but they are still behind in terms of memory footprint. For embedded applications, where you may be forced to count every KB of memory and every CPU cycle, the JITted systems are simply not a good fit right now.

You certainly can write a JavaScript implementation which would work in an embedded environment (just found one: http://www.espruino.com/ - it actually looks pretty nice! I wonder how it compares with Arduino?), but, when coughing JavaScript, it most often means "JavaScript as currently implemented in the four most popular implementations" or similar.

So, while it's true that you can write JS code that's 1000s of times more efficient than some bad JavaScript, it's also true that even the good JS is not going to be fast enough for some domains.

This (among others) is where AOT-compiled, GC-less (or with special implementations of those) come in. And even then, there are applications where even the cheap, mostly-compile-time abstractions of such languages prove to be too clunky and you need to drop down to assembly (bootloaders, demos, parts of OSes or language implementations).

So, while you can write efficient JS code, it's not going to be efficient enough for many cases.

Your assessment is definitely sufficiently true, although I would argue that, looking at how v8 essentially increases speed down to just twice the time of a comparable C program (as opposed to a magnitude or two) it is worth the convenience it brings to the table for devs (though c++ 11 and later catch up quite a bit)

cough https://twitter.com/rbanffy/status/950784408482648066/photo/... cough

Back in the day some devs said JavaScript devs weren't real programmers but script kiddies. I wonder how much of this came from wanting legitimacy? They were like, ok let's see how Java devs do it. Next thing you know the JS devs are also using 75 layers of abstraction.

cough massive amounts of javascript form multiple sources of which the page only needs 10% *cough"