Am really not convinced by all this talk of react being performant: just doing some performance testing and found it took 3 seconds to set a Boolean variable…
🇳🇱
@rlamacraft did you make sure you did some burn-in first (set and unset the boolean variable several times, then start the timer and set it for real).
You may be measuring initial load time and not the time to set the boolean.
@freemo I think what I’m measuring is an absolute tonne of third party JavaScript cruft. I can’t think of any reasonable justification for why any code-executing runtime should take 3 seconds to set a Boolean variable unless that bit of memory is sitting in orbit
@rlamacraft Yes you probably are, but my point is most of what your measuring likely is a one time expense that occurs the first time you call certain parts of the libraries after a page load.. After that it wont likely be so expensive.
If you do burn in before benchmarking you will likely measure a more realistic number as those few seconds should be a one-time deal.
What is the time the second third and 100th time you set the variable? Is it really 2 seconds every time?
@freemo If I set the same value immediately after it drops down to something reasonable, but if I alternate the value being set it stays up around a second, and every time the function is invoked it’s always up at multiples of seconds; I don’t think it’s the JIT or anything. I just need to really understand what all these libraries are doing under the hood to propagate the changed values to the rendered view and how they’re attempting to optimise changes to the DOM
@rlamacraft I dont do enough functional programming to really make a good case, but i have done some, mostly in haskell. From what expiernce I do have, I agree, functional programming is much harder to make performant than OOP.. .on the flip side of that though is that functional programming is much easier to parallelized across multiple cores than OOP. For that reason it may be that at least on the backend, functional programming makes sense if your thinking in terms of scalability and over time may become the dominant technology.
@freemo Yeah, the more exotic runtimes of languages like Haskell and Prolog certainly have their place. I’ve worked on a proprietary FRP system (though they didn’t call it that) in the finance industry but that was for overnight batch processing. Very good for modelling dependencies between variables and, yes, where parallelism is hugely beneficial (Erlang comes to mind), but it’s applying it to time sensitive applications that doesn’t make sense to me. And that’s not to say all functional languages aren’t predictable; PureScript is just like Haskell but without the lazy evaluation and is just as predictable as vanilla JS, but most trade it off for other benefits
@rlamacraft Every task has its tools.. I would never say one language is a good choice for everything. So if functional languages arent food for real-time apps but great for bulk-processing apps that no more unusual then any other language.. I wouldnt use python to do GPGPU programming or ruby to do an enterprise webapp either.
@freemo So I’ve managed to get the assignment down to consistently 40ms by abstracting the code that renders the variable… (still high but it’ll do)
This is why I don’t see the point of functional reactive programming in building time sensitive systems because behaviour is unpredictable when data dependencies aren’t co-located — much prefer the traditional OOP approach of getters and setters, myself