Comment by lowercased
4 years ago
Flawed in what sense? I don't doubt that there are some conceptual drawbacks, and this only benchmarked chrome, not other browsers. I do think there's some utility in relative comparisons that have a standard/fixed baseline, as it would still seem to show what overhead a framework/library brings to the table.
FWIW, my initial impression of imba is that it's very impressive. I do think you rightly point out that, at this point, it may still be hard to leave larger ecosystems of react/vue/etc. DOM/UI speed of the project's JS toolkit generally has not been any meaningful impact in the projects I've worked on in the last several years - the data size and audience and app space just don't really call for it. However... as my needs change, imba will be something I'll revisit. Thank you.
> DOM/UI speed of the project's JS toolkit generally has not been any meaningful impact in the projects I've worked on in the last several years
Maybe you're the exception among your peers or something, but I'd wager you're wrong. Benchmark or no benchmark, imba.io and the site for Scrimba are way snappy. In contrast, when I find myself having to derp around on a landing page or a UI made with React or contemporary frameworks, I can feel the bloat. Is it possible that being elbow deep in this stuff has dulled your senses?
Not sure how you got from this that I was saying that there's no different between react and imba, or that it's not snappy/fast.
I was just saying that for the majority of LOB apps I'm working on, whether a table of 2000 entries renders in .2 seconds or .3 seconds has no meaningful impact on the client projects I'm working on. Even though it's a 50% slowdown, or 33% speed up, depending on how you measure, that speed difference has no impact on these projects. If we got up to 20000 entries, and we were hitting 2sec vs 3sec, that might be noticeable and something to address.
> Not sure how you got from this that I was saying that there's no different between react and imba, or that it's not snappy/fast
And I'm not sure where you got that I got that you were saying that.
What I am saying is a direct challenge to what you wrote—no need to repeat yourself. I'm saying, positively, that the common standards in React projects produce bloat that is perceptible—in cases I had in mind, FWIW, that are even more trivial/lightweight, by comparison, than the example of 2000 entries you're relating here.
That you consider a threshold on the order of 2 seconds as beginning to be worthy of something that might need to be addressed is significant. It reveals a fundamental difference in our expectations of software. That "no impact" 0.3 seconds figure is already itself eons in CPU time.
(This isn't generic anti-JS, anti-Web sentiment, by the way. In the early days of developer.mozilla.org—up until 2008 or so—I poured a lot of effort working on the JS documentation to make sure high quality docs would be available to a wide audience, so that even more people might pick up JS, which wasn't taken very seriously at the time. That's also, though, why I bristle at the state of React and frontend development—it has sowed the idea that JS, or maybe just software in general, has to be inherently slow and bloated. The average modern Web project on modern mid-range hardware is more top-heavy and perceptibly less snappy than the Electron-style applications like Netscape, Firefox, etc. from 15 years ago, which ran unJITted on sub-Ghz machines.)
1 reply →