It's really fashionable to smugly deconstruct things right now and claim that it is somehow better to do things this way. I could (and have) made some beautiful sites that rely only on HTML, CSS,...
Exemplary
It's really fashionable to smugly deconstruct things right now and claim that it is somehow better to do things this way.
I could (and have) made some beautiful sites that rely only on HTML, CSS, and a minimal amount of vanilla JavaScript. This is certainly a beautiful way to write a static site.
In no uncertain terms, this is not a good way to manage a blog.
The reason we have all the tools that we have is because at each step, they actually solve problems. These problems are things that the author handwaves away, but they absolutely shouldn't be handwaved away:
Doesn’t this mean that I have to type a bunch of boilerplate every time I create a new blog post?
My simple answer is: just copy it. My more advanced answer is [just copy it with extra steps]
This is just manual site-generating.
But how can I then keep the style and layout of all my posts and pages in sync?
Simple: don’t! It’s more fun that way. Look at this website:
There are reasons that we try to keep things in sync. Consider a newspaper that didn't have standard page sizes. You would think that the form factor was bad, and you'd think that whoever made the newspaper didn't know what they were doing. I have made a similar judgment about the author of this website.
There are other things that the author (smugly) brings up - "I fixed this with sed" "I wrote an RSS generator in PHP". Those are things that you shouldn't have to fix. They should just work.
The idea of counterculturalism for the sake of being different is silly, and this is a bad article with bad reasons for doing things.
OH, and as a final note:
HTML is unpleasant to write.
That isn't even true. Writing HTML isn't a problem for most front end devs. It's not interesting most of the time, but it's not particularly unpleasant. The reason that you might not want to mark your document up in HTML (and the reason that I prefer Markdown, personally) is because marked up HTML isn't a particularly beautiful thing in and of itself. A document that you write in Markdown is easy to parse (and easy to write) for people who don't know HTML.
I don't really think you have to do this if you set it up correctly? I have never used Jekyll, but I have a super basic website made using zola, which looks similar, and past the initial setup of...
Using a static site generator means that you have to keep track of two sources: the actual Markdown source and the resulting HTML source.
I don't really think you have to do this if you set it up correctly? I have never used Jekyll, but I have a super basic website made using zola, which looks similar, and past the initial setup of making the html templates and css theme, I don't have to look at anything not markdown. When you copy/paste the html and css for every page, you still have to keep track of the files. The proposed method kinda feels like copying a command instead of writing a makefile.
That was my biggest problem with the article, personally. I'm running a static website with Jekyll, and I only consider my original working document as the source. It was as easy as adding the...
That was my biggest problem with the article, personally. I'm running a static website with Jekyll, and I only consider my original working document as the source. It was as easy as adding the directory to the .gitignore file.
I mean, when you are designing executable programs, you don't track the differences in the binaries you're generating, do you? The choice to not track the files being generated seemed like a no-brainer to me.
That's perfectly fine; in your case Hugo was overkill. Static site generators are good when you have a lot of content you want to have displayed in a consistent way, such as if you were writing a...
That's perfectly fine; in your case Hugo was overkill. Static site generators are good when you have a lot of content you want to have displayed in a consistent way, such as if you were writing a blog. The very reason why static site generators are important is because they are designed for dynamic content. With a static site generator, you can typically change the layout of every page by editing a single file. That's not typically necessary on business card sites or personal websites with less than 10 or 20 pages.
It's really fashionable to smugly deconstruct things right now and claim that it is somehow better to do things this way.
I could (and have) made some beautiful sites that rely only on HTML, CSS, and a minimal amount of vanilla JavaScript. This is certainly a beautiful way to write a static site.
In no uncertain terms, this is not a good way to manage a blog.
The reason we have all the tools that we have is because at each step, they actually solve problems. These problems are things that the author handwaves away, but they absolutely shouldn't be handwaved away:
This is just manual site-generating.
There are reasons that we try to keep things in sync. Consider a newspaper that didn't have standard page sizes. You would think that the form factor was bad, and you'd think that whoever made the newspaper didn't know what they were doing. I have made a similar judgment about the author of this website.
There are other things that the author (smugly) brings up - "I fixed this with sed" "I wrote an RSS generator in PHP". Those are things that you shouldn't have to fix. They should just work.
The idea of counterculturalism for the sake of being different is silly, and this is a bad article with bad reasons for doing things.
OH, and as a final note:
That isn't even true. Writing HTML isn't a problem for most front end devs. It's not interesting most of the time, but it's not particularly unpleasant. The reason that you might not want to mark your document up in HTML (and the reason that I prefer Markdown, personally) is because marked up HTML isn't a particularly beautiful thing in and of itself. A document that you write in Markdown is easy to parse (and easy to write) for people who don't know HTML.
I don't really think you have to do this if you set it up correctly? I have never used Jekyll, but I have a super basic website made using zola, which looks similar, and past the initial setup of making the html templates and css theme, I don't have to look at anything not markdown. When you copy/paste the html and css for every page, you still have to keep track of the files. The proposed method kinda feels like copying a command instead of writing a makefile.
That was my biggest problem with the article, personally. I'm running a static website with Jekyll, and I only consider my original working document as the source. It was as easy as adding the directory to the .gitignore file.
I mean, when you are designing executable programs, you don't track the differences in the binaries you're generating, do you? The choice to not track the files being generated seemed like a no-brainer to me.
That's perfectly fine; in your case Hugo was overkill. Static site generators are good when you have a lot of content you want to have displayed in a consistent way, such as if you were writing a blog. The very reason why static site generators are important is because they are designed for dynamic content. With a static site generator, you can typically change the layout of every page by editing a single file. That's not typically necessary on business card sites or personal websites with less than 10 or 20 pages.