The Burning Man App is coming along. What started out as a proof of concept playing with the data has gradually moved towards becoming an actual web app. The journey of building it has been taking me through some adventures (if we can quite loosely define 'adventure' here as 'source code' and 'articles about code'). (Also, it's to the point that I'm going to have to choose a name, and I don't want to run afoul of copyrights / trademarks. The Burning Man App is a good working title, but probably not for release.)
A few new things I have learned:
There is a whole ecosystem of virtual DOMs.
There are tons of web application frameworks in active use and development, not just React and the Angulars.
Lighthouse is a thing.
Page Speed Insights is a thing.
Given the nature of the app, I'm probably* going to have to use a framework that supports a virtual DOM. Page Speed Insights reports that it contains over 3,000 elements (stating that less that 1,500 is desirable). This is undoubtedly because of the SVG that comprises the Black Rock City map, which, besides the infrastructure of the city itself, also contains icons representing 308 artworks, 1,299 camps, and 3,374 events!
This will necessarily require some optimization though, because, while desktops and fancier smart phones can handle all that, under-powered phones and tablets crawl. The app doesn't really need to display all of the events at once, either. I can also probably insert icons only as the user zooms in, and only within its viewport.
I'm still not ready to pull the trigger on a full-blown framework, yet. I'm peering closely at Vue.js, but we'll see. Not sure why I'm so reluctant to wade into React. It would be good for my professional development to at least be familiar with it, but as this app is a labor of love, I want any technology to fit with what I want to do, rather than trying to fit the app into some mismatched box. To those of you who already know a framework, including my future self, it may be hard to understand this hesitancy. But remember: learning a framework takes an investment of time and energy; time and energy spent learning a framework is time and energy not spent developing the app; not spent with family and friends; and, at the end of the day, your app is now married to a community and ecosystem that may or may not be a good match. A divorce is costly. Apps also require maintenance, and if it has been some time since using that framework, and the framework you've chosen badly is unintuitive, then you will have to spend time relearning (on some level, this is my reluctance with React: everything - javascript, HTML and even CSS appears to be jumbled all up together in JSX). There are pros, of course, but those are some of the cons.
I have committed to using Redux, however, at least for the user interface. Keeping application state in a single object to which all elements refer makes a lot of sense. The app will be able to store that state, as well, so that the user can return to the app as it was. It will also be much easier to integrate a framework when the time comes.