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

My stack is HTML+CSS

blog.steren.fr

Post reply on HN
Print view View original

171–180 of 194 posts

Re: My stack is HTML+CSS

#171

Post by steren »

progval wrote: post #123
Evidlo wrote: post #93

Why can't HTML some kind of templating system, or even simple includes? Then I wouldn't need to use a static generator and could just author HTML directly. e.g. (with hypothetical and tags) template.html My Fancy Blog index.html Hello world Maybe this would compromise browser performance or add some kind of vulnerability, but authoring DRY HTML directly is my fantasy

> Why can't HTML some kind of templating system, or even simple includes? XHTML does, it's XSLT. For example: Page Title Hello world With this in stylesheet.xsl: My Fancy Blog And it's supported by all major browsers. Probably even IE6.

Never again I will touch XSLT. That's how I dumped my wordpress to HTML. I regretted it. https://github.com/steren/wordpress-to-html

Re: My stack is HTML+CSS

#172

Post by smichel17 »

forgotmypw17 wrote: post #124
dceddia wrote: post #16

While I really like the idea of serving raw HTML and CSS, I think that on the authoring side, a static site generator that ingests Markdown and generates HTML is a more practical way to go. I think writing raw HTML can work fine for small pages, and arguably it can be better than Markdown for pages with a lot of design elements, like landing pages. But for the typical blog post, or especially if the blog post has cod…

I don't like Markdown, because it too often takes what I meant and changes it to what I think I meant. I'm OK with ambiguity between implementations, but this one is a deal-breaker for me, and I've not encountered a Markdown implementation which doesn't do it. I think it's just a faulty idea to begin with.

Can you be more specific / give an example?

Re: My stack is HTML+CSS

#173

Post by pabe »

winrid wrote: post #103
dceddia wrote: post #27

Earlier quoted context omitted.

Oh boy, YouTube embeds! I went through checking the Lighthouse score on a few of my pages a while back, and the ones that had videos were performing pretty badly. It turned out that embedded YouTube videos were pulling down something like 1mb of JS, just to show the thumbnail , before the user even clicked Play. I ended up making a static thumbnail with a hover-over "play" icon that would replace itself with the real…

You can also use lazy loading with iframes.

This is often a very useful hack indeed! <3

Re: My stack is HTML+CSS

#174

Post by forgotmypw17 »

smichel17 wrote: post #172
forgotmypw17 wrote: post #124

Earlier quoted context omitted.

I don't like Markdown, because it too often takes what I meant and changes it to what I think I meant. I'm OK with ambiguity between implementations, but this one is a deal-breaker for me, and I've not encountered a Markdown implementation which doesn't do it. I think it's just a faulty idea to begin with.

Can you be more specific / give an example?

more specific: when i want something left alone or displayed as is, markdown does its own thing and wrecks it completely. and there is usually no easy way to negate it. no, pre-pending each line wit 4 spaces, only to get nowrap now, which works like shit in small displays, is not easy. it makes the user think and do extra work at minimum.

examples:

emoticons

urls with certain common symbols

code

textart

that,s just off the top

Re: My stack is HTML+CSS

#175

Post by 5350-uiop-1130 »

robertoandred wrote: post #102
5350-uiop-1130 wrote: post #91

Earlier quoted context omitted.

HTML, CSS and SSI includes would be an easier option. If you don't want to deal with Node.

How do you set the state of a nav with SSI? Does it know what the page being built is?

You can use variables in SSI and if/else conditions. So you could set state based on the URL or other environment variables.

It's actually fairly powerful and you can get quite a lot done with it.

https://httpd.apache.org/docs/current/howto/ssi.html

Re: My stack is HTML+CSS

#176

Post by Santosh83 »

naberhausj wrote: post #100

I agree wholeheartedly with this sentiment and have elected for the same thing on my website. The only difference is that I wrote a simple template based static site generator ( https://github.com/JosephNaberhaus/naberhausj.com/tree/maste... ) to keep my HTML sources in accordance with DRY. What I don't understand is how the linked page is downloading 1 MB of resources which unpack to nearly 2 MB. This page shouldn't…

It's the image of the Wordpress source and poor Lighthouse score. It's a poorly optimised PNG and a single file at 1 Mb instead of multiple sources for multiple screen resolutions. Of course, it does go with the thrust for simplicity in the article...

Re: My stack is HTML+CSS

#177

Post by kkoncevicius »

chubot wrote: post #163
kkoncevicius wrote: post #107

Earlier quoted context omitted.

I use something very similar on my website, except with a few twists - MultiMarkdown (instead of Markdown) for HTML, Perl for piping MultiMarkdown produced HTMLs through some regex changes, and redo instead of Make for rebuilds. If you are looking for Make replacement - I cannot sing enough praises for redo: https://github.com/apenwarr/redo

I've seen redo (and talked with apenwarr about it) although I think my brain is still stuck on static/declared dependencies. That doesn't apply to every problem but it definitely applies to a blog. Is your build parallel? That's one of my main requirements. I'd be interested in seeing the redo files if they're public.

I made the files public temporarily: https://github.com/karoliskoncevicius/website

My website is probably a lot simpler than yours. All the "do" files are at the root level. But I have to state that there is no "redo" syntax really. You just take the scripts that do things and save them to files with a "do" extension.

Re: My stack is HTML+CSS

#178

Post by alpaca128 »

ivanhoe wrote: post #66

Sure, it's super easy when your page doesn't have even a header and/or a footer. Try having a top-menu in your design, or some banners/ads, and then you need to change ALL the pages to change a single url. This is how we used to do things long time ago, and it sucked BIG TIME, and that's why people invented server-side includes and cgi and mod_php and all of that... it saves time, and your time costs much more than h…

> it saves time, and your time costs much more than hardware...

And the user's time doesn't?

If you can shave off a bit of loading/processing time for every request you will have improved the experience for countless people. Sure, using just HTML+CSS is a bit extreme, but for many sites the removal of some social media embeddings/trackers and switch to static site generation could improve it by an order of magnitude.

Re: My stack is HTML+CSS

#179

Post by alpaca128 »

josefresco wrote: post #109
411111111111111 wrote: post #71

Earlier quoted context omitted.

To be fair, static site generators are a thing and are very much underused in cooperations. He could have the same scores/performance and still get the full advantages you mentioned. But yes, handcrafting html is pointless at some point, especially if you have to update the contents every so often

> To be fair, static site generators are a thing There goes your super-lean stack and we're back to square-one.

If you know what you want you could write a trivial script which just pushes a Markdown file through pandoc(unless you just write html), concatenates it with the files for the header and footer (& maybe an inlined stylesheet) and appends a link to the index file. The result will be the same but applying changes on all pages is a matter of seconds.

Nothing against a lightweight stack, but simplicity doesn't necessarily have to exclude functionality.

Re: My stack is HTML+CSS

#180

Post by alpaca128 »

lhorie wrote: post #94
Hitton wrote: post #82

Earlier quoted context omitted.

>The benefits of using a templating system is not worth the cost of introducing the tooling it requires. Other people use static site generation, you use search and replace in your editor - not much of difference. Your approach is slower in long term, but with your on average 1 article per year it will take some time until you reach the threshold.

Eh, I don't think a person can ever write enough articles and rewrite their layout enough times that search+replace overhead ends up bigger than the upfront time it takes to read jekyll/hugo/whatever docs (plus debugging idiosyncrasies, etc). And even if search and replace was slower overall, you might be looking at a difference of minutes over a period of decades (i.e. it wouldn't actually matter in any practical se…

In reality the time saved isn't the only significant factor though, humans aren't machines after all. I'll gladly "waste" a bit more time if that time makes the process more enjoyable in the end.
Post reply on HN