RetroV: TodoMVC example
Back to the RetroV main page.
One of the first things I’ve done with RetroV is implement the canonical single-page application test.
(View the source of the example page to see how it’s built. Everything but the CSS is in a single file.)
What makes TodoMVC (todomvc.com) great is that it has all of the painful little details that make writing real interfaces so difficult. Take a look at the innocent-looking Application Specification (github.com).
The interface has tons of nasty logic and it makes use of all sorts of
mouse and keyboard events. It even requires "routing" (detecting URL hash
changes) and persistence via localStorage.
Getting all of the details right means writing tons of edge case code. It’s also a great way to learn about the common browser API pitfalls your library will have to deal with. I added two new features while implementing TodoMVC and I’m much more confident that it can be used for most common UI scenarios.
Framework comparisons
I think it’s really interesting to compare library and TodoMVC implementation file sizes. It’s not a contest, but it does speak about the relative merits of the "weight" of features.
This article by Ryan Carniato (dev.to) compares the library (or runtime) and TodoMVC implementation sizes for five popular frameworks.
I’ll take Ryan’s list and see how RetroV compares:
+---------+----------+------------+---------+ | | Library | Todo impl. | Total | | | (bytes) | (bytes) | (bytes) | +---------+----------+------------+---------+ | RetroV | 869 | 1440 | 2314 | | Svelte | 1850 | 1880 | 3730 | | Solid | 3860 | 1260 | 5120 | | Preact | 4390 | 1210 | 5600 | | Vue | 16890 | 1100 | 15990 | | React | 36220 | 1230 | 37450 | +---------+----------+------------+---------+
(Note that the article uses Brotli (wikipedia.org) compression for all files, which yeilds a smaller minified RetroV than the old standard Gzip size you’ll see me use elsewhere. Nice!)
My TodoMVC implementation was the second largest after Svelte (which has been "compiled" to JavaScript). I believe what we’re seeing is that the other implementations had larger frameworks, but were able to have less application code.
If that’s right, the simplicity of RetroV (which has just a single
render() method) has a trade-off: there’s less convenience methods and you
have to write your own. I’m sure I could have been clever and "golfed"
my implementation down quite a bit, but I think this is realistic for a
tiny example.
Over a larger project, you’d be able to start re-using convenience methods and common interface patterns, so the application sizes would probably more-or-less converge across implementations.
It’s probably also worth mentioning that RetroV uses no build tools. All sizes are raw vanilla JavaScript as written by the developer and ready for use in the browser. (Minification and compression is only needed for apples-to-apples file size comparison.)
Again, it’s not a contest and RetroV isn’t "winning" anything. It’s smaller and it does less. But I feel confident in saying that it definitely has a very good power-to-weight ratio and it definitely has a tiny learning surface (just one external method) to match it’s file size.