4 ms·

"Keys are unnecessary" in what way? The only reason they are necessary in React etc. is to keep DOM mutations to a minimum. Are keys unnecessary because you alw

by Timon3 3y ago

"Keys are unnecessary" in what way? The only reason they are necessary in React etc. is to keep DOM mutations to a minimum. Are keys unnecessary because you always re-render the whole list, making for very inefficient updates?

tipiirai 3y ago
True. When the array changed, the view is indeed re-rendered. Nue is probably not a good pick ATM for UI's with hundreds of rows and when list re-rendering performance is critical. I'll add the key- support if this becomes a frequent issue.
- lucideer 3y ago
  > if this becomes a frequent issue This becomes a frequent issue in any app at scale. If your app is at a small enough scale that it doesn't run into this issue, I would not recommend using a framework: just use vanillajs &/or some modular utility components. If you're working on a small app & want to do it in a framework because you anticipate scale, use one with key support.
  - tipiirai 3y ago
    Hardly a frequent issue. I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 — that all needs to be completely changed in one operation without re-rendering. It's a common theme in benchmarking apps though, which will ultimately be the main reason for adding the key support.
    - latchkey 3y ago
      > I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 I do. You've now disqualified this entire framework over a single issue, number of items in a list.
      - tipiirai 3y ago
        This is so demotivating. I wasn't prepared to this large downplaying of Nue.
        latchkey 3y ago
        You're trying to upset the applecart by saying your "framework", which has been developed in relative isolation, is better than the other top 4 contenders. Well, you better have some hard proof of that. Saying that you don't use lists, isn't helping.
        lucideer 3y ago
        There's a few elements to understand here: 1) In general, in the open-source community, there's a LOT of JS frameworks and many of them have caused developer frustration. This has lead to people being generally more skeptical of ANY new framework, just because there's so many & its considered a saturated space, so critique will be more strict. 2) With JS taking over as the "everything language", there's also some general backlash against JS itself. 3) On HN, this is even more pronounced for some reason. However, apart from the above, most of the negative comments seem to just be direct replies to certain claims you've made on HN (keys unnecessary & the ES6 DSL): there aren't as many negative comments on the actual submitted website. Personally I quite like it - I particularly love the narrative history lesson & to-the-point inline examples; you're a great communicator. As for thte library, there's elegance in simplicity, & while the framework may not be practical at the moment for some applications, there's still value in using software that is essential grokkable.
        tipiirai 3y ago
        Thank you lucideer! Great, kind points. Made me feel better.
      - tipiirai 3y ago
        I was talking about the applications I personally use frequently, like Slack for example. Unlike the parent said that "this becomes a frequent issue in any app at scale", I just don't see this happening on the UI's I personally use. Having said that: they key-optimization thing will be implemented. The more frequent issues get a higher priority. Maybe it's this one.
    - paradox460 3y ago
      This comment section on HN has more than 100 items in a single view.
- Timon3 3y ago
  It's not just about performance, although that is of course a big part. What if I have child components with state that I don't want re-rendered? Suddenly I have to track the state in the parent to keep it from disappearing on every array change. This has big architectural implications, and it worries me a bit that you only see it as relevant for benchmarks.

by Timon3 3y ago

tipiirai 3y ago

True. When the array changed, the view is indeed re-rendered. Nue is probably not a good pick ATM for UI's with hundreds of rows and when list re-rendering performance is critical. I'll add the key- support if this becomes a frequent issue.

lucideer 3y ago
> if this becomes a frequent issue This becomes a frequent issue in any app at scale. If your app is at a small enough scale that it doesn't run into this issue, I would not recommend using a framework: just use vanillajs &/or some modular utility components. If you're working on a small app & want to do it in a framework because you anticipate scale, use one with key support.
- tipiirai 3y ago
  Hardly a frequent issue. I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 — that all needs to be completely changed in one operation without re-rendering. It's a common theme in benchmarking apps though, which will ultimately be the main reason for adding the key support.
  - latchkey 3y ago
    > I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 I do. You've now disqualified this entire framework over a single issue, number of items in a list.
    - tipiirai 3y ago
      This is so demotivating. I wasn't prepared to this large downplaying of Nue.
      - latchkey 3y ago
        You're trying to upset the applecart by saying your "framework", which has been developed in relative isolation, is better than the other top 4 contenders. Well, you better have some hard proof of that. Saying that you don't use lists, isn't helping.
      - lucideer 3y ago
        There's a few elements to understand here: 1) In general, in the open-source community, there's a LOT of JS frameworks and many of them have caused developer frustration. This has lead to people being generally more skeptical of ANY new framework, just because there's so many & its considered a saturated space, so critique will be more strict. 2) With JS taking over as the "everything language", there's also some general backlash against JS itself. 3) On HN, this is even more pronounced for some reason. However, apart from the above, most of the negative comments seem to just be direct replies to certain claims you've made on HN (keys unnecessary & the ES6 DSL): there aren't as many negative comments on the actual submitted website. Personally I quite like it - I particularly love the narrative history lesson & to-the-point inline examples; you're a great communicator. As for thte library, there's elegance in simplicity, & while the framework may not be practical at the moment for some applications, there's still value in using software that is essential grokkable.
      - tipiirai 3y ago
        Thank you lucideer! Great, kind points. Made me feel better.
    - tipiirai 3y ago
      I was talking about the applications I personally use frequently, like Slack for example. Unlike the parent said that "this becomes a frequent issue in any app at scale", I just don't see this happening on the UI's I personally use. Having said that: they key-optimization thing will be implemented. The more frequent issues get a higher priority. Maybe it's this one.
  - paradox460 3y ago
    This comment section on HN has more than 100 items in a single view.
Timon3 3y ago
It's not just about performance, although that is of course a big part. What if I have child components with state that I don't want re-rendered? Suddenly I have to track the state in the parent to keep it from disappearing on every array change. This has big architectural implications, and it worries me a bit that you only see it as relevant for benchmarks.