Skip to content

Commit ff7907e

Browse files
committed
WIP blog post: Python Website Recipes
1 parent 250496a commit ff7907e

1 file changed

Lines changed: 171 additions & 0 deletions

File tree

Lines changed: 171 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,171 @@
1+
---
2+
title:
3+
...
4+
5+
I've already made a personal site with [GitHub Pages],
6+
but I'm still curious about all the other options.
7+
I'm really tempted to see how quickly I could replicate the original site
8+
with alternative solutions.
9+
Of course, if I'm really sincere in my desire to learn,
10+
I'd be well served to write about my experience.
11+
12+
At the moment,
13+
I'm most interested in static site generators,
14+
but I'd also like to try more conventional, "always on" solutions.
15+
16+
## Making Websites
17+
18+
So, the question is,
19+
how does one best deliver one's thoughts to another human
20+
through a web browser?
21+
22+
If the answer is "make a website",
23+
it's time to break it down into smaller pieces,
24+
because there are probably as many ways to make a website
25+
as are ways to open a restaurant.
26+
27+
A hypothetical restauranteur faces numerous choices:
28+
29+
- the choice of menu items,
30+
- the decor,
31+
- the kitchen equipment,
32+
- the behaviour of the wait staff,
33+
- the building location,
34+
- the customer parking,
35+
- locks and alarms,
36+
- and so on.
37+
38+
Similarly, a recipe for a website comprises:
39+
40+
- the selection of content,
41+
- the visual design,
42+
- the user experience design,
43+
- the document handling tools,
44+
- the server's programming languages (if any),
45+
- the HTTP server,
46+
- caching technologies,
47+
- the domain name and URL schemes,
48+
- security necessities such as SSL,
49+
- and so on.
50+
51+
The number of combinations of possibilities is understandably daunting.
52+
53+
## Overview of Website Architecture
54+
55+
The best way to grasp an overview of possible solutions
56+
would be to trace the path of information
57+
flowing between author and reader,
58+
and enumerate the variables potentially affecting that path.
59+
Let's trace upstream from reader to author,
60+
because there's little variability in the final legs of a web page's trip,
61+
and much variability in the middle and earlier.
62+
63+
The first web browser had originally been a simple viewing and navigating layer
64+
between human client and machine server.
65+
Early web servers did little more than to obediently
66+
deliver a file from disk over the network, upon request.
67+
With this simple system, there were few choices:
68+
69+
- Which document editor will you use to write the raw content of your pages?
70+
- Will the document contain embedded functionality
71+
for the browser to bring to life?
72+
- If extra, dynamic functionality is being created, what tools will do it?
73+
- To which web browser applications and versions will you cater?
74+
- How is the web formatted file produced
75+
before it's given to the web server machine?
76+
- How will you copy the file to the web server machine?
77+
- What web server software and operating system are on the server machine?
78+
- What web addresses will the site's pages use?
79+
80+
Beginning with this simple foundation, we get all possible combinations of
81+
what would these days be called "static websites".
82+
83+
### Static Websites
84+
85+
For static websites, all content is fully formed in advance,
86+
and the software or person responsible
87+
doesn't stick around to participate in
88+
minute-by-minute delivery to users.
89+
Instead, the pre-created website files go to a web server
90+
that's single-mindedly dedicated to the task of endlessly
91+
listening for requests and fulfilling them one after another
92+
with a transmission of the corresponding file.
93+
By the time any real world user visits a page on a static site,
94+
the original software that generated it is done with this process,
95+
and therefore cannot interact with visitors at all.
96+
97+
When I got started with making websites,
98+
this was the workflow for everyone involved:
99+
100+
1. I write content for later inclusion or conversion into HTML
101+
2. I make web-ready files: HTML (by copy-and-paste, mostly),
102+
and optionally CSS and JavaScript (if I felt ambitious)
103+
3. Deliver files to server or storage system used by server (probably by FTP)
104+
4. User requests page from browser, browser requests page from server
105+
5. Server delivers file to user's browser, browser displays or downloads file
106+
6. Repeat from step 4
107+
108+
#### Dynamic Features on "Static" Pages
109+
110+
That's not to say dynamism is impossible,
111+
just that there's no participation from
112+
the actual machine that sent the pages.
113+
Dynamic interaction can be achieved in the browser with JavaScript,
114+
and pages can even appear to change and those changes persist
115+
between visits by using local storage such as cookies.
116+
Furthermore, certain HTTP methods that are
117+
typically associated with classic HTML forms
118+
can send data to other machines,
119+
which can in turn do the remembering or computation
120+
your web server or user's browser doesn't do.
121+
For example, [Disqus] can store comments
122+
for any article published on a static site.
123+
124+
125+
#### Static Site Generators
126+
127+
There's a class of web publishing tools that specialize in getting
128+
authors through the first step of making web-ready files
129+
after the necessarily human part is done.
130+
This saves an author the trouble of working through technical matters,
131+
so the author's focus can be on producing content.
132+
Getting the files to a web server is sometimes feature of these systems, too.
133+
In some cases, the tool in question is already on the Internet,
134+
just waiting for your non-HTML content so it can neatly produce
135+
ugly-but-necessary files that look great in the browser.
136+
137+
- [GitHub Pages]
138+
139+
### Server Based Solutions
140+
141+
If you need your website users to be able to interact with your site while using the browser,
142+
some sort of machine needs to be ready and waiting to handle those needs.
143+
144+
- [Flask]
145+
- [Pyramid]
146+
- [Django]
147+
148+
## Choosing
149+
150+
When approaching the problem of
151+
choosing amongst numerous solutions
152+
it's best to start by paring away as many options as possible.
153+
154+
I can narrow down the solutions I'm most interested in
155+
if I take a narrow-minded point of view
156+
by eschewing languages other than those that are necessary.
157+
HTML, CSS, and JavaScript are nearly unavoidable on the web,
158+
unless one strives for utmost simplicity.
159+
160+
## Python
161+
162+
I'm in love with Python
163+
as a language for expressing information for humans.
164+
If I open my mind to include the fondly cherished Python,
165+
I increase my list of fun trials
166+
by a reasonably vast extent,
167+
without going hopelessly overboard.
168+
169+
[Flask]: http://flask.pocoo.org/
170+
[GitHub Pages]: https://pages.github.com/
171+
[Disqus]: https://disqus.com/

0 commit comments

Comments
 (0)