Benchmark idea

[jayrbolton]

I was thinking about a benchmark that includes some trickier points that a lot of UI libraries do badly at, but which is important for large apps, and I don't think it's necessarily evaluated here. Namely, I'm talking about reusing, aggregating, and controlling dynamic collections of components.

Phase 1: Create a countdown timer

Properties:

• Buttons for start/stop and reset
• Take a duration as a parameter
• Counts down to 0 and stops

Evaluations:

• Managing states (running, paused, stopped, reset, etc)
• Asynchronous data handling
• Reusability -- you should be able to manually duplicate the timer in the window with different initial durations

Phase 2: A timer collection.

Properties:

• A button for "add timer" and a field for "duration" that adds a new timer onto the page with the given duration
• A button for "reset all" that resets all timers and stops them, and shows "start all" if all buttons are reset. If any one timer starts, then the button is changed back to "reset all"
• Some text that displays the total elapsed seconds of all timers so far, counting up.

Evaluations:

• You should reuse your code from Phase 1 without modifying or refactoring any of it (this is important).
• How well the system can control and aggregate data from a dynamic collection of sub-components

Just a discussion issue, feel free to close or label as you see fit

[devinivy]

@foxdonut I wonder if you might have some thoughts about this.

[drewnoakes]

I like the idea. A framework's ability to compose UI elements is critical to its use at scale.

An option is to add one more GUI that includes all the other GUIs, so the existing GUIs become componentised, and you can see their usages all in one place.

I was initially confused at the 'benchmark' reference. I thought you were aiming to compare framework performance, which is also an interesting idea.

[foxdonut]

I think it's a great idea, that's a good exercise.

I actually have most of this in one of my Meiosis examples, the Random Gif example.

The "Random Gif" is the component being reused. Under "Random Gif List", you have the dynamic collection of components. The "parent" component collecting data is the "Total Counter" at the top of the page.

This example also demonstrates composing and reusing components. That is, the "Random Gif Pair" is one component that is built using two instances of the "Random Gif" component, and then the "Random Gif Pair Pair" is one component built with two instances of the "Random Gif Pair" component -- without needing knowledge or ties to the inner "Random Gif" components, which are reused as-is.

[jayrbolton]

Hey @foxdonut, thanks for linking your example, I'm a fan of Meiosis. One missing aspect in the gif-list example is having a control that affects all sub-components -- eg. a "reload all" button. Another one is aggregating some data from all components -- eg. a global loading indicator that is true if one or more subcomponents are loading.

[foxdonut]

@jayrbolton excellent points! I updated the example to include these aspects. The "Random Gif List" now has a "Reload All" button, and it aggregates some data from the components in the list: it indicates "Contains one or more gifs: true/false" according to whether one or more components in the list has loaded a gif.

[jayrbolton]

Thanks @foxdonut for the example code. I might give a shot at the timer example in Meiosis if I have time at some point so I can get a better understanding of that system. If anybody stumbles on this thread, the link to the code is here: https://github.com/jayrbolton/snabbdom-statechart-components/tree/master/examples.

To nitpick more, I think part of the challenge should include aggregating state from all sub-components, updating the aggregate data when any of the sub-components change. This can be tricky. In the case of the timer example, disabling "reset all" if they are all already reset, and also counting total seconds elapsed, would include that. The global loading indicator is my only idea for the gif one.

I'm also playing with implementing the timer-list example with a frontend lib that uses statecharts and 'fractal' components, maybe you would find it interesting. The source code is here: https://github.com/jayrbolton/snabbdom-statechart-components/tree/master/examples

I might make a separate repo from 7guis called something like "timer-list-mvc" that describes the challenge in a lot of detail and has some example implementations, similar to what we have here.

[jayrbolton]

rough draft for the benchmark: https://github.com/jayrbolton/timer-list-benchmark

[eugenkiss]

@jayrbolton Thanks a lot for starting this discussion. I was never too happy with the Timer task in 7GUIs as it felt too artificial. A countdown app that also tests reusing of components would be a nice replacement for a successor of 7GUIs. Though it seems to me that your proposed benchmark is large enough to be its own dedicated benchmark. As an aside, I noticed the demo links in your README do not work.

[jayrbolton]

Thanks @eugenkiss -- the readme is just a rough draft so the links are blank for now.

I actually had an idea yesterday about how to make this kind of benchmark much more fun. A list of timers (or a list of lists of timers) is still a little contrived and dry. I was thinking instead it could be a looping drumkit. The project would provide a handful of drum sounds as small mp3 files

Phase 1: A single looper

• Select a drum sound from a dropdown
• Set a speed (beats per minute)
• Set a loop length
• Select some checkboxes in a row to sequence the loop
• Play/pause/reset buttons

Phase 2: full drumkit -- a collection of loops

• Buttons to add/remove loops
• Reuse the looper component without changing it
• Buttons to start and stop all loops
• Input to set the BPM for all loops
• Status text to show how many loops are playing.

Phase 3: drum battle -- a collection of drumkits

• Add/remove drumkits (whole collections of loopers)
• Set BPM for all drumkits, show status text for all drumkits, etc

Downside would be that there is some more overhead in implementing this because of dealing with playing audio files, and it's a little more complicated than just a countdown timer. But it'd be more fun.

[eugenkiss]

In general, the idea to make the benchmark less artificial and more practical/fun appeals to me. I believe the incentive to create an implementation is increased because at the end you'll actually have something to use/play with. Among other reasons, the practicality aspect is what I think makes TodoMVC and HNPWAs popular.

The downside is that the benchmark may become too complicated. If you restrict yourself to JS in the beginning, provide a JS utility library with functions for the sound manipulation and host the sounds yourself it might work. Though honest feedback: I personally would feel less inclined to write an implementation here than for, say, TodoMVC probably because it seems less general (more niche) and more involved than TodoMVC. But I might be an exception.