-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
128 lines (115 loc) · 3.84 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>The Single File Philosophy</title>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="description" content="The Single File Philosophy" />
<style>
*,
*::before,
*::after {
box-sizing: border-box;
}
* {
font-family: "Georgia";
}
body {
margin: 0;
min-height: 100vh;
text-rendering: optimizeSpeed;
line-height: 1.5;
font-size: 1.2em;
padding: 1em;
}
h1 {
font-size: 1.25em;
}
li {
margin-bottom: 1em;
}
pre {
white-space: pre-wrap;
margin: 2em 0;
}
pre,
.tag {
font-family: monospace;
}
.tag::before {
content: "<";
}
.tag::after {
content: ">";
}
</style>
</head>
<body>
<h1>The Single File Philosophy</h1>
<p>
Given the complexity of the web and how we build it nowadays, sometimes it
helps to remember that a single file can be capable of doing incredible
things. Create an HTML file, add your markup, maybe augment it with some
<span class="tag" role="text">style</span> and
<span class="tag" role="text">script</span> tags, and now you have a
self-contained and coherent site. How cool is that? The Single File
Philosophy focuses on fighting against unnecessary Complexity when it's
applicable. Of course, if you're collaborating on applications at Scale or
sites that have various Business Requirements, then this philosophy most
likely doesn't – and probably shouldn't – apply. However, there are cases
where we introduce Complexity to build our single-use web apps or side
projects for the sake of Convention. If we take a step back and see the
project for What It Is, you may realize that you don't need to follow
Convention. Everything you wrote can realistically fit into a lone
readable file and nothing more.
</p>
<p>
Benefits of this approach:
</p>
<ul>
<li>
<p>
Everything is in one place. There's no need to worry about file
structure and attempting to locate Resources, which can be influenced
by Personal Preferences.
</p>
</li>
<li>
<p>
Generally less Tooling. If you can fit everything in a single file
without it being a Burden, it's likely that you don't need much
Tooling to have it working. Tooling is meant for Optimization and
Convenience, whether it's for the Creator or the Result, but it can
also be a Barrier. We don't need more Barriers if we can help it.
</p>
</li>
<li>
<p>
An emphasis on Less Code. If your Intent is to keep a Maintainable
project within a single file and limit your use of Tooling, then it's
likely that you won't want to write too much to begin with. The
Inconvenience is the benefit here. You can do a lot with Less Code,
and we should be mindful of how we can make that come to fruition when
possible.
</p>
</li>
<li>
<p>Portability. Imagine the following conversation:</p>
<pre>
"Hey I love that site that you built. Would be great to know how you did that!"
"Thanks! I can send you the file that has everything you need to know. Or you can click View Source and read it."</pre>
<p>
This is Beautiful. The web is a content-first platform. Why shouldn't
the code that it's built on be part of that content too?
</p>
</li>
</ul>
<p>
Yes, this philosophy is pretty limited, and it will almost always only
apply to your small projects that you decided to build over the weekend.
However, sometimes it's nice to be reminded of how simple the web can be
and how a little can go a long way.
</p>
</body>
</html>