4 ms·

Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. Yes, of course you're using RA

by Kiro 4y ago

Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. Yes, of course you're using RAF for the game loop. Not sure of the relevance of that comment. I just said 60 to simplify things. > Games, even games written in React, manage to do this quite easily That's a really broad and generalising comment. All games are different. My way works but only because I'm using a library that is fast enough. Sure, maybe I should batch update calls and do all sorts of optimization techniques on my end, but why would I when I can just do it like this and focus on the core gameplay instead? Are you saying that libraries should not be performant in order to punish lazy developers like me?

onion2k 4y ago
Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. It is though. We've all used web apps where something doesn't nail 60fps and it's so jarring. I used one yesterday where typing in a textbox was laggy. WTF is the dev who made it doing when a textbox is slow?! This is the sort of problem that developers face and, if they're not great at their job, they reach for a library that claims to be faster rather than looking at their code to work out why it's slow. The impact of marketing something as "magically better perf by using this super special library!" is that developers stop trying to make things fast enough themselves. Worse, some people start believing all web apps are slow because the web must be slow by default if you need these clever tricks that only libraries can provide to be fast. It's nonsense. Browsers are pretty damn fast and if you encounter a webapp that's slow it's almost guaranteed to be the fault of the developers who made it and not the libraries it's built on. There is no library that a bad dev can't make slow software with.
- stagas 4y ago
  But there are libraries that a bad dev can make fast software with. You can accidentally make a laggy textbox in one framework more often than another, that's why what framework you use matters. The textbox is just an example, there are myriads of ways the DOM can behave badly without the developer having any intention and possibly the application layer logic is perfect. Each framework has its quirks. Do you optimize for correctness or speed? Does every update need to be 100% correct/consistent or can you allow it to drop updates? These are performance details that the framework should provide tooling to deal with, or it may not, and it may have abstracted away all these decisions and made it impossible to fix the textbox lag unless you hack into the DOM manually. Which framework you use matters a lot.

by Kiro 4y ago

onion2k 4y ago

Hitting 60 fps for a normal web app is usually not about actually updating the DOM 60 times a second. Two different issues here. It is though. We've all used web apps where something doesn't nail 60fps and it's so jarring. I used one yesterday where typing in a textbox was laggy. WTF is the dev who made it doing when a textbox is slow?! This is the sort of problem that developers face and, if they're not great at their job, they reach for a library that claims to be faster rather than looking at their code to work out why it's slow. The impact of marketing something as "magically better perf by using this super special library!" is that developers stop trying to make things fast enough themselves. Worse, some people start believing all web apps are slow because the web must be slow by default if you need these clever tricks that only libraries can provide to be fast. It's nonsense. Browsers are pretty damn fast and if you encounter a webapp that's slow it's almost guaranteed to be the fault of the developers who made it and not the libraries it's built on. There is no library that a bad dev can't make slow software with.

stagas 4y ago
But there are libraries that a bad dev can make fast software with. You can accidentally make a laggy textbox in one framework more often than another, that's why what framework you use matters. The textbox is just an example, there are myriads of ways the DOM can behave badly without the developer having any intention and possibly the application layer logic is perfect. Each framework has its quirks. Do you optimize for correctness or speed? Does every update need to be 100% correct/consistent or can you allow it to drop updates? These are performance details that the framework should provide tooling to deal with, or it may not, and it may have abstracted away all these decisions and made it impossible to fix the textbox lag unless you hack into the DOM manually. Which framework you use matters a lot.