joryphillips / joryphillips.github.io Goto Github PK

Portfolio/Resume Implementation - a 2020 retrospective

The current portfolio/resume website implementation has some advantages but also has some problems.

First, the positives:

• Doesn't rely on any JS libraries or build tools. Only needs the TypeScript compiler and (for now) a lightweight CSS library.
• Uses native HTML templating which is highly performant and also good to understand.

The negatives:

• The imported CSS library is nice little utility library, but after months away from regular use, it doesn't really make much sense. While I generally understand the intent of col col-6 sm-col-6 md-col-4 lg-col-3 px1 lg-px2 lg-p1 mb4, I think looking at line-by-line CSS rules that provide a grid, padding, and margins for that DOM element would be faster to understand and edit, as opposed to this long horizontal string of shorthand.
• JS is loading synchronously, then the JSON is loading, then images are loading. The only things that are async are the CSS with the initial JS, util.js and clock.js, and all the images.
  
• Page load is fast but could be even faster. It takes up to a couple seconds for everything to load. On the other hand, all the text content is loaded and showing in less than half a second (within milliseconds of the JSON loading).
• It is not great that none of the projects are showing until all the images are loaded. It also causes a content 'jump'.
• Stamping things into the DOM with JavaScript is not really scalable, at least without a library or more foresight than this implementation. 😃 If I write my own utility for doing this, it is not going to end up being better than LitHTML or similar.
• This implementation doesn't make it very easy to add additional functionality. Top feature request: make the projects interactive. Users (well... me) probably want something to happen when clicking on them, like providing more information and background. This means showing a popup, navigating to a new page, or moving/changing the information on the screen to make room for more text and possibly more images.

Some ideas:

• Drop the CSS library and rewrite it all by hand. CSS Grid is now standard since this page was originally made and should make a CSS rewrite relatively easy.
• Use the Intersection Observer to deal with image loading.
• Use loading="lazy" for images instead of the current Promise.all() then show method.
• Use a library for templating. LitHTML does a lot of what this code does and is likely just right for this.
• Start componentizing the webpage and make it more app-like. This might be overkill for the use case, but may also facilitate easier development of more dynamic, interactive content. React or LitElement are candidates.
• While loading the JSON with a fetch might be somewhat representative of a typical client-server relationship, it doesn't help in a meaningful way here. Changing it to be a JS object and bundling the module could speed things up. This does surface a good question: what is a good balance for easy content updates vs. easy implementation vs. fast end-user experience/downloading?
• Adding a new library will require also adding more advanced tooling, and with that comes the opportunity to bundle and minify the JS, which could help with load times (although this might be offset by adding a library).
• Probably should add a bundler in either event.

On reloading a portfolio project page, the link to the image gets broken because the path is no longer correct. Need to remove the path from the filename in the portfolio object and have it update depending on the current page route.

I expected some adverse side effects on this feature! A couple bad things are happening:

1. non-deterministic "snapping" to visuals or summary page load -- seems to maybe be based on window width (?) Anyway this is bad.
2. using keyboard navigation, tabbing out of the navbar when 'experience' is selected causes the page to scroll, which fires the intersection observer, which fires the nav selection, which puts the focus right back to the visuals. it works as expected from there, but we need to disable scrolling in actions fired from the intersection observer.

Using CSSTransitionGroup to provide an opacity or other transition between routes doesn't work well with 'swiping' forward or backward, as the user sees the native swipe followed by the CSS transition.

Try to disable CSSTransitionGroup with touch events. Also look into how trackpad swiping may or may not differ from mobile device touch events.