My biggest issue, is that most apps need filesystem and network access these days. And the permissions aren't fine grained enough in terms of how they're limited.
If filesystem access could be limited to constrained directories and files via configuration for read-only and read/write, it would be a better option. Likewise, if network access could be constrained to specific IPs or named addresses with wildcard matching.
With those options to whitelist your resources, anything that tries to do otherwise (rogue modules), then the application can blow up with an error informing as much.
Personally, I've found that to a large extent, if you aren't a content driven site/app that the SEO portion is largely not going to be very useful. Also, Google and Azure are pretty quick to handle JS content changes (usually 2-3 days from past experience). If what you are building is more like an application, and you aren't selling products in a public facing way then you may not want to focus on SEO or server-rendering.
However, if you are largely content driven, or public facing sales driven you should probably go the other direction with pre-rendered content first, then add features as needed. It comes down to what your focus is on.
I've been split about half and half in my career between the two, and it really should inform your approach. The more SEO friendly your content needs to be, the more you should lean into a static first approach. Even if that means running multiple renders a day. If you're dealing with a lot of content, with lots of searchable options, and results that need indexing, you may want a light server to do your basic renders. If you're creating an application experience like chat, games or otherwise heavily interactive content, then don't worry about the server/seo render. Most of the businesses I've worked with rely on other sales channels and SEO has been a reduced influence.
Material UI is a component library, but it's not coming from google, it is an implementation of Google's Material Design (I don't know why this bugs me that people get it wrong so often).
Also, the other UI kit mentioned, I'm not even sure how it made the list. It's woefully incomplete. react-bootstrap[1] or reactstrap[2] would both be better options.
[1] https://react-bootstrap.github.io/
[2] https://reactstrap.github.io/
That works... though, probably my favorite datepicker (excluding the lack of sizing for phone/touch) is probably the UX for the Microsoft Ajax Toolkit (hate the toolkit, UX for dates is really good). When you click on the month/year title, you get a panel with each month in the year with prev/next, click on the title again, and you get a decade of years with prev/next.
https://ajaxcontroltoolkit.devexpress.com/Calendar/Calendar.aspx
About the only thing I'd do is tweak the styling a bit larger, and display it full screen for small/mobile devices (phone). I always thought it was a very intuative interface.
I made this one a few years ago... don't like it as much as the one above, but it's good for mobile use. The demo only shows 3 years, but it's in a scrolling field like the months. I should really break it up, and make it compatible with the material-ui library... as it is, it works standalone. Next time I need a date picker beyond the browser's date input, I'll probably revise it. Right now, I mostly just use <input type="date" /> and defer to the browser's UI.
https://github.com/tracker1/md-datepicker/http://tracker1.github.io/md-datepicker/
global.fetch = require('node-fetch');