Two popovers on this blog are *REALLY* f-ing annoying to say the least. When looking at more than once a day, extra so.
If I want to share, I'll copy the address bar, or find a way. If I want to subscribe, I'd probably figure that out too. You're reaching a technical audience and these types of engagement patterns are a distraction to say the least.
I would suggest a fixed box in the lower right with a the standard share glyph/icon and a subscribe with an email glyph/icon. When clicking one of those, then have the popover dialog come up. NOTE: make room for it when scrolling to the bottom so it doesn't interfere with your footer.
----
row-reverse isn't the same as right alignment, it reverses the direction. justify-content on your #3 would be how you would align right.
Other than that, decent writeup.
With the advent of sessionStorage and localStorage, this isn't a very good idea... cookies are sent on every client-server request, and this doesn't seem to be meant for server usage at all. Cookies should be kept to a bare minimum, not sore session state.
I would suggest most that haven't already start looking at the `--experimental-modules` flag that node proper is working on including. The behavior is a little different, and it's a good idea to get an understanding of both.
[comment deleted]tracker1 2311 days ago. link 2 points ▲▼
This project does not have a license assigned to this project, meaning nobody can/should even look at it.
Yes. There are a few conserns. Regarding @misan's points. You can write accessible react and you can add the same structure and attributes since in the end it does render HTML to the DOM.
As to SEO, it's not really much of a hindrance. I've worked in a couple larger sites and hosting environments and 5-7 years ago, Google was only a few days behind in computed detection vs. static rendering and can only assume it's much closer to actual today. Bing also does computed renders for content. Beyond this, SEO doesn't actually help much these days compared to general marketing efforts.
You can server-render and cache React, there are lots of tools for this from Next.js and other frameworks. Walmart has written and released a lot of tooling in this space. Again, I don't think it's that worth it most of the time, but ymmv here.
Where I would concentrate is using webpack's analyze options to pay close attention to your gzipped payload size. Ideally you want to stay under or around 500k. Which is not hard, I'm working on a pretty complex web application and it's around that with React and Material-UI libraries taking up the bulk and about 25% actual application code beyond that. For comparison, Grubhub is about 442k for their initial (not logged in) JS payload and over 2MB on a fresh load logged in (Angular I believe).
If you're more content driven (blog, resume, etc) I would tend to favor a static content generator such as gatsby mentioned by @misan.