A Quick Way To Evaluate Software Frameworks
One of the most impressive bits of #software I’ve used is #Python. When I started to learn Python, it was version 1.5, a long time ago. I was immediately impressed with the tutorial. It was the first port of call. Here it is now:
<https://docs.python.org/3/tutorial/index.html>
Read the tutorial basics and you could start exploring the language library
<https://docs.python.org/3/library/index.html>
knowing you could master enough to move to more advanced concepts. Want to do something more complicated? Say build a web server?
First you might try the #HOWTO pages trying #sockets:
<https://docs.python.org/3/howto/index.html>
After reading about the limitations you might try the #PEPS (Python Enhancement Proposal) What is a PEP? Try reading this page:
<https://peps.python.org/pep-0001/)
Finally you might decide #WSGI is what you want and read the specification at
<https://peps.python.org/pep-0333/>. I travelled this path in 2007/8 to build a version of my blog engine. 
<https://seldomlogical.com/redux.html>
So I go the latest build on #Deno, install it and try a simple blog engine to see how it works
<https://deno.com/blog/build-a-blog-with-fresh>.
The example code fails, the source code fails. I see the basic documentation for it (yet to try, but skimming through, it appears okay.) The tutorial only a couple of years old has rusted, the source is unmaintained. The issue is with JS / #React / #Preact where plain old #HTML5 and #CSS will do. 
A quick example how the basics have to documented, correct in bite sized pieces. The #HOWTOS maintained and blog #examples periodically revised.