Browse Source

Update Modular Matrix site with design goals and misc fixes

Sven Slootweg 5 months ago
parent
commit
f1ce5dd64e
1 changed files with 30 additions and 2 deletions
  1. 30 2
      configuration/sources/modular-matrix/index.html

+ 30 - 2
configuration/sources/modular-matrix/index.html

@ -8,16 +8,44 @@
8 8
<body>
9 9
	<h1>Modular Matrix</h1>
10 10
	<p>
11
		<em><strong>NOTE:</strong> If you're looking for the Matrix website, go to <a href="https://matrix.org">Matrix.org</a>. If you're looking for the Matrix hosting service, go to <a href="https://modular.im/">Modular.im</a>. This project is not affiliated with either of those two.</em>
11
		<em><strong>NOTE:</strong> If you're looking for the Matrix website, go to <a href="https://matrix.org">Matrix.org</a>. If you're looking for the commercial Matrix hosting service, go to <a href="https://modular.im/">Modular.im</a>. This project is not affiliated with either of those two.</em>
12 12
	</p>
13 13
	<p>
14 14
		Hi! This will eventually be the website for Modular Matrix, a project to build a modular JavaScript SDK for the <a href="https://matrix.org">Matrix protocol</a>, as an alternative to the <code>matrix-js-sdk</code>.
15 15
	</p>
16 16
	<p>
17
		Currently there's not really anything here yet, though you can have a look at the <a href="https://www.npmjs.com/org/modular-matrix?tab=packages">already-published packages</a> if you're curious about how things are going.
17
		Currently there's not much here yet, though you can have a look at the <a href="https://www.npmjs.com/org/modular-matrix?tab=packages">already-published packages</a> if you're curious about how things are going.
18 18
	</p>
19 19
	<p>
20 20
		You can contact me on Matrix as <a href="https://matrix.to/#/@joepie91:pixie.town">@joepie91:pixie.town</a>.
21 21
	</p>
22
23
	<h2>Primary design goals</h2>
24
25
	<p>
26
		These are not the *only* goals, but they are the most important ones, and the ones that are most often overlooked in library design.
27
	</p>
28
29
	<ul>
30
		<li>
31
			<strong>Modularity.</strong> It should be possible to build weird experimental things that don't look like a typical Matrix client or server, without having to pull in a lot of complexity you don't need, or having to hack into SDK internals. Therefore, Modular Matrix primarily consists of a lot of small, single-responsibility modules, that can be used in isolation.
32
		</li>
33
		<li>
34
			<strong>Exhaustive documentation.</strong> There shouldn't be a single undocumented thing in the external API. All modules are <em>fully documented</em>; including examples, API reference, high-level concepts, and gotchas to watch out for.
35
		</li>
36
		<li>
37
			<strong>Readability.</strong> Ideally, it should be possible to learn the Matrix protocol by reading the implementation.
38
		</li>
39
		<li>
40
			<strong>Maintainability.</strong> It should always be possible to understand how the implementation approaches a particular problem, both from a high-level perspective and from an implementation-details perspective. It should always be obvious which part of the code to change, to correctly solve a problem.
41
		</li>
42
		<li>
43
			<strong>Reliability.</strong> Semantic versioning is followed. APIs are, where possible, designed in a way that is hard to misuse. All library errors have clearly distinct types and metadata, so that you don't need catch-alls.
44
		</li>
45
	</ul>
46
47
	<p>
48
		The common theme here is that Modular Matrix is designed to be <em>human-friendly</em>. It's not about clever technical hacks or micro-optimized implementations that exploit runtime specifics, but about creating a set of libraries that are <em>pleasant to work with</em> and don't yield unpleasant surprises.
49
	</p>
22 50
</body>
23 51
</html>