Learning Javascript

I haven't posted anything on here in a long time. It should come as no surprise that the pandemic has eaten up a big chunk of my schedule. I was overbooked prior to the pandemic. The need to move two classes to a new format, and learn and incorporate into my teaching new forms of technology, has been challenging.

Act I

Last week I dug up an old script (from 2018?) I had written while deepening my Javascript beyond the occasional copying of a few lines of codes off the internet. It was a static page generator contained entirely in one html file, requiring no server, no command line interaction, nothing but the single html file. You enter text into a box on the screen in markdown format (complete with equation support). There's a live preview below the text entry box. When you're done, you click the button and download it to your computer. I'm pretty sure the goal was to have something that could be directly uploaded to a Github repo for display on a Github Pages site.

I'll post a link when I make the html file publicly available. It still needs a little cleaning up, including the removal of personal information, before I can share it.

Act II

Over the weekend I decided to get a better understanding of modern web development by figuring out how to write a single-page web app. I was largely familiar with old school CGI apps. They're dead simple. You can learn all the "server" parts in 20 minutes. You then return text output based on the URL. CGI programming is just regular programming with external data.

Considering that I'm not a web developer, that's more than I need to know. My curiosity tends to get the best of me, however, and I had no choice but to figure out how to write a web app that communicates with a server but never reloads the page. So I set out to write one of the single page apps that can be used to manage a directory of markdown files and a few other things inside a repository (Git, Fossil, or otherwise).

I wrote the backend in D using Adam Ruppe's cgi.d. In spite of the name, it has an embedded http server that can be run locally to respond to requests on the local filesystem.

The frontend (I think that's what the kids call it these days) is in Javascript. I learned about fetch, which is both simple to use and beautiful in the functionality it provides. I had heard of fetch before but it was limited to copying a single line of code from a stackoverflow answer. I used URLSearchParams to create a URL that can be used for a GET request. I learned async and await to deal with promises. In the end, I had some functionality working. I had a sidebar with a listing of all files, could display and edit existing files, create new files, and preview files.

While this is functional, it doesn't do anything more than I can do better with various other tools, including a basic text editor. As a learning exercise, it was successful. As a tool, it provides no value at all in its current state. I just want to be clear on that last point because tool creation was not my goal over the weekend.

The project will continue. Some of the things I will do include:

• Figuring out XMLHttpRequest, which seems to be powerful but not as easy as fetch.
• Understanding promises.
• Adding tag support to allow easy querying of all files in the repo with that tag.
• Adding backlink support to query all files that refer to the current file. I'm not sure how useful that will be but it should be easy to implement and experiment with.
• Saving to localStorage and allowing recovery if the browser gets closed.
• Add file metadata support so I can add a description of arbitrary length to be displayed with individual files.
• Add a "timeline" where I can quickly enter project updates. One problem I have with Git repos is that there's no standard way to post updates. When I return to them later, I can't easily figure out the state of the project.
• Add an "inbox" to note things that need to be done or issues. This would differ from the timeline in that these posts would need to be queried, grouped, and archived.
• Rewrite the Javascript parts in other languages that compile to Javascript. Strictly speaking, there's nothing wrong with JS as a language, but there's also not much that makes me enthusiastic. I'd describe it as a "vanilla" language that does the same things as other languages but not providing anything that reduces the pain of programming. In that sense, the "Java" part of "Javascript" fits even if they are unrelated.

Everything will be handled in text files - no database. Standard Unix tools such as awk, sed, and grep provide the database functionality I need. My repos are small (a few hundred files at most). The advantages of no dependencies and having text files under version control with no overhead far outweigh any possible advantages of a database.

This remains a learning adventure. If I end up with a tool customized for my workflow that I use in the future, that's a bonus. I probably won't use it when it's written. That's okay with me.

Edit: It looks like I've played with ClojureScript in the past. I posted about it here. I don't have any recollection of that, and rereading the post, it looks like I didn't spend much time with it.