HTML, JS, Java... these things have their uses, but efficiency is not their forte. When you get to big designs, it's hard enough to keep native software snappy,
Actually, for some time now good JITs reach the performance of native, e.g. completely compiled ahead of time, software.
There are several reasons software written with a language with an underlying JIT can still appear slower:
1. Startup time, size and other resources needed by the interpreter and JIT.
2. The overhead until a JIT has finally kicked in and done the job.
3. Sloppy written code.
much less trying to achieve graphics-heavy performance with interpreted or JIT languages.
Most electronics CAD stuff is not even graphics-heavy. Like rendering a schematic or a 2D PCB.
But lets say it is. The issue has become more and more an issue of hardware, aka GPUs, their specific APIs, like OpenGL, the language-specific binding of the API, and, once again, talent and skills of the programmer. It is typically not a problem of a JIT language.
To give you an example where JIT-based, graphics-heavy, code is routinely executed fast: Graphics-heavy games on Android. Java as a language, compiled to Java bytecode, then translated to Google's own Dalvik bytecode, plus, depending on the setup, also pre-compiled optimized Dalvik bytecode, executed on the phone by the Dalvik virtual machine, which has a JIT and might generate and cache optimized Dalvik bytecode on the fly.
Or to give an example where a completely ahead compiled EDA program is dead slow: KiCad schematics rendering. The reason for that is it is badly programmed. You don't have to have a JIT-language to write bad code. Even PCs in the 80th had enough CPU power to render these lines. AFAIK KiCad is now moving to OpenGL to speed things up.