Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT.
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
It will also increase power consumption because your CPU has to do more work to run the same code.
you are talking about the effect, not the cause.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
Agree. Chrome should just disable JIT by default and boom many website owner will start to optimize their website.
jira and confluence come to mind...
I suspect the people who agree to buy Jira & Confluence are not particularly heavy users of them. At least, that's the only explanation I can fathom for their continued sales.
Is it their app’s features that are slow, or the analytics bolted on top?
Both. And all the dependencies of both are slow. And the dependencies of those are slow, too.
> SPAs will be slow no matter what.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
At this point SPA pretty much implies React. But even if you optimize everything the best you could and avoid any third-party runtime dependencies, it's still going to be significantly more work to make API requests and do client-side rendering vs just rendering HTML server-side.