Live data from Hacker News

No longer writing my own damn HTML

claytonwramsey.com

61–70 of 98 posts

Re: No longer writing my own damn HTML

#61

I don't understand your hangup about using JavaScript to accomplish tasks that JavaScript is extremely well-suited to do. The idea that you are somehow imposing a burden on your visitors is an imaginary constraint which is actively consuming the finite minutes you have on the planet. This is a pyrrhic victory. I am not advocating using SPAs of any kind, especially in a blog context. However, if there is a library whi…

As a fellow no-JSer (when it comes to personal sites) for me it’s mostly about pushing myself to figure out creative solution using only what’s available within CSS and HTMl, which is a lot these days. It’s a fun exercise.

Sounds like the fun exercise went 'a bit' too far in this case

Re: No longer writing my own damn HTML

#62

Earlier quoted context omitted.

I did think about that! However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. Forcing users to run code just to render some boring text seems like a waste.

> However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. If you set the bar to "0% JS at all costs " then you can't very well complain about how hard it was to maintain HTML. Part of the standards, whether we like it or not, is JS. A sprinkling of JS (say, 60 lines?) to do client-side includes does not in any noticeable way increase the workload of the client,…

The argument is not to never use JS. The argument is that you shouldn't unnecessarily use JS in a way that breaks core functionality if it is disabled.

There is no actual need solved by using client side include to load a nav bar. Doing so will break navigation on your blog for people without Javascript enabled.

Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.

Re: No longer writing my own damn HTML

#63

Earlier quoted context omitted.

> Not to mention the issues you create for battery life, network traffic, caching, etc just because you are too lazy to develop properly. This is a very uncharitable take. It's because I know how to develop properly that I want to send the repeated content of the site to you just once; the header, topnav, lhs-nav and footer will be cached if JS is enabled. The cost of that JS is less than the common elements anyway!

It's funny. Further up in this discussion is someone sharing their demo of using XSLT to dynamically assemble a page from parts. This process properly caches the fragments as well. No JS required, just the default rendering process for the browser. But XML+XSLT is the "red-headed stepchild" that everyone seems to hate. Writing a SPA just to recreate the built-in functionality of rendering a static page on the client…

Your take is getting more and more uncharitable.

In what world is 60 lines of JS an SPA?

Come on, enquiring minds want to know. Show us all this SPA you know off that is 60 lines or less.

Re: No longer writing my own damn HTML

#64
post #25
post #15

What I did was store my Obsidian vault in my website server folder. Then I instructed Cursor to make all /whatever.md markdown files in there show up as HTML when you visit "/whatever" , and to get all the obsidian features like [[links]] and ![pics] and all rendering right. It used php and some apache settings. Works great. Now I just edit in Obsidian, and it all appears on my .com live as I type. Very low friction.…

Publish the PHP!

Sure. I'm not necessarily advocating others use it, but I'll post it for the curious. https://github.com/gth001/MarkdownToHTML/

Re: No longer writing my own damn HTML

#65

Earlier quoted context omitted.

As a fellow no-JSer (when it comes to personal sites) for me it’s mostly about pushing myself to figure out creative solution using only what’s available within CSS and HTMl, which is a lot these days. It’s a fun exercise.

Sounds like the fun exercise went 'a bit' too far in this case

I think it’s up to them to decide. If they’re having fun doing it I don’t think there’s anything wrong.

Re: No longer writing my own damn HTML

#67

Earlier quoted context omitted.

Why would you need JS for any of that?

how else can I have a fullscreen overlay navigation on a phone from an accessible toggle button? almost forgot to answer the question: because I don't know any better

Actual answer: like this! https://codepen.io/Sfate/pen/kGbLzK

Re: No longer writing my own damn HTML

#68
I use a sort of intermediate approach for my personal site. It's just stored as html files in a git repo, and I do write the html by hand for pages that I want to put extra love into (e.g. an annual year-in-review post to share with family and friends). You wrote something in your original "Writing my own damn HTML" post that captures a big part of why this appeals to me: "I see my website as a sort of self-expression project - kind of like a zen garden..."

But handcrafting html is inconvenient to do frequently, so for more ordinary posts I write in markdown and use some custom scripts and pandoc to generate html. For me this approach is more fun than using a static site generator and less annoying (because I spend less time figuring out why an upgrade randomly broke something, or how to make the SSG do things I already know how to do manually). But the only reason it hasn't devolved into a full hand-rolled SSG is that I don't need/want much consistency across pages: there's no shared nav bar and I don't try to keep the styling or layout of older pages in line with newer pages.

Re: No longer writing my own damn HTML

#69
post #24

As an option that still uses HTML, with relatively minimal and common dependencies: the unified header and navigation insertion, as well as other aspects of website generation and syntax checks, can be handled with XSLT. Or one may employ a generic macro processor like M4, which should be fairly easy to set to convert LaTeX into MathML, as well as to include shared headers.

My “static site generator” is m4 and make.

People over complicate things.

Re: No longer writing my own damn HTML

#70

I don't understand your hangup about using JavaScript to accomplish tasks that JavaScript is extremely well-suited to do. The idea that you are somehow imposing a burden on your visitors is an imaginary constraint which is actively consuming the finite minutes you have on the planet. This is a pyrrhic victory. I am not advocating using SPAs of any kind, especially in a blog context. However, if there is a library whi…

But all the tasks in the article are totally straight-forward SSG stuff. Why would you do some processing in a build step, but then stop half-way and ship a bunch of JS to the client so they can finish it? That only makes sense if the work is dynamic in some way that it can only be done on the client-side.

Because you go where the good tooling is and MathJax is drop-dead simple to integrate on the client.
Post reply on HN