Hacker News Reader

Comment by tipiirai | Hacker News Reader

Keys are unnecessary in Nue, just like many, many other framework abstractions. If you receive another list from the server, Nue takes care of it automatically. No need for diffing.

View on HN

https://github.com/nuejs/nuejs/blob/a5c844494852cdbe3282fdc5...

Am I correctly reading that you just throw away and re-render the entire DOM?

"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?

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.

> 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.

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.

> 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.

This is so demotivating. I wasn't prepared to this large downplaying of Nue.

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.

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.

Thank you lucideer! Great, kind points. Made me feel better.

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.

I built an app that listed all 20,000+ of my blade computers on a single long page. They were arranged in a grid that mapped to the way they were racked in the data center, which made it super easy for a technician to get an overview of the status of the entire system. 12 blades per chassis and 1-8 chassis per rack.

The page took about 2-3 seconds to load (mostly downloading the json data to render the page), but once it loaded, it rendered and more importantly, updated very quickly as new data would roll in. If I had to re-render the entire dom every time there was an update, the page would have been unusable.

It feels like you can't see past your personal use case. You're trying to convince HN that your framework is better than the top 4 projects out there and HN is pushing back and saying... umm... no.

Note that Nue will probably work just fine for your use case. The list is not re-rendered when individual items on the list are updated or when new items are added. Currently only re-rendered when the whole list is sorted or replaced with a new one. Based on the feedback here looks like I need to optimize these two mass-operations as well.

I don't want to manage the list on the client side.

I just do a replacement of the data retrieved from the server, and it all magically works because the ID's don't change.

Indeed. It's rare to see real-world scenarios where thousands of items are mass-manipulated on the client side. They exist, but rarely. The lists are typically appended/prepended or individual items are updated.

> Indeed. It's rare to see real-world scenarios where thousands of items are mass-manipulated on the client side. They exist, but rarely.

I'm not sure this is correct. Almost all apps that I write that display live data are built by replacing the whole client-side array with updated server-side array data, and the other commenters seems to work similarly. With your current approach I'd have to write a complete diffing logic to modify the array in-place locally, especially if I don't want child components to be re-mounted.

This comment section on HN has more than 100 items in a single view.

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.

Reply on news.ycombinator.com