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.
No longer writing my own damn HTML
61–70 of 98 posts
Re: No longer writing my own damn HTML
#62Earlier 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,…
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
#63Earlier 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…
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
#64What 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!
Re: No longer writing my own damn HTML
#65Earlier 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
Re: No longer writing my own damn HTML
#66Re: No longer writing my own damn HTML
#67Earlier 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
Re: No longer writing my own damn HTML
#68But 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
#69As 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.
People over complicate things.
Re: No longer writing my own damn HTML
#70I 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.