[HN Gopher] No longer writing my own damn HTML
___________________________________________________________________
No longer writing my own damn HTML
Author : claytonwramsey
Score : 74 points
Date : 2025-02-12 03:45 UTC (19 hours ago)
(HTM) web link (claytonwramsey.com)
(TXT) w3m dump (claytonwramsey.com)
| ljlolel wrote:
| I've felt the pain
| lelanthran wrote:
| The big problem was not wanting to write even a small amount of
| is.
|
| After all, a simple web component in a page of code would have
| allowed client side includes.
| claytonwramsey wrote:
| 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.
| b_e_n_t_o_n wrote:
| Hmm - what is the actual cost incurred by the users here?
| Mostly battery right? Is that not virtually inconsequential
| to each individual?
|
| I mean you could sum it all up and compare it to human-hours
| or something but that's not a useful metric because it's
| distributed.
|
| Personally I think it's better to distribute the workload
| across clients. We'll probably see purely client driven UI's
| dominate the future. Imagine users being able to display data
| (because fundamentally that is all a blog [or any site] is)
| in a way chosen by each user. That would probably be worth
| the extra cycles on device.
| shkkmo wrote:
| Please, no. Don't use a SPA to render a blog, that's awful.
|
| Browers already give users near complete ability to
| customize how web pages are displayed and SPAs usually make
| this worse not better.
|
| The actual cost is forcing users to run javascript, with
| all its privacy leaks and security issues, to view what
| should be a static HTML document.
|
| Not to mention the issues you create for battery life,
| network traffic, caching, etc just because you are too lazy
| to develop properly.
| DangitBobby wrote:
| In this case, users with JS disabled would miss out on
| loading, what, a navbar and footers?
|
| And fuck off with "too lazy to develop properly." I am so
| tired of HN users constantly talking shit about JS. There
| are times to fight for efficiency but this is just part
| of a tired crusade.
| lelanthran wrote:
| > 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!_
| lsaferite wrote:
| 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 side is overkill
| IMHO. If it's an actual _application_ (the A in SPA),
| then fine. But for what is essentially a static
| website... why?
| lelanthran wrote:
| 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.
| chuckadams wrote:
| > XML+XSLT is the "red-headed stepchild" that everyone
| seems to hate
|
| One look at XSLT syntax and you learn why.
| Dalewyn wrote:
| >what is the actual cost incurred by the users here?
|
| Time.
|
| Every bit of JavaScript is more time to download, execute,
| and then render the page. Time is a valuable resource,
| users appreciate not being told to waste it.
|
| >I think it's better to distribute the workload across
| clients.
|
| The bulk of such loads should and ideally must be on
| servers, not clients. Use PHP, not JavaScript.
|
| Also worth noting, the _biggest_ motivator for JavaShit by
| far is the website owner(s) cutting costs. More load on the
| clients is more idling of the servers, the consequences of
| this will be homework left for the readers.
| account42 wrote:
| You're not distributing the workload to clients, you're
| duplicating it.
| lelanthran wrote:
| > 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, nor deteriorate the experience of the user.
|
| After all, you provide a CSS file, right? The JS to do
| client-side includes using a custom element (so that
| `<client-side-include remote-src="...">` works) is unlikely
| to surpass a modest CSS file in terms of size.
| shkkmo wrote:
| 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.
| netsharc wrote:
| > Forcing users to run code just to render some boring text
| seems like a waste.
|
| Do you serve your content with "Content-Type: text/plain"?
| Client-side parsing of HTML and CSS, layouting, etc, is a
| looot of code.
| Nijikokun wrote:
| Honestly, I thought this was going to be another AI post. TIL
| about zola. Looks cool.
| hardlyfun wrote:
| I run my personal site off of Hugo. You can load some decent
| themes and adding new content is a relatively painless process.
|
| But I do feel like there is a cost to using static site
| generators. Raw HTML is easier to work with if you aren't dealing
| with a lot of similar pages.
| andrewshadura wrote:
| Build times can be annoying. I have a bicycle shop's website in
| Hugo, full generation takes about a few dozen seconds, upload
| using rsync easily a minute because of many nested directories
| with images. I ended up writing a script to only upload changed
| html and new images unless needed.
| wombatpm wrote:
| You know there was a time when we had to wait dozens of
| seconds for the modem to finish its handshake before you
| could do anything.
| vram22 wrote:
| 80s or 70s geezer, huh?
|
| 60s grandgeezer here. try waiting a week or two, to find
| out that your punched card batch job didn't even compile,
| let alone run, because of a single character typo you made.
| back to square zero.
|
| kids these days ...
| Brajeshwar wrote:
| After many iterations of tools, systems, and processes, I have
| settled on writing in plain text, in Markdown, to identify
| headings, paragraphs, quotes, images, etc.
|
| My reasoning and approach is that I or someone should be able to
| read it as it is and then have a tool parse it to spit out HTML
| for browsers, helping others read it with a better experience.
|
| With thousands of posts, it would be complex for me to maintain
| them in HTML. Now, my blog is powered by Jekyll because of GitHub
| pages. However, I can quickly switch to any other tool with minor
| tweaks.
|
| Locally, I see my blog posts as individual files with dates
| `YYYY-MM-DD` and the title in their yearly folder `YYYY`. Some
| are in `WIP`, which I can continue to update/write. The `future`
| folder contains the ones that are drafts, but I can see them and
| don't mind if someone stumbles on them. Always a work in progress
| and am even aiming to simplify it further.
| est wrote:
| same here.
|
| Besides you can directly embed any HTML inside markdown.
| austin-cheney wrote:
| I want to agree with this because I completely love markdown
| and it solves for so much of accessibility.
|
| Markdown makes it challenging to write form controls (input.
| select, textarea, buttons) and non-visual identifiers (id,
| class). To solve for most of these concerns I still find I
| prefer to do it dynamically against the DOM as needed by user
| interaction.
| apsurd wrote:
| God on Clayton to publish his thoughts on his own blog!
|
| That said, he's throwing the baby out with the bath water and
| making convoluted claims. I agree with some of them, but I'll
| exercise my desire to write more and reply:
|
| > My hope is that I'll take advantage of this and start writing
| more!
|
| Choosing to self-publish one's blog is already at odds with "I'm
| doing this to write more". So blaming handwritten HTML for added
| friction is not so fair.
|
| Literally writing every single page of HTML is unnecessarily
| strict. As another commenter mentions, why not add a few client-
| side templates for header/footer, a global nav etc.
|
| Jekyll is really not a very ergonomic static site generator. I
| got GitHub famous for a hot-second because I wrote a little
| framework to help: https://github.com/jekyllbootstrap. TLDR:
| Jekyll is famous because the cofounder of GitHub made it. Not
| really because it's the best or even a good implementation. It's
| neat, it's just, why would you use that if you have access to a
| fully ruby runtime.
|
| Anyway, I love hand-writing HTML so my bias out. I don't think
| it's HTML's fault. HTML is super easy to write, as OP agrees.
|
| I made my own little website framework (of course); it's not
| ready for prime-time but you can peruse here:
| https://plusjade.com/demos/index.html
| vunderba wrote:
| I can definitely relate to building towards an easier "write ->
| publish" workflow. My old site is still running WordPress but I
| just got frustrated with the overall feeling of oppressive
| heaviness to the whole framework (no shade on WP, I still really
| like it).
|
| I switched over to a similar process but opted for Pelican (since
| I'm more familiar with Python vs Rust) which builds directly off
| my markdown notes in Obsidian so it's relatively WYSIWYG. Much
| easier to maintain and Github Actions automatically handle
| updates.
|
| https://mordenstar.com/blog/obsidian-to-pelican-exporter
| natnatenathan wrote:
| I have always written my own static blog generator, moving from
| PERL to Ruby and most recently Python. I find the other blog
| systems are too complicated for what I want. Plus, I think I like
| writing the generator more than writing actual posts.
| choobacker wrote:
| +1.
|
| It's nice to have to a set of programs I moderately care about,
| so when I'm learning another language I can port them to it.
|
| They're unimportant enough that I can comfortably experiment,
| but important enough that I want to complete the rewrite.
|
| My "blog engine" is a nushell script that uses pandoc and
| built-in XML support to convert markdown into a site+feed.
| account42 wrote:
| This is the best solution I think - you get to have things work
| just as you want like if you were manually writing the HTML but
| don't have to manually do the repetitive parts like keeping
| layouts and navigation synced.
| TZubiri wrote:
| My main issue with writing html directly is that it's not a
| writing workflow. I write in my notepad, or in my notepad.exe or
| word about lots of things, only a few of which I would end up
| publishing, so htmlizing was always a publishing step that starts
| with a source material. From that it naturally follows that it
| can be easily automated, and html is a great format for this in
| theory, but even as a programmer WYSIWYG is so powerful, I'd
| rather write in Word or notepad exe and THEN annotate what are
| the headings and etceteras.
|
| If you truly write directly in html, you are probably going to be
| writing about html or webdev, as your mind is in that headspace,
| and you have to tweak a lot of html stuff so that's what you get
| to talk about. Once you let go a bit of that primitive purism you
| realize you are free to think about whatever the fuck you want.
|
| That said I have a lot of love for speaking about the medium.
| When I'm feeling cynical, it feels dumb to speak about anything
| other than the medium. It makes sense to me that half of the
| discourse on twitter is about elon musk, at least it's
| transparent in its topical bias, on typical media the topical
| bias gets rerouted and engineered through ads so that you can
| "focus on the actual content" which is kind of dumb, I guess, I
| find the ads end that keep the lights on end up being more
| important than yet another mindless sitcom.
|
| So yeah, I'm torn. But whichever path is chosen, going through
| this drama of self hosting, tech minimalism and reinventing the
| wheel, is a key signature of the tech blog, it really shows the
| identity of the author and the work they've put into the mix of
| their ideas and their web space, in a way that, say, a wordpress
| instance, cannot fulfill.
| Analemma_ wrote:
| Everyone loves to gripe about Markdown, but I think this the
| killer feature which keeps it so prominent: it's right at the
| sweet spot of staying in a writing workflow while still having
| enough formatting capability to cover ~95% of use cases.
| Despite all the complaining, I don't expect it to be replaced
| any time soon and I think all my notes and writing will be in
| Markdown for many years to come.
| genewitch wrote:
| I only have 1 markdown editor, in nextcloud. Is there an app
| that let's me write markdown and then save as .md for
| publication by something that makes that HTML?
| TZubiri wrote:
| What do you mean markdown editor?
|
| I thought the idea was that you can just write it as plain
| text in something like notepad.exe
| genewitch wrote:
| markdown isn't viewed as plain text, though. So a
| markdown editor lets you edit markdown while seeing what
| it looks like, with things like "make this highlighted
| selection bold" as a keypress combo or a button.
| TZubiri wrote:
| Hmm, it also has display support in a lot of random websites
| and tools like GitHub and reddit
| geor9e wrote:
| 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. I did see
| Hugo, Jekyll, & Pelican do similar, but it was straightfoward
| enough to just do it from scratch with Cursor, customized how I
| liked it.
| Evidlo wrote:
| Publish the PHP!
| geor9e wrote:
| Sure. I'm not necessarily advocating others use it, but I'll
| post it for the curious.
| https://github.com/gth001/MarkdownToHTML/
| asynchronousx wrote:
| Hilarious post in that it mirrors my own experience. Starting
| writing a SFS site by hand in HTML, hated writing new things on
| it, decided to ditch it for a static site generator.
| Evidlo wrote:
| A funky option for doing client-side includes and basic
| templating without JS is XSL.
|
| Here's an small demo I threw together
| https://github.com/evidlo/xsl-website
|
| A lot of people hate on XSL, but it has some interesting
| abilities!
| defanor wrote:
| 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.
| tonijn wrote:
| XSLT is indeed great for this but very underestimated
| __d wrote:
| My "static site generator" is m4 and make.
|
| People over complicate things.
| grandempire wrote:
| You actually skipped making an adhoc site generator of your own.
|
| Make a 5 line shell script to do steps 1 and 2 for your entire
| site. Then the content is just a few paragraph and link tags.
| Throw in a call to markdown if you want to get fancy.
| genewitch wrote:
| Back in the day I'd use a WYSIWYG editor to design a front page
| and navbar and whatever, then split each part into header, nav,
| footer files and have code spit out the template HTML in the
| correct order with "body" file chosen by the URI
|
| This is static site generation? I had another name, basically
| it was CMS for people that used ms word to type blog posts
|
| Doing this again with a markdown step sounds cool
|
| I think a real cms just has like tag engines and the ability to
| group posts and that sort of thing. But a site where everything
| is chronological; and otherwise only "wicked" - linked via
| potholes in posts is really all I need.
|
| Maybe. I do need 2 blog sites here soon. I'll try templating
| for one and a ssg for the other maybe.
| Sabinus wrote:
| I just want to say how funny it is that this is posted after the
| spirited discussion in the previous related thread about exactly
| what 'writing your own html' means.
|
| https://news.ycombinator.com/item?id=42996322
| austin-cheney wrote:
| Yeah, people (primarily developers) have always claimed HTML is
| so hard to get wrong and yet failure is well above 90% after
| consideration for accessibility, SEO, security, and more.
| rcarmo wrote:
| It was likely meant as a counterpoint to it. However, I don't
| really know what either story brings to the table in terms of
| learning value, either option has been with us since the age of
| CGI scripts...
| dangus wrote:
| I mean, no shit dealing with raw HTML sucks. I really don't
| understand why technical people get in their own way.
|
| Even something like a squarespace site is worth the proprietary
| commercial money if you enjoy blogging.
| peteforde wrote:
| 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 which makes it easy to
| render MathML, why the hell wouldn't you just use it?
|
| I'm not saying that I've never invented artificial constraints
| for myself; arbitrary goal posts that literally nobody but me
| would ever notice much less care about. I am saying that
| perspective is everything, and that sometimes it can be hard to
| see from the inside.
|
| This is intended as an expression of care.
| Dalewyn wrote:
| The ideal amount of JavaScript is zero.
| IshKebab wrote:
| I disagree. The gov.uk website completely eschews JavaScript
| at some usability cost, in particular form validation is
| delayed until way later than it would be if they added just a
| _little_ JavaScript. It can be quite annoying.
| DoingIsLearning wrote:
| > The gov.uk website completely eschews JavaScript at some
| usability cost
|
| I would imagine this was mostly driven by accessibility
| requirements more so than some ideological rigidity.
| fragmede wrote:
| a little bit of the right kind of JavaScript _helps_
| accessibility, so it 's clearly not
| biofox wrote:
| Unfortunately, some people view accessibility as an
| ideology.
| tzmudzin wrote:
| It's easy to dismiss the genuine needs of someone else if
| one's not impacted though.
|
| Ideology or not, exclusion does not help.
| tweetle_beetle wrote:
| Perhaps, but, taking the example provided, Gov.uk deals
| with population scale products funded by taxpayers and
| which may be exclusively digital. Accessibility as an
| ideology makes sense in this context, and, I would argue,
| is morally correct.
| rhubarbtree wrote:
| Why?
| mediumsmart wrote:
| I agree and with small single page sites doable but when I
| need to put a navigation (plus language versions etc) of the
| site into a mobile layout I have to do the js toggle, or do
| I?
| account42 wrote:
| Why would you need JS for any of that?
| mediumsmart wrote:
| 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_
| Lammy wrote:
| Actual answer: like this!
| https://codepen.io/Sfate/pen/kGbLzK
| mediumsmart wrote:
| _yep that works thank you_ - so to get the fullscreen
| overlay (since we only want it on the phones) a media
| query - maybe it should be the one gridcell navpage. But
| maybe the links should be listed for the robots ... if
| mobile is default /first there would be only one link -
| yeah maybe this is good.
| endemic wrote:
| You can do a lot with CSS these days: https://css-
| tricks.com/the-checkbox-hack/
| throw_m239339 wrote:
| I agree, but HTML widgets are not sophisticated enough not to
| require some amount of scripting for interactivity in many
| cases.
| ozim wrote:
| It is for documents but we have web apps that are not
| documents.
| manuelmoreale wrote:
| 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.
| loco5niner wrote:
| Sounds like the fun exercise went 'a bit' too far in this
| case
| manuelmoreale wrote:
| I think it's up to them to decide. If they're having fun
| doing it I don't think there's anything wrong.
| edflsafoiewq wrote:
| 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.
| Spivak wrote:
| Because you go where the good tooling is and MathJax is drop-
| dead simple to integrate on the client.
| whatever1 wrote:
| Html and xml are prime examples of why code prettiness is super
| important for the developer experience. Markdown and JSON exist
| because the above are plain ugly.
| james-bcn wrote:
| I think the key to getting into the habit of writing blog posts
| is to make the actual process of writing and then publishing as
| easy and frictionless as possible. I use Bear app for the writing
| - it's a very well designed markdown editor with some really
| nice, simple features, such as nested tagging. I then got ChatGPT
| to help write some scripts to publish it via the Quarto static
| site generator. I wrote about the process here:
| https://thisisjam.es/creating/quarto-website-with-bear/
| memhole wrote:
| Different process, but this is my experience too. Making it
| super easy to go from writing to publish helps keep momentum.
|
| Including the prompt in your write up is a nice touch.
| eviks wrote:
| > handwriting HTML is honestly not that hard
|
| proceeding with all the steps that make it hard...
|
| > exercise in pointless manual labor
|
| This is exactly correct! Let the tools do their job and insert
| all the spans/tags/etc. that a browser expects, devote your
| energy to the content!
| aqueueaqueue wrote:
| Ignore the high velocity toys emanating from the strollers of
| leadership ... and just use WordPress.
| Joker_vD wrote:
| > handwriting HTML is honestly not that hard.
|
| > To write a new article, I... [c]opy-paste an older article to
| get the correct headers and navbar.
|
| This is kind of hilarious. Any parts that you copy-paste from
| your previous projects into your new one are almost by definition
| too hard to do from scratch every time. You don't normally copy-
| paste e.g. single words or phrases like "do from scratch" into
| your writing because simply writing them is quicker and less
| fiddly than copy-pasting them from somewhere else, right? Yet
| I've worked with a dyslexic programmer once, and he copy-pasted
| _tons_ of single words and phrases around from his earlier
| messages when chatting, and code snippets when coding -- because
| for him, it was indeed easier than writing it correctly from
| scratch.
|
| So back to main original point: handwriting HTML may not be
| _that_ hard, but it 's still hard enough for almost anyone to
| make them evade it whenever they can.
| xyzzy9563 wrote:
| The best method I found is write in markdown and then use react-
| markdown on a next.js app. Kind of overkill but it works well.
| jaw wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-12 23:02 UTC)