Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: A New Implementation of the Seven GUIs Benchmark
4 points by graderjs 8 days ago | hide | past | favorite | discuss
7GUIs: https://github.com/eugenkiss/7guis

My implementation: https://i5ik.github.io/_____/7guis/

I built this after seeing Brad Woods' work on Show HN.

I wanted to do it because it was different to the other GUI benchmarks I had seen before such as RealWorld and Todo MVC.

I liked how the original author wrote the description of the tasks and the challenges they were supposed to try to address and I appreciated that design and usability thinking, as well as the chance to flesh out and test a framework for how it could handle this. I also knew that GUI programming was one of my weaknesses so I wanted to push myself to learn more.

The most challenging was Cells, and I procrastinated for a bit before getting into it. But actually the scripting side of that challenge was not as hard as just getting the markup right.

I was also building a web components framework at the same time and using these challenges to develop and test the features of that framework. The most challenging thing there was figuring out how to get a good load time without displaying partially loaded GUI components. Basically this man keeping track of a components subcomponent dependencies and and marking the ancestor component as loaded only when all it's dependents and it's uncontent was loaded.

In the case of cells which calls for 99 rows and 26 columns it ended up producing around 10,000 nodes which took quite a while to render in the browser and in my framework. It was a good chance to try to push the performance of that framework as far as it could go. A lot of time was spent in the performance tab of devtools.

Something else that was important was getting a good load time while maintaining responsiveness on the main thread render across a range of devices.

This was challenging because providing that responsiveness for lower end devices unavoidably sacrificed load time for higher spec devices that may not have had any lack of responsiveness at all. But I decided that I wanted responsiveness to be the priority and then to maximize the achievable load time given that constraint.

I achieved this by splitting up the work of the big render using a function to insert asynchronous sleeps between bundles of work.

The sleeps allowed the main thread to maintain some low frame rate of responsiveness while it completed the off screen rendering of the large component, without taking too long.

The current version of the demo uses a small Cells component just to save time. This will be my only comment on this thread, if you want more info you can check out the framework repository: https://github.com/i5ik/_____






Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: