Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No longer writing my own damn HTML

claytonwramsey.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: No longer writing my own damn HTML

#51

Post by lelanthran »

claytonwramsey wrote: post #5
lelanthran wrote: post #3

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.

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, 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 `` works) is unlikely to surpass a modest CSS file in terms of size.

Re: No longer writing my own damn HTML

#52

Post by tzmudzin »

biofox wrote: post #49
DoingIsLearning wrote: post #41

Earlier quoted context omitted.

> 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.

Unfortunately, some people view accessibility as an ideology.

It’s easy to dismiss the genuine needs of someone else if one’s not impacted though.

Ideology or not, exclusion does not help.

Re: No longer writing my own damn HTML

#53

Post by throw_m239339 »

Dalewyn wrote: post #32
peteforde wrote: post #31

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…

The ideal amount of JavaScript is zero.

I agree, but HTML widgets are not sophisticated enough not to require some amount of scripting for interactivity in many cases.

Re: No longer writing my own damn HTML

#54

Post by account42 »

mediumsmart wrote: post #45
Dalewyn wrote: post #32

Earlier quoted context omitted.

The ideal amount of JavaScript is zero.

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?

Why would you need JS for any of that?

Re: No longer writing my own damn HTML

#55

Post by account42 »

natnatenathan wrote: post #10

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.

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.

Re: No longer writing my own damn HTML

#56

Post by account42 »

b_e_n_t_o_n wrote: post #11
claytonwramsey wrote: post #5

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.

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 use…

You're not distributing the workload to clients, you're duplicating it.

Re: No longer writing my own damn HTML

#57

Post by netsharc »

claytonwramsey wrote: post #5
lelanthran wrote: post #3

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.

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.

> 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.

Re: No longer writing my own damn HTML

#58

Post by mediumsmart »

account42 wrote: post #54
mediumsmart wrote: post #45

Earlier quoted context omitted.

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?

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

#59

Post by lelanthran »

shkkmo wrote: post #18
b_e_n_t_o_n wrote: post #11

Earlier quoted context omitted.

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 use…

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, cachin…

> 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!

Re: No longer writing my own damn HTML

#60

Post by lsaferite »

lelanthran wrote: post #59
shkkmo wrote: post #18

Earlier quoted context omitted.

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, cachin…

> 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 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?

Post reply on HN