citrusui / me

The open source code that powers citrusui.me.

no

me's Issues

Add legacy/deprecated web pages

Leaving placeholders for broken links is nice, but not particularly useful. For example, I'd like to add proper links to old versions of my website (/about, /repo) dating back to as early as 2015. I don't plan on adding this old content to the repository directly, as it will make git pushes and pulls much slower. Instead, I will add the old content via a submodule or two, which will only be fetched when explicitly requested.

Most of this work could be implemented in #4. However, special directories like /repo and /packages will have to be served directly, rather than a separate subdomain. I do not like adding redirects unless they are absolutely necessary.

Move to Amazon S3

Firebase is awesome, don't get me wrong -- but it'd be even more awesome if I could deploy to S3 any time I push a commit to this repo. I'm thinking commit messages containing [push] will be routed through S3.

Still new to AWS, but it shouldn't be that hard! Just need to get off my lazy butt

Extremely lightweight version

I'd like to implement a script of some sort that generates extremely small web pages -- they should only contain HTML. Also, each page should have a meta viewport so they scale nicely on mobile devices.

So: no CSS, no JavaScript, and no images either. It won't look pretty, but it will load insanely fast (hopefully), and not obstruct the body content with the loading of scripts of CSS animations.

Inspired by https://danluu.com/web-bloat/.

Splitting the blog directory (again)

Porting the blog directory back to a submodule has a few advantages and disadvantages:

Note: core repo refers to https://github.com/citrusui/me, and blog refers to https://github.com/citrusui/blog.

Advantages

• Slightly faster git clone's
• Focused development. The core repo and blog have different goals: The former incorporates most of the functionality, and the latter provides detailed information in Markdown. Opening a pull request or issue would hopefully be directed to the core repo or the blog repo.
• Different design choices. Files directly pertaining to blog would no longer be cluttering up the core repo, and vice-versa.

Disadvantages

• Heavy reliance on _includes and _layouts. Should blog have duplicates of these folders in its own repo, or be strictly Markdown files? Would it make sense to be able to jekyll serve the standalone blog repo?
• More tests. One without the inclusion of blog, and one with blog to make sure all goes well.

Even lazier loading of images

So far, lazyload seems to be working well in reducing page load times. However, using lazyload also means experiencing frequent page reflows. As a result, reading long paragraphs of text on these pages becomes a pain for the user.

Two considerations:

• generate smaller “thumbnail” versions of images (will consume more develop time and increase page load time)

• add a basic placeholder image, ideally a transparent (white) background with a camera or picture glyph in the middle

Idea number 2 seems the most ideal. However, the placeholder will need to exactly match the dimensions of the original image once it has finished loading. Perhaps the placeholder could be placed inline, as a PNG with alpha transparency. Or, it could be placed inline as a base-64 encoded SVG. Either way, the issue remains: how do I ensure the placeholder matches the original image dimensions? Specifying the dimensions manually is tedious and unrealistic. It is crucial that the loading of page content does not cause the page to “jump up” or scroll up unexpectedly -- especially when the page is reloaded. Could this be resolved through extra styling of <img> or <div>?

Add new artwork/design page

I’ve been making a lot of random pictures and digital designs for the past few months, and I figure it’s time to show them off.

Priorities are:

• fast loading times
• a search function
• fancy animations that don’t hinder UX
• download links for a few (or all) designs
• a good webfont, or at least a few tweaks to my existing font stack (bigger text, etc.)
• light/dark theme toggle

Later on, I might implement categories to distinguish specific content. As an example, RAW photos could get their own category (or tag, if that ends up being semantically correct)

Support for AMP

As I'm no longer using Jekyll on GitHub Pages, I'm free to use any plugins that I desire. AMP may be severely lacking in features, but it does load insanely fast.

This may depend on citrusui/poole#2. I need to do some more in-depth research about Hugo plugins.

Stop using Node.js

Node is far more complicated than a regular Jekyll/Hugo setup. There's no good reason why I need to download hundreds of megabytes of code just to build and publish my site.

Unfortunately, it seems that firebase-tools is only compatible with Node. This means I need to either find a hack to use Firebase without Node, or drop Firebase completely and use a service like Netlify.

IPFS archives

I'd like to add full support for IPFS/IPNS on my subdomain https://ipfs.citrusui.me.

However, IPFS is still in alpha, (especially IPNS) and is not yet suitable for production. I'd like to implement a simple static site on the aforementioned subdomain that hosts links to hashes on https://ipfs.io.

My initial thought is running a build script that appends hashes to a JSON file, perhaps called contents.json. Then it will take the output from the JSON, maybe using jq, and produce a single page (index.html) or a set of folders with pages, like 2017/01/23/index.html and so on.

And, of course, there should be an about page. I'd prefer it to be separate from the index as its own file.

Progress for switching to Node.js

[Codename: Sunstreak]

This is an attempt to completely ditch Ruby and Jekyll in favor of Node.js.

Benefits

Installing Ruby, Jekyll, and other gems will no longer become neccesary. macOS ships with an outdated Ruby, and so does Ubuntu. rvm fixes these problems, but does not fix the fragmentation/differences between Node and Ruby libraries/tools. My reasoning is discussed further below.

Jekyll is not as fast as I'd like it to be. Sure, it's not slow, but it isn't instant either. I've mentioned Hugo on citrusui/poole#2, which seems to be much faster (especially for directories with 1000s of pages.) Hugo is written in Go, but does not need to be compiled for use; you can use any of the binaries on the GitHub Releases or the unofficial hugo-cli module on npm.

Express.js is something I've been looking at. A minor pet peeve of mine is the constant addition of trailing slashes at the end of my URLs. Luckily, Express (by default) treats both URLs (slash and no slash) as the same page.

Downsides

I have to figure out the backend and hosting stuff. My initial thought was to use https://now.sh, but it unfortunately costs to use custom domains. Firebase Hosting only handles static files, and Nodejitsu is now part of GoDaddy (sigh.) Heroku seems to be a fair compromise, although the free dynos hours may be the death of me (unless I move twbs-listr to a different host, in which case everything should be OK.)

Initially, I may need to manually push changes to my website from my local machine. It'd be rad to push the changes after the website passes CI tests; I believe Heroku is capable of doing this.

I need to stop sleeping incessantly.