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

161–170 of 194 posts

Re: My stack is HTML+CSS

#161

Post by fouric »

tomc1985 wrote: post #67
Rauchg wrote: post #21

This is an inaccurate over-simplification. If you just use HTML and CSS, you can also have really bad Lighthouse scores. For example, vanilla ` ` will ship the same image to every device, regardless of viewport size. Vanilla ` ` doesn't enforce setting `width` and `height`, which makes your layouts shift. Slow-loading images and layout shifts are the very things that will downgrade the "100" score he's currently prou…

Back in the day you sized your image for the web, there was no need for dimensions in img tags > For example, vanilla ` ` will ship the same image to every device, As it should be, for simplicity's sake. Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today. Let the browser handle layout, that is one of the things it is designed to do!

Removing the dimensions from the image tags is absolutely the wrong thing to do.

If you do this, then a browser/user/client that wants that information simply doesn't have it - you can't create bits from thin air.

If you leave the metadata in, then any browser that wants it can use it, and any brower that doesn't want it can ignore it.

I can code up a Greasemonkey script in a few minutes that will strip the width and height attributes from img tags, but nobody on earth can write a script that will magically detect what size the author wants them to be if they don't send that data to you.

Re: My stack is HTML+CSS

#162

Post by gunnarmorling »

What this approach doesn't really consider is that the same contents may appear multiple times on a site:

- actual post

- teaser on the front page

- RSS feed

- search index

- title in multiple "tag" pages

- title in sitemap

- title in a paged list

etc. pp. Sure, you can maintain all that manually, but it's so much easier using an SSG like Hugo.

Re: My stack is HTML+CSS

#163

Post by chubot »

kkoncevicius wrote: post #107
chubot wrote: post #74

I use Markdown and HTML, CSS, and Python (just stdlib, no packages) to generate static files. I think that will last just about the same length of time. http://www.oilshell.org/blog/ Markdown is a significant win, and CommonMark made it a lot better. CommonMark is a Useful, High-Quality Project http://www.oilshell.org/blog/2018/02/14.html Admittedly I need a Makefile, and Make is pretty impoverished for this use, and…

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.

Re: My stack is HTML+CSS

#164

Post by tomc1985 »

fouric wrote: post #161
tomc1985 wrote: post #67

Earlier quoted context omitted.

Back in the day you sized your image for the web, there was no need for dimensions in img tags > For example, vanilla ` ` will ship the same image to every device, As it should be, for simplicity's sake. Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today. Let the browser handle layout, that is one of the things it is designed to do!

Removing the dimensions from the image tags is absolutely the wrong thing to do. If you do this, then a browser/user/client that wants that information simply doesn't have it - you can't create bits from thin air. If you leave the metadata in, then any browser that wants it can use it, and any brower that doesn't want it can ignore it. I can code up a Greasemonkey script in a few minutes that will strip the width and…

They do, you can read the size data from the image file itself before you render it

Re: My stack is HTML+CSS

#165

Post by chubot »

cxr wrote: post #111
chubot wrote: post #86

Earlier quoted context omitted.

I agree it could have been phrased more nicely, but it actually pointed out something valid, which I didn't catch at first. The author hasn't written any posts in 5 years, and has ~15 total since 2010: https://blog.steren.fr/ As someone who blogs regularly, I'm more interested in the toolchain of people who HAVE done significant writing. I read blogs for at least a decade before I wrote one, and it's harder than it s…

> it could have been phrased more nicely That's an understatement. It's the kind of comment that should be in the grey. Comments that amount to pile-ons and smug dismissals—like the one above—are far more welcome here than they used to be. > Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! Among the things that Microsoft first started pushing to GitHub around the time that t…

Yeah it's definitely a problem that you have this "elsewhere" thing that rots. Having some kind of online editor is one way to solve it, although it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) [1]

I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build your blog.

Basically check in a spec for a container (Dockerfile) into VCS. It's done off of your machine, and it will "never" rot. You still have the cloud portability problem, and the "shell scripts and YAML are gross" problem. But those are solvable, especially for the relatively simple case of building a blog. I'm working on that:

https://news.ycombinator.com/item?id=25343716

[1] I think it's funny that VC's use non-startup platforms for their own blogs, because they know that blog platforms do not last.

https://blog.samaltman.com/

https://posthaven.com/

Re: My stack is HTML+CSS

#166

Post by Shared404 »

scooble wrote: post #118
Shared404 wrote: post #79

Earlier quoted context omitted.

> it's super easy when your page doesn't have even a header and/or a footer. It's not that hard even with. My stack consists of HTML/CSS, and a small program to stitch headers and footers onto documents generated with markdown. If anyone would like to see it, it should be in the Sourcehut page linked in my profile. The program is a hacky (but functional) piece of garbage however. E: Spelling

I did this. Had a header template, a footer template and a bunch of pages. My build script was basically ‘for page in pages cat header page footer > ouput’. Worked fine for its purpose (which was limited in scope).

That's just about what mine does as well, except pages will inherit headers above them in the directory structure, so I could make the top bar pretty without JS.

Re: My stack is HTML+CSS

#167

Post by tommyage »

indigodaddy wrote: post #136
rchaud wrote: post #114

Earlier quoted context omitted.

He mentions that SSGs require tooling and dependencies. And if all you need are dynamic headers and footers, just wrap those in 'php include' tags and rename the files to .php. It's still HTML and CSS that's getting rendered.

I’m not a web guy—- this should be safe from php vulnerabilities I would think, because there is no db and it’s just taking advantage of very limited/basic features of php right?

Php vulnerabilities are introduced by the developer.

Re: My stack is HTML+CSS

#168

Post by cxr »

chubot wrote: post #165
cxr wrote: post #111

Earlier quoted context omitted.

> it could have been phrased more nicely That's an understatement. It's the kind of comment that should be in the grey. Comments that amount to pile-ons and smug dismissals—like the one above—are far more welcome here than they used to be. > Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! Among the things that Microsoft first started pushing to GitHub around the time that t…

Yeah it's definitely a problem that you have this "elsewhere" thing that rots. Having some kind of online editor is one way to solve it, although it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) [1] I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build y…

> now standard "infrastructure as code" [...] check in a spec for a container (Dockerfile) into VCS

This is an example of the "predilection for certain systems and ways of working" that I referred to.

> it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?)

That's not really what I meant. My reference to WordPress was probably more misleading than I intended.

I really mean it when I say a human-readable document that's more SOP than blog post—it's not a metaphor. Consider a static site generator for an existing site, and consider the steps it performs on the input to produce the output. Specify these steps as a single, written document—one that you can print out, even. If you're doing it right (in contrast to how we "have been doing it all wrong" up till now), then you should be able to ask yourself, "Is this document suitable for publishing a copy of it on my site itself (or printing it out and dropping at the bottom of a filing cabinet)?", and you should be able to answer "yes".

(This is where the reference to WordPress came from—it's not exactly a "single document", but it is a bunch of PHP files that you could conceivably stitch together and consider to be one and which you can take a peek at so long as you're self-hosting. But even then it's not something generally available as another piece of content on your site, because WordPress doesn't "reveal itself" as such, i.e. there's no associated HTTP resource by default that's associated with the underlying WordPress-in-PHP engine itself, so its likeness as an example is strained.)

That still doesn't solve hosting and portability, but it's a separate matter from the authoring tools (etc) experiencing rot. In practice, this can be covered by the inclusion of an annex to the above SOP (or a completely separate set of procedures) that describes how to get your generated files onto whatever host you're currently using. (In software terms, this section would describe an "adapter" and its use.) Static site pages are already pretty portable by their nature, and you don't really move around enough to worry about it, really, but if you do move, then just document the new process by speccing out a new adapter.

The takeaway is that if these processes are too elaborate to be documented in this way, then it won't work. But if that's the case, then they're already too complex, period—which rules out Docker and pretty much anything else that's "standard" in the devops world right now. I've prototyped something like this, and describing the whole thing that fits into a document weighing I don't think relying on underspecced and inscrutable commercial systems like GitHub Actions is especially simple, resilient, or healthy. It seems to be subject to exactly the sort of rot mentioned before. Basically, what you said about VCs' blogs.

Re: My stack is HTML+CSS

#169

Post by chubot »

cxr wrote: post #168
chubot wrote: post #165

Earlier quoted context omitted.

Yeah it's definitely a problem that you have this "elsewhere" thing that rots. Having some kind of online editor is one way to solve it, although it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) [1] I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build y…

> now standard "infrastructure as code" [...] check in a spec for a container (Dockerfile) into VCS This is an example of the "predilection for certain systems and ways of working" that I referred to. > it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) That's not really what I meant. My reference to WordPress was probably more misleading than I intended.…

Hm I think we're coming at this from different angles... the whole "SOP" terminology confuses me, though I guess you mean "standard operating procedure".

I'm a programmer so when I hear "document on how to update something" I hear "untested set of manual steps". I don't understand why it isn't a shell script instead ...

----

I actually don't want to preserve an authoring experience forever. I expect that my authoring experience will change [1].

What I want to preserve is the data. Both the source data and the generated data. I have one git repository for each. And everything else is basically Unix tools that I can compile myself.

Ask me in 4 years about this stuff, or 10 years: http://www.oilshell.org/site.html

I bet it's all going to work, basically due to the "Lindy Effect". I can build everything from source even if people don't maintain it.

I actually wouldn't rely on Docker itself, I meant more a "spec for a container", but Dockerfiles now have multiple implementations like OCI.

The point of the shell layer is to NOT rely directly on Github Actions APIs, even while using the service. It's indeed a problem that all these cloud services have weird SDKs and command line tools.

However when you look UNDERNEATH these cloud services, you get a KERNEL and a SHELL. That is the "timeless API" I'm writing to. I already did that with continuous builds, and it would be similarly easy to port my blog toolchain to the MULTIPLE clouds this way, so I don't rely on one. (It wouldn't be easy for all problems, but it's easy for building static content.)

I realize this is all outside the norm and 99% of writers aren't going to use this toolchain. But it goes very well with the Oil shell project. Unix and document authoring are very closely related. Historically the first use of Unix was to create patent documents at Bell Labs.

I don't quite understand what you are getting at so I think you must have a much different use case. If you have an example then that would help. It seems like you might be talking more about a blog that lots of people are editing?

----

[1] Actually it JUST did after 4 years and at least a hundred posts. I used vim for 4 years, and now I switched to the online editor StackEdit because it has realtime preview. I wrote the last 2 blog posts in StackEdit and it worked great.

However the data remained exactly the same. Unix is data-centric, not app-centric. Apps are the things that rot.

Re: My stack is HTML+CSS

#170

Post by steren »

andai wrote: post #99
steren wrote: post #72

Earlier quoted context omitted.

My article covers that: > So... if I don’t use any templating system, how do I update my header, footer or nav? Well, simply by using the ”Replace in files” feature of any good text editor. They don’t need frequent updates anyway. The benefits of using a templating system is not worth the cost of introducing the tooling it requires.

You forgot to mention the main benefits! Your website does not fingerprint my device, nor present me with a dark pattern infested "do you want us to send your data to 50 ad networks" popup.

Yep, I ditched the Google Analytics script, because I don;t really care about metrics. (I wish my host would give me pageviews metrics)
Post reply on HN