Joe's Code Jottings

In the last entry, I presented a way to use typescript in basic static html pages with a simple compile task, along with how to use external modules' type definitions while still relying only on their CDNs for the actual code and css loading.

Here, I'm going to add a little my dynamics to the page. I have 2 core features I wanted on the page. First is to be able to write sections of the page in the slightly more readable markdown syntax. Second was to fetch the RSS feeds from my various blogs and render just the first entry in a reasonable layout consistent with the page styles.

While both of these features could be done with a server side language or a full static-site generator, I'll be honest: I'm tired of php, and I find the SSGs to be overkill for something like the simple home landing page I'm making (I also don't like how in general they pollute the file system of the root folder with all of their cruft that could easily be stored in a subfolder to keep things isolated and easier to manage when you restructure a site).

So the basic idea - I have a "card" of the markdown content deployed on the host site with the index page. I want to fetch it, convert it to html, and render it. Yes, this could be done straight in javascript right on the index, but I'm a sucker for some encapsulation. Thus the ideal self-contained solution would be a web-component.

The syntax should be simple - just specify the card content and then some classnames or styles. (Any header/other styling would happen from the beercss library already being used to style the whole page.) A web-component needs a name in a hyphenated form to differentiate it from any current or future standard HTMLElement.<aji-md card="cards/bio.md" class="aji-summary line-clamp-8"/> Continue reading "A simple markdown-to-html web-component"

A few days ago, I did the stupid. I accidentally wiped over some key PHP files from my personal home page's Concrete5 setup, and attempts to recover them were unsuccessful (yeah, stupid me forgetting where his backups were).

So having decided to start over, I had to decide 'with what'? Usually I use opportunities like this to pick up a new thing I'd never worked with before. My site is on a php-based host (cpanel+scriptaculous), so some of the more modern node options like ghost were out, as were anything involving docker. But in thinking about it, I realized I didn't need all of the weight that comes with many php-based CMS/Blog systems like wordpress, b2evolution, and concrete (in addition there's the matter that increasingly the 'themes' aren't free).

What did I really want? Easy theming, a list of my social media sites, a list to my other home pages, a place for a bio blurb, and spots where I could put the summary of the most recent article from each of my blogs/rss feeds. I also wanted a general-posting blog but I could externalize that separate from the personal home page itself. I don't need a static site generator or big CMS system for something like that.

But I might want to add a few special features through simple web-components, and the theming framework may need some coding. And doing that, I absolutely wanted Typescript. But again, I don't want a big rollup/webpack framework. I just want the deployed site nice and simple, using CDNs as much as possible.

So here's how I set that up and worked past a few odds and ends. Continue reading "Typescript for Web Pages, Simplified"

The optional chaining operator is a great tool for code clarity. The messy nest of if-checking down a deep object well has always been a readability nightmare in every language.

That said, it is a syntactic sugar that can fill your code with unneeded checks, and it is also not without some risks if not used well.

Continue reading "risks of ?'s"

Inspired by this: https://youtu.be/ADKvP8Xn4g8, a video response to another "I'm not using react ever again" rant. "you" = the responder, "he" = the original anti-react ranter.

I think you missed one detail around claims 3 and 1 - a bit of a contradiction. On the one hand, he talks about how much the "elite" (your term) are constantly talking about some 'right way' to use react and he finds that annoying or worse.

But on the other hand in his point 3, he talks about the other framework as one where "there is a very clear idea how to use it."

So on the one hand he doesn't want to be told he's doing something wrong, but at the same time he wants assurances he's doing it right.

Those aren't as different as he seems to think. Continue reading "On the energy lifecycle of web frameworks..."

I'll admit this up front: I'm lazy. I hate typing. I hate typing long words. I hate trying to read through long words to get to what I need to see, especially oft-repeated ones.

I label it a kind of laziness, but rather it is more that it is a distraction. It gets in the way of seeing what you need to see, because it is always sticking out. Code syntax highlighters aren't smart enough to 'rate' attributes and properties and highlight only the ones that matter and fade out the ones that don't...and how would they know?

And with that comes one tiny gripe with Material-UI's naming and syntax. "Grid container", "Grid item", "Typography variant={variant}". Even with syntax highlighting, I find it makes the text of my code hard to read, and takes up so much space that in a nested Grid, I end up with a lot of line-wrapping in the editor which also decreases readability for me. They are long, almost boilerplate, words that cease to be useful to me after I've typed them, but they're always there, always taking up space, and making it hard to find the properties that I really need to argue with, like the responsive size markers, or in the case of Typography, my actual text itself. When the wrapper for a block of text is bigger than the text itself, there's a problem that needs to be resolved.

Continue reading "Material-UI Shortcut Components (for the Terminally Lazy)"

So my ISP here no longer supports node.js, and I'm flipping to an older but stable php service. I'll go through the old entries and see what's worth putting back here next week.