It depends on what you're doing. Because DOM interactions are heavily textual (usually for no real reason), you end up with very slow operations like "http://element.style ['pointer-events']='none';" and when you have to do a lot of those (or things like it), you are very sad.
-
-
Replying to @cmuratori @NoHatCoder and
In general, JavaScript's "Who knows? It's just a giant hash map and you can add things at any time!" object model means that almost everything is very slow, and there's not much that can be done to speed it up without extreme JIT heroics.
1 reply 0 retweets 3 likes -
Replying to @cmuratori @NoHatCoder and
I'm sure there's no reason a competent JIT couldn't make a 128x128 update of just adding numbers together. But that's never what's actually happening, you're always dealing with something more complex than that, and it just rolls over and dies.
1 reply 0 retweets 1 like -
Replying to @cmuratori @Jonathan_Blow and
Right, the DOM is a shitshow, I'm not gonna say that JavaScript itself isn't, but it is a faster shitshow than most people know. Your example still sounds slow, but it is not completely beyond the expected. If you want I'll give you some pointers to avoid the worst of it.
1 reply 0 retweets 1 like -
Replying to @NoHatCoder @Jonathan_Blow and
I am actually pretty experienced with JavaScript :) Like I said, I optimized it just fine, and it's OK now. Unfortunately the browser can't really handle 16k DOM objects so it's unclear that I won't have to switch to canvases anyway, but that's a separate issue.
2 replies 0 retweets 1 like -
Replying to @cmuratori @NoHatCoder and
I don't think of JavaScript _the language_ as slow, I think of JavaScript _the object model_ as slow, and it is, pretty much period. If you just wanted to do basic stuff in JavaScript it's fine, even at high load, but if you want to work with structured data it falls apart.
0 replies 0 retweets 2 likes -
This Tweet is unavailable.
-
Replying to @fenomas @NoHatCoder and
The language definition for JavaScript doesn't permit you to do the things you would want to do to make things like style setting fast. Normally in a strongly typed language the JIT would know it could turn a elem.[string] = string assignment into direct code...
1 reply 0 retweets 6 likes -
Replying to @cmuratori @fenomas and
... but in JavaScript, it has no idea what that line means, because it doesn't even know what "elem" is. So the JITs have to resort to heroics where they try to analyze the code to figure out what can be safely turned into fast operations, and what can't.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @fenomas and
A sane scripting language knows this and designs in the minimal amount of "typing" necessary to ensure that you can still have easy-to-read things that a user types, but that the compiler can know definitively what they do. JavaScript fails completely here.
1 reply 0 retweets 5 likes
Normally you'd just be like "yeah, it's a rookie mistake, it happens". Kinda like with HTML and CSS. But sadly, HTML/CSS/JS, despite all three being rookie mistakes across the board, ended up running the top of the entire world's software stack. So that's where we're at :(
-
-
This Tweet is unavailable.
-
Replying to @fenomas @NoHatCoder and
Sigh. Since apparently nobody knows how this stuff works, I will go grab a performance capture to demonstrate :(
1 reply 0 retweets 2 likes - Show replies
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.