Observe fonts to prioritize content. Handle repeated visits with sessionStorage

[jeremenichelli]

A note before starting with what's inside this PR. I'm not completely happy with the code, basically because antwar doesn't help a lot with above the fold styles and javascript and font strategy technics, so if this PR doesn't go further I'm totally fine and I will consider doing this again if we migrate to other content managment generator or strategy.

What's happening here? I'm replicating a technic I've used in other static sites, you can read more about it here: https://jeremenichelli.github.io/2016/05/font-loading-strategy-static-generated-sites/

I'm observing the font change when the site mounts and in case sessionStorage indicates the font is already cached the className is changed in advanced overhead.

One of my concerns is that I don't know how antwar is gonna handle this global code related to the site, because my choice would have been to create a new entry with font face observing code only being loaded when needed, something I couldn't do.

Locally, look at the screenshot on bottom left from dev tools, it really works since instead of this text-less page on first paint:

User might be able to get this system font text screen:

And when fonts get available they will switch to this:

I will wait to see what build says, but as I mentioned before I don't feel 100% confident about this.

[skipjack]

@jeremenichelli yeah I see where you're going with this and I like that we want to do more in terms of optimizing the site performance/experience. However there's also something to be said about complicating the codebase (which already pretty convoluted imo). This is kind of been my feeling in general re the dev work discussed in #1525 and #1400 -- meaning I'd much rather do things to clean up the codebase like finish #980 and hit any cleanup-like tasks mentioned in those issues (e.g. the changes in #1490) before we start adding a new things.

The blocker for me so far has been that at the end of the day the site's content should take priority over everything else imo. No matter how performant we get this site, if the content isn't well thought out and better organized than we still are left with a bad site (all be it a fast bad site 😆 ). For this reason I've spent the most of this year trying to address the large backlog of content-related issues we had open.

The good news is that this work is nearing completion and starting to be much more manageable with the recent wave of help that we've gotten. Now we're down to ~20 issues and I'm hoping we can keep it that way. With the content more under control and people continuing to review and improve it, we should be able to get the infrastructure cleaned up and then start making some improvements.

By the way, I'm not saying we have to hold off on all infrastructure improvements, just ones like this where it feels a bit dirty and we could probably come up with something cleaner once the repos in a better place.

[jeremenichelli]

All understood and I have the same opinion about the priorities and original mission of this site.

I will close this pull request since I myself don't feel confident about getting this code to master. But it might be a good place to start thinking on a change for the future. I love React, I think is a powerful tool, but using it for everything like static sites doesn't feel super right in my opinion. For example here, when you are trying to accomplish some static content first approach.

It might be good to take a look at Next if we want to stick with React for example, or take a look at some static site generators, there are a lot out there working well on production. Also to simplify the DX, that for a static site is really complex in my opinion.

That way we might be able to make content first citizen in this repo.

[skipjack]

I will close this pull request since I myself don't feel confident about getting this code to master. But it might be a good place to start thinking on a change for the future.

Definitely, feel free to leave the branch around.

I love React, I think is a powerful tool, but using it for everything like static sites doesn't feel super right in my opinion. For example here, when you are trying to accomplish some static content first approach.

It might be good to take a look at Next if we want to stick with React for example, or take a look at some static site generators, there are a lot out there working well on production. Also to simplify the DX, that for a static site is really complex in my opinion.

So first of all, I totally agree the infrastructure of this site definitely needs work and developer experience (I'm assuming that's what you mean by DX) really needs to be simplified. We have a plan for some things, like markdown processing, but other things like build process we haven't discussed too much yet.

I think React can be a good static site generator but the setup that we have now is definitely not ideal imo. I think the biggest point of confusion has been the Interactive components, which are used because antwar doesn't do true SSR (server-side rendering) while other generators like Phenomic and Gatsby do. This makes it easier to bind events, import css, and prevents some of the duplicate bundle issues we've been running into.

To antwar's credit, @bebraw has given us a lot of freedom in terms of updating it to cater to a nice solution on this site. The problem has been that @bebraw (nor I) has had the time to make certain updates to the tool and even just managing content and development issues on this site is tough. There's also certain changes (like full on SSR) that @bebraw doesn't want to add to antwar as it will complicate what is now a fairly simple codebase.

I, and others I think, have also played around with the idea of a port. I do think Next.js might be a good option and potentially Phenomic or Gatsby could be as well. I did do a bit of testing on right after the v1 releases of Gatsby and Phenomic and had a lot of trouble with the provided examples for both.

I think we're close to getting #980 merged which will at least fix some things and put us on the latest version of webpack, antwar, and a bunch of other packages. From there, I think we can more fairly evaluate a port and talk about the pros and cons of each. There's just a lot of moving pieces with this site so I just want to get a good plan together before we dive into anything. Rushing a port could leave us in an even worse position than we are now.

That way we might be able to make content first citizen in this repo.

This is really what @bebraw and I have always discussed trying to get to. If we keep our build process and functionality fairly simple and externalize as much as possible to other packages then we can keep the focus on well organized and well written content. Which, at the end of the day, is what the users of the site need from us.

[jeremenichelli]

@skipjack yes, I agree with basically all stated. Just to be clear I'm not against using antwar, I just think there are better options for this specific type of site.

Of course any port would a major change which should be widely discussed by all members. I'll be around to collaborate with team on both topics, content and infrastructure 🎉

[skipjack]

Just to be clear I'm not against using antwar, I just think there are better options for this specific type of site.

Yeah I understand. We just need to weigh our options, list out the pros and cons, and pick something that makes the most sense for this site.

I'll be around to collaborate with team on both topics, content and infrastructure.

👍