tunetheweb
commented
4 years ago The other option of course, is to have a "full" python server to generate the static pages at deploy time, and then a light version of the server (also in python?) to serve these "static pages" and add the dynamic content (redirects, headers, nonces, randomised pages...etc) as need be.
That could be more performant for most pages - thought that is added complexity (two servers) and not sure our full python server is that heavy anyway. I'd imagine (without any testing whatsoever to back this up!) that spinning up a light python server would probably take just as long as the full one.
@HTTPArchive/developers , another question for you.
This question has come up (again) with some chats with you and so I'm opening this issue for discussion.
Note: this has been discussed before in #634 and we closed this issue. I've decided to open a new issue, rather than reopen that last one, as that last one got a little sidetracked on other GitHub issues.
The Web Almanac is basically a static site, but has a full Flask-based Python engine using Jinja2 templates to display these pages. Some have suggested we should move to a purely static site, or alternative static site generators (e.g. 11yy or some other Jamstack), which would potentially simplify our site, potentially lead to a performance boost and also potentially lead to other hosting opportunities (e.g. hosting directly on GitHub).
From my point of view, I can see the arguments for and against, which I've tried to summarise below:
On the one hand, I would say it has the following areas for potential improvement:
On the other hand, what we have is working well, we've had no major issues or items that we can't support on the site and functionality has been relatively easy to add (personally I had no experience of Python, Flask or Jinja2 before working on this project but have contributed a huge number of changes to that code). The refactor of Python in #949 and #1176 has helped improved the Python code no end, and the templating system we have (although seemingly quite convoluted at first) does allow us great support of other languages.
Also, as I say the site is VERY performant and rarely scores below 90 on Lighthouse and much higher on simple pages like the home page (95-98 Lighthouse performance score). Given the size and complexity of some of the data in the chapters that is quite a feat! Of course I'd love to get 100, and we could get a higher score by inlining our CSS, reducing the number of fonts, or removing interactive visualisations, but not sure those are compromises we're willing to take. So, for now, I'm happy with the performance so I for one don't believe we have a performance issue to solve per se, or that a move in backend platform would have a material impact on this - see #638 for more discussion on this and things have improved further since then.
It should also be noted that the site is not static. In particular we have:
Maybe none of these "dynamic" items are deal breakers, and we could potentially live without some (or maybe even all) of them. Other platforms may allows similar level of detail, or we could work around them with front end code. However, we've tried to make the Web Almanac the best possible site we can, and to serve as example of how sites should be built. So personally I'd be against moving to something very simple like GitHub pages since we couldn't keep the level control of some of the server-side items to allow all of the above to still be supported. Though if there are considerable benefits to moving, and more than enough to offset these negatives, then let's hear them.
So there's a lot to like about our tech stack and I'm loath to move, just for the sake of moving (though personally I'd love to learn more about 11ty since it seems to be the hot new thing at the mo!).
And with that I'll open it up to the floor for discussion!
One final ask would be that you qualify any suggestions with what benefits it would bring to the project over our current tech stack (e.g. "I think we should move to X." is not that helpful, whereas "I think we should move to Y, because it would be easier to do..." is).