Dear Recruiter,

I do not use React or Typescript anymore. I use the HTMLElement api, which is what was added to the specification to implement React. It is lovely, and let's me do beautiful things that extend HTML. It is almost Lisp like, almost classical. I previously used things like CoffeeScript, which had beautiful ideas like maps and list comprehensions that JavaScript has now incorporated into its features. CSS now has variables and simple calculations. I can, as I said, extend the HTML components with javascript now and use them like I would any other HTML Component.

In fact, my philosophy is that preprocessors for HTML, CSS and JS are to be considered harmful these days. They used to be essential to writing Javascript. They gave us access to enormous new parts of the language, let us reason about objects and the DOM in brand new ways. But the beautiful thing about the stack is that over the past few years it has evolved to incorporate these ideas into its core base. The bad part about preprocessors is they are fractured and ever breaking systems. The browser, when written for properly, is remarkably resilient to change.

My framework is HTML, CSS and JS served from a web-server of your choosing, and holy smokes it's good. In fact, it reminds me of COBOL. Grace Hopper, who wrote Cobol, understood that all communication took place across multiple channels. A COBOL program has several different streams of code happening throughout -- parts to manage memory, parts to execute commands, parts to comment. HTML, CSS and JS offers us similar multiple streams of information to express an idea.

Right now I can extend HTML to do things like:

<geo-map>
  <map-location>Content Here</map-location>
</geo-map>

And I can put together cinematic maps like this with it: https://lindseymysse.github.io/sunken-city-graffiti-park-proposal/proposal.html

This uses my component geo-map-component: https://map.garden

I see a lot of complexity added to front end development for no reason. GraphQL, as far as I can understand it, is a tool to solve a highly political business problem, and has now become an engineering requirement. This is, of course, silly. The correct answer to this particular engineering conundrum is to let the data scientists handle the business logic, the backend engineers write the REST API that indexes and serves it, and the front end engineers use nice, asynchronous javascript to weave it all together into a cohesive whole. But instead we get sheafs of design documents that we will get fired for commenting on and told this waterfall project is agile because we have a meeting every morning and we ship every two weeks otherwise the project's funding is going to get pulled.

There is a certain type of programmer who thrives in this environment. They love writing large amounts of code. They just LOVE setting things up. Oh, they'll have you spending money on servers soon (the executives are going to love it! shows movement!). But then adding features, pivoting features that don't make sense anymore, just gets slower and slower. Why? Because you've used a software framework to abstract away a business problem (how do we make decisions as a company) and then you keep adding to an ever more ornate set of commands to it.

Look at this beautiful thing:

That is several millions (perhaps billions?) of dollars of computation from the Baroque era.

And worthless.

You know why? It's a model of the solar system that doesn't account for arcs. Ol' Newton was still in Diapers when it was built, hadn't even begun to contemplate calculus

Certain frameworks pride themselves with reducing HTML, CSS and JS to a single conceptual thread to reason with, which at first glance sounds like a great idea, but it ultimately is the mathematical equivalent of looking through your front door's peephole instead of going outside. (literally here -- 1 thread, vs stereoscopic vision + time) .

So, I create HTML Components and reason about them in HTML. I carve out space for the backend guys and the data scientists to write javascript. I let junior devs focus on writing coherent HTML and CSS and parts of JS to weave these components together.

I don't have a problem with a highly automated deploy chain necessarily, but I've seen enormous amounts of servers and setup used for things that needed a $500 desktop and a public ip address to run well. Heroku is awesome, Amazon GovCloud with an EC2 instance that takes git hooks is beautiful. The thing I don't like about docker is that spinning up a VM to read documentation isn't normal, but on Docker it is. There is something about this idea (I'm not going to name the software project) -- that would ask me to spin up an entire server just to read their documentation, that says it hasn't been fully thought through.

Tests aren't ever going to replace someone who acts like a copy editor for a website. A lot of the power of using JS, HTML and CS directly is you find the edges of your architecture choices a lot sooner. A large complex architecture with lots of padding around sharp edges removes those quick, loud, app-crashing bugs for those silent, intermittent appearing and disappearing bugs. My philosophy: crash sooner.

I have an addiction to a snippet of javascript I wrote that I liken to cigarettes: https://lindseymysse.github.io/html-partial/html-partial.js

Any senior engineer is going to see 20 problems with this code. It doesn't run script tags, which would be the primary one. But what I like about this code is it doesn't run script tags. That means you can only reason about an HTML partial as a bit of <xml> or .css. With extensible HTML this lets us generate HTML that does a lot more than show a website. It's a snippet of Business Intelligence. For illustration, look at this page:

https://lnsy.studio/grampa-shmidt-on-garbage-collection/

This page uses this snippet to load an HTML file that looks like this without my added javascript:

https://lnsy.studio/grampa-shmidt-on-garbage-collection/two-stroke-engine.html

With the new method of HTML extension we can do things like have a details tag:

<details>
  <last-revised>
    Tue, Sep 14 2021 07:46
  </last-revised>
  <author>LNSY</author>
  <tags>
    <tag>grampa</tag>
    <tag>two stroke engine</tag>
    <tag>tree gas</tag>
  </tags>
  <qr-code value="https://lnsy.studio/grampa-shmidt-on-garbage-collection/two-stroke-engine.html"></qr-code>
</details>

When this is written I'm not just generating a pretty picture: I'm giving you a snippet of business intelligence. No JS to parse a tag? it fails silently. That information is still there, though.

But by forcing our business communications apart -- there is the public face, there is the internal communications, here is where the programmers talk -- we are losing enormous amounts of labor to replicated, disjointed, often conflicting work.

My preferred corporation would not be one where I built a website, but one where everyone in the corporation was building the website -- internal and external pages -- at every moment. I think a snippet of HTML code served in a bucket can run something as complex as a global bank more efficiently than the fastest COBOL server. As long as you reason about the HTML and intellectual labor properly as an organization.

A markup approach to entire business communications allows for distributed reasoning througout the entire organization. Already when we talk about document store databases like Mongo, we are talking about similar data structures. Parsing XML is a solved problem, so that information can be incorporated into the whole database and generated again easily. But most importantly: it is readable by human beings who can use their creativity and intuition to reason through certain problems a lot more quickly than any computer can.

LNSY