4 ms·

I really wish developers would move away from talking about performance as a benefit of using their libraries. Pretty much all libraries are "fast by default",

I really wish developers would move away from talking about performance as a benefit of using their libraries. Pretty much all libraries are "fast by default", especially in the trivial examples that library devs tend to publish to show off their work. No matter what library you use, if your app is slow it's probably not the library. When performance is a part of the marketing naive developers move to it expecting their app to magically stop being slow because they used the fast library!. 99.99% of the time the libraries they were using before weren't the bottleneck and moving to a library that's faster doesn't actually solve the performance problems in the application's logic. If the app gets faster it's usually because they removed the slow bit as part of moving to a different library. If you build an application that's genuinely slow because of the library you're using to pass data around, rather than the way you're using that library, I will eat my hat, your hat, and many other hats. In fact, I will adopt an entirely hat-based diet.

mfbx9da4 4y ago
But some libraries are not build with performance in mind and libraries like [momentjs](https://momentjs.com/ https://momentjs.com/) have proved to be performance bottlenecks on many occasions.
- robertlagrant 4y ago
  That's why we have day.js!
Kiro 4y ago
Game UI in the DOM. When you need to update something 60 times a second all performance matters.
- davedx 4y ago
  I’ve built web games. Don’t bother trying to render the DOM 60 fps, it’s unnecessary. Render your actual game with canvas and use regular react for your UI. If for some reason your UI needs to render that often, move it into canvas too.
  - Kiro 4y ago
    Pretty strange to call it unnecessary when it's magnitudes easier to build the UI in in the DOM than re-implementing it in canvas. Yes, the UI needs to update that often because every game tick there are a lot of numbers being updated (think colony simulator). It works so not sure what the problem is or why I would change it.
    - davedx 4y ago
      If you're talking about things displaying numbers in real-time, it's not magnitudes easier to do it in the DOM, that's a gross exaggeration. If you're talking complex form controls then maybe, but I wonder what kind of game would have complex form controls that also need to be rendered at 60 fps. In my experience anything that needs to be animated should be done with canvas, otherwise at some point you're either going to hit performance walls or end up fighting the DOM.
      - Kiro 4y ago
        I'm not talking about displaying just numbers. Bars, numbers, animated things with shadows, filters and tweens. All trivial to do in the DOM with CSS while making it from scratch in a canvas (not using any engine) would be extremely cumbersome. And even if it's just text that's explicitly something you shouldn't do in canvas if you care about performance: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/... > Avoid text rendering whenever possible. So then I'm forced to create rendered font glyphs and use tooling for the texture atlas when drawing characters. Again, much easier just overlaying an element and do it in the DOM.
- onion2k 4y ago
  Every website, web app, browser-based game, etc should be nailing 60fps. That's the baseline minimum framerate for web software in my opinion. However... window.requestAnimationFrame in browsers (which is what games will be using to manage their main loop in the background) matches the refresh rate of the display. If you're looking at a game on a a laptop that's 60Hz, but if you're looking at it in a VR display it's probably 90Hz, or on a top end flagship phone it might be 120Hz. Games, even games written in React, manage to do this quite easily so long as the dev doesn't screw it up. You definitely don't need a 'faster state library' to do it well.
  - 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.
- capableweb 4y ago
  > Game UI in the DOM. When you need to update something 60 times a second all performance matters. What sort of Game UI has to be updated 60 times per second and would be implemented with something like React? In-game UI like healthbars would be implemented in canvas/webgl or whatever you use for the game itself. The UI around the game can be implemented as DOM and overlayed, but rarely have to be updated 60 times/second
beaker52 4y ago
Agreed. I once worked with an engineer who seemed to have dedicated their career to reducing bundle sizes. I think it's easy to do things like this in the name of "better" because they're measurable. I'd advise that if you've not accumulated Gandalf levels of experience yet, or you genuinely don't really need to reduce bundle sizes, or eek out an extra 10ms of execution time, your energies are best focussed on creating better software for users (here's the important bit) _that doesn't hurt the developers who'll need to modify it in future._ Why? Because bad code compounds in cost. When you make a decision and write code, it always results in other tangential decisions to need to be made in future. If your decision makes future decisions harder, they're more likely to be wrong. And then it makes all the tangential decisions after that likely to be even harder. Compounding, like interest, but the bad kind: debt. So it's far more valuable to invest your time in learning to make inoffensive decisions than to go swapping libraries or trimming bundle sizes in the name of kilobytes. On that front, it's more noble to choose a framework because it makes the pit of success as wide as possible, helping even the least skilled engineers make changes that are simple to change, fix or undo when needed, than to save 30ms per user, only to lose it because someone screwed up because of some bad code you wrote in one of the features.
- 411111111111111 4y ago
  You're just flat out wrong. The original point is correct, all modern frameworks have comparable performance, which is why the app will perform similarly, no matter which framework was used. However, bundle size has a direct impact in loading speed and there are multiple thresholds where even kilobytes can matter. The only time you can ignore it is if your users will exclusively access your website from a direct broadband connection.
  - deleted 4y ago
    [deleted]
  - beaker52 4y ago
    To some people, loading speed is everything. My experience has taught me that it is not. I work on web apps and I've learnt from experience that optimising software for simplicity and ease of change over a few milliseconds or kb is far more valuable than a lot of people would have you believe. Your users will barely notice a few kb or ms. But your colleagues do notice software complexity. Your stakeholders do notice delivery times. Your directors do notice costs. And ultimately you'll notice your share value. That said, you might benefit greatly from fine tuning your bundle sizes and library choices. But what I'm saying, is that maybe you'd make a different choice if you take the time to consider the broader activity of software development.

mfbx9da4 4y ago

But some libraries are not build with performance in mind and libraries like [momentjs](https://momentjs.com/ https://momentjs.com/) have proved to be performance bottlenecks on many occasions.

robertlagrant 4y ago
That's why we have day.js!

Kiro 4y ago

Game UI in the DOM. When you need to update something 60 times a second all performance matters.

davedx 4y ago
I’ve built web games. Don’t bother trying to render the DOM 60 fps, it’s unnecessary. Render your actual game with canvas and use regular react for your UI. If for some reason your UI needs to render that often, move it into canvas too.
- Kiro 4y ago
  Pretty strange to call it unnecessary when it's magnitudes easier to build the UI in in the DOM than re-implementing it in canvas. Yes, the UI needs to update that often because every game tick there are a lot of numbers being updated (think colony simulator). It works so not sure what the problem is or why I would change it.
  - davedx 4y ago
    If you're talking about things displaying numbers in real-time, it's not magnitudes easier to do it in the DOM, that's a gross exaggeration. If you're talking complex form controls then maybe, but I wonder what kind of game would have complex form controls that also need to be rendered at 60 fps. In my experience anything that needs to be animated should be done with canvas, otherwise at some point you're either going to hit performance walls or end up fighting the DOM.
    - Kiro 4y ago
      I'm not talking about displaying just numbers. Bars, numbers, animated things with shadows, filters and tweens. All trivial to do in the DOM with CSS while making it from scratch in a canvas (not using any engine) would be extremely cumbersome. And even if it's just text that's explicitly something you shouldn't do in canvas if you care about performance: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/... > Avoid text rendering whenever possible. So then I'm forced to create rendered font glyphs and use tooling for the texture atlas when drawing characters. Again, much easier just overlaying an element and do it in the DOM.
onion2k 4y ago
Every website, web app, browser-based game, etc should be nailing 60fps. That's the baseline minimum framerate for web software in my opinion. However... window.requestAnimationFrame in browsers (which is what games will be using to manage their main loop in the background) matches the refresh rate of the display. If you're looking at a game on a a laptop that's 60Hz, but if you're looking at it in a VR display it's probably 90Hz, or on a top end flagship phone it might be 120Hz. Games, even games written in React, manage to do this quite easily so long as the dev doesn't screw it up. You definitely don't need a 'faster state library' to do it well.
- 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.
capableweb 4y ago
> Game UI in the DOM. When you need to update something 60 times a second all performance matters. What sort of Game UI has to be updated 60 times per second and would be implemented with something like React? In-game UI like healthbars would be implemented in canvas/webgl or whatever you use for the game itself. The UI around the game can be implemented as DOM and overlayed, but rarely have to be updated 60 times/second

beaker52 4y ago

Agreed. I once worked with an engineer who seemed to have dedicated their career to reducing bundle sizes. I think it's easy to do things like this in the name of "better" because they're measurable. I'd advise that if you've not accumulated Gandalf levels of experience yet, or you genuinely don't really need to reduce bundle sizes, or eek out an extra 10ms of execution time, your energies are best focussed on creating better software for users (here's the important bit) _that doesn't hurt the developers who'll need to modify it in future._ Why? Because bad code compounds in cost. When you make a decision and write code, it always results in other tangential decisions to need to be made in future. If your decision makes future decisions harder, they're more likely to be wrong. And then it makes all the tangential decisions after that likely to be even harder. Compounding, like interest, but the bad kind: debt. So it's far more valuable to invest your time in learning to make inoffensive decisions than to go swapping libraries or trimming bundle sizes in the name of kilobytes. On that front, it's more noble to choose a framework because it makes the pit of success as wide as possible, helping even the least skilled engineers make changes that are simple to change, fix or undo when needed, than to save 30ms per user, only to lose it because someone screwed up because of some bad code you wrote in one of the features.

411111111111111 4y ago
You're just flat out wrong. The original point is correct, all modern frameworks have comparable performance, which is why the app will perform similarly, no matter which framework was used. However, bundle size has a direct impact in loading speed and there are multiple thresholds where even kilobytes can matter. The only time you can ignore it is if your users will exclusively access your website from a direct broadband connection.
- deleted 4y ago
  [deleted]
- beaker52 4y ago
  To some people, loading speed is everything. My experience has taught me that it is not. I work on web apps and I've learnt from experience that optimising software for simplicity and ease of change over a few milliseconds or kb is far more valuable than a lot of people would have you believe. Your users will barely notice a few kb or ms. But your colleagues do notice software complexity. Your stakeholders do notice delivery times. Your directors do notice costs. And ultimately you'll notice your share value. That said, you might benefit greatly from fine tuning your bundle sizes and library choices. But what I'm saying, is that maybe you'd make a different choice if you take the time to consider the broader activity of software development.