4 ms·

performance isn't great, though: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benc

performance isn't great, though: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...

infogulch 9y ago
Overall the slowdown is 3.3x, but in memory usage it places third and in startup time it's in the top 10, and both of these are only about 1.1x slower than the fastest. I wonder how many cases would give a better UX to have the smaller, faster to load library.
- komali2 9y ago
  What does "startup time" mean compared to "usage"?
  - hvidgaard 9y ago
    The time from you enter the URL to you have landed in a usable state where you can use the site. For something you keep open all day, like email, general performance matters. But for things you use once or twice for 5 minutes, startup time matters a great deal more compared to the former.
    - komali2 9y ago
      Damn I never thought to consider the actual framework's startup time - just our own app.
- nonsince 9y ago
  It's not better UX for the end-user if the app is slower. It's not acceptable to make your life easier as a developer in trade for making a worse app. If the developer ergonomics lead to more features then it may be a good trade-off, but there are too many cases where people will trade performance to make their life easier.
  - estsauver 9y ago
    I think there's obviously trade offs to be weighed, but really? You hand write assembly? I'm assuming you hand inline all your functions? UX is one of three hundred things programmers have to weigh when making decisions for a business or project.
    - mbaha 9y ago
      1.1x faster navigation-UX by the way.
  - vbezhenar 9y ago
    0.1ms reaction time and 10ms reaction time would be instant for a human, so you definitely can make your life easier with reasonable performance trade-offs.
    - infogulch 9y ago
      Under 16ms is one frame so anything less than that would be equivalent (modulo battery life), but that example is a factor of 100 slower. In reality this would look more like 0.1ms vs 0.4ms, or 1ms vs 4ms.
  - infogulch 9y ago
    "slower" by what metric? It seems like you're ignoring the user's bandwidth, latency, and memory usage. We're talking about a library that is a factor of 100 smaller. That's 100x less code to transfer, parse, store, and optimize. My claim is that for the user's benefit it may be better to choose a library that sacrifices some benchmark performance metrics like "Time to update the text of every 10th row for 10000 rows with 5 warmup iterations." in favor of startup time and memory. These are the exact same tradeoffs that Seth Thompson mentioned in the video, they can't just be dismissed wholesale. My question is: how many real apps should make this tradeoff for the smaller library? I would guess "many more than make it now." Developers are wooed by the columns with a lot of pretty green (myself included) and end up making their app worse because they're optimizing for the wrong thing.

performance isn't great, though: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...

infogulch 9y ago

Overall the slowdown is 3.3x, but in memory usage it places third and in startup time it's in the top 10, and both of these are only about 1.1x slower than the fastest. I wonder how many cases would give a better UX to have the smaller, faster to load library.

komali2 9y ago
What does "startup time" mean compared to "usage"?
- hvidgaard 9y ago
  The time from you enter the URL to you have landed in a usable state where you can use the site. For something you keep open all day, like email, general performance matters. But for things you use once or twice for 5 minutes, startup time matters a great deal more compared to the former.
  - komali2 9y ago
    Damn I never thought to consider the actual framework's startup time - just our own app.
nonsince 9y ago
It's not better UX for the end-user if the app is slower. It's not acceptable to make your life easier as a developer in trade for making a worse app. If the developer ergonomics lead to more features then it may be a good trade-off, but there are too many cases where people will trade performance to make their life easier.
- estsauver 9y ago
  I think there's obviously trade offs to be weighed, but really? You hand write assembly? I'm assuming you hand inline all your functions? UX is one of three hundred things programmers have to weigh when making decisions for a business or project.
  - mbaha 9y ago
    1.1x faster navigation-UX by the way.
- vbezhenar 9y ago
  0.1ms reaction time and 10ms reaction time would be instant for a human, so you definitely can make your life easier with reasonable performance trade-offs.
  - infogulch 9y ago
    Under 16ms is one frame so anything less than that would be equivalent (modulo battery life), but that example is a factor of 100 slower. In reality this would look more like 0.1ms vs 0.4ms, or 1ms vs 4ms.
- infogulch 9y ago
  "slower" by what metric? It seems like you're ignoring the user's bandwidth, latency, and memory usage. We're talking about a library that is a factor of 100 smaller. That's 100x less code to transfer, parse, store, and optimize. My claim is that for the user's benefit it may be better to choose a library that sacrifices some benchmark performance metrics like "Time to update the text of every 10th row for 10000 rows with 5 warmup iterations." in favor of startup time and memory. These are the exact same tradeoffs that Seth Thompson mentioned in the video, they can't just be dismissed wholesale. My question is: how many real apps should make this tradeoff for the smaller library? I would guess "many more than make it now." Developers are wooed by the columns with a lot of pretty green (myself included) and end up making their app worse because they're optimizing for the wrong thing.