Joe's Code Jottings

On Seeking an Answer: Why can’t HTML alone do includes?

A few thoughts. Some of which are cross-domain issues.

the big one is that a block of html isn't just html. if it was, hey, great, no problem. render it and move on.

but a block of html (like in a web-component or a react component) can contain css and scripts and meta tags and the like. each of these needs rules for when it runs and applies, and as such each also needs to be handled by CSP CORS rules in some manner, even if on the same domain.

Granted, none of these rules existed X years ago when this could have been implemented where security concerns would have just addressed the fact that it would have been there.

But now the security concerns are SO large that it is just unfeasible to address them all.

that's one thing the JS solutions all are kind of stuck, trying to handle that security concern as best they can give or take not knowing when the browser is going to reject something.

Second is yes this affects rendering, particularly if the included html has a meta tag that changes the device-width. Synchronous processing would work albeit with a risk of slowdown much like how a script tag without defer freezes the render while waiting for the load. but if async, do we have a 'loading' tag to show what it had before it is loaded?

now in all of that, when does "ready" fire? when does "on document load" fire? do we need a new event for "document ready AND all the other crap is loaded, too"?

Now throw in the next step: what happens in when the html included by the "" tag...has tags? they have to be loaded, too. so how does the above document ready thing know when they're all done, too?

And finally the curse: recursion. X includes Y includes X and the loop is infinite. yeah code could be done to test for X...but if Y doesn't include X but rather, through a script, includes X?date=new Date().milliseconds - so there's no way for the browser to cache it?

yeah, thoughts. None of them positive, really, and all leading to the idea that the server should just handle this, or web-components that are clearly restricted in what they can include.

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.