Comment by tipiirai
2 years 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.
> 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.
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.
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.
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.
4 replies →
This comment section on HN has more than 100 items in a single view.