2023-04-23

• Listened: [[Soviet Cybernetics and the Promise of Big Computer Socialism]]

• [[Oddly Influenced]] podcast looks fun.

• Writing up thoughts on [[Internet for the People]].

• Really enjoyed the [[Ecological Radio Workshop]] put on by [[Full of Noises]] yesterday.

• Read: [[Chile's president aims to nationalize world's largest lithium supply]]

  • Not quite so radical as Allende (it'll happen when current contracts expire).

• Sunday, 04/23/2023 ** 20:14 Having trouble cooking. Having trouble socializing. Feeling mediocre. Hoping that the Dieter Rams book sitting on the table will make my work more beautiful.

Spent most of the day huddled in ilcaffe experimenting with my website. I think the look might be getting somewhere, but lots of infrastructural changes need to be made.

Thinking that completely static generation is the wrong paradigm; re-fetching all of the resources on every page and losing their state feels terrible. Ideally we compile to HTML fragments - i.e. component/file.{css,js,html} - and navigation rather than replacing the whole page with a new one, means replacing a part of the page with the new content. This would match the hot reloading paradigm better; we just have to be careful about state.

The second that a wrapper of a technology says that it isn't fully transparent, it's done for. Clojure's garden doesn't support all CSS selectors, so it's bad; even though it would be great to keep some data in Clojure, that would mean sacrificing potential future malleability. Clojurescript is a good abstraction in some ways - you can always dig into JS and all of its features - but having to convert between JS and Clojure imperative vs. lazy paradigms and adding a few megabytes to the page load in the meantime isn't worth it. We'll stick with JS until we have our own solution.

Clojure was a great choice for the static site generator though. No syntax or friction - just parentheses and functions. I can do whatever I want without pain. Something like nodejs would probably have been faster, but the experience of typing with those languages just isn't that fast. This'll pay off when we add component macros soon too - we'll be able to abstract better.

What should a terminal for a website do? I want to use it to prototype everything I want on my desktop. ** 21:35 Some ideas after looking into HTMX further:

• Components should be independent from the website at large. I should be able to open a URL associated with a component that has no (or some) query parameters provided and get back that component from the website.
• Components should also be composable. I should be able to return a page that contains many components, components that nest, or a page.
• Components should render on the server as one or in a group. Client-side components are far more complex to handle in most cases. A component should be a container of HTML, but that container can contain javascript that helps it to render.
• Components need arguments. They need data from other parts of the application to function. How they get this data - statically or dynamically, etc. - isn't super important most of the time, but sometimes (as with live data) it matters a lot.
• Components should feel like functions. I should be able to call them from a terminal with arguments and see them, just like I should be able to open them up in new pages.
• Components should have two ingredients: a function that converts inputs into structured data and a function that converts those inputs into a user interface that explains that structured data to users. This allows us to reuse components as data pipelines as well as for intermediate visualizations of their data. (This feels very node-based...)
• Components should map to URLs. Everyone uses the internet. How could other people use components if they weren't able to get to them with their web browsers? ** 21:44 and reading the hyperscript docs makes me see that the best form of JS is JS that manages locality properly. See https://hyperscript.org/comparison/: hyperscript is clearly not an extensible language, but its proper scoping hidden inside of HTML makes it clear why we want CSS modules, why globals are bad most of the time, and so forth... functions should be explicitly bound to templating where the templating is, not in a separate location and associated in your brain.

Associating A with B is the compiler's job. How can we make a component that handles this properly? ** 21:51 Trying to understand tailwind. I can see how it's fast if you have things memorized - it saves you characters to type - but it doesn't support all of CSS and it's not very readable, as you don't fully understand what classes it's adding to your code. With Github Copilot I can simply generate the CSS I need most of the time and correct it if it's wrong. Saving characters and optimizing for typing over reading is the wrong bet. I'm skeptical of tailwind's ability to be maintained long term.