The complex simplicity of my static websites(alinpanaitiu.com)
alinpanaitiu.com
The complex simplicity of my static websites
https://alinpanaitiu.com/blog/complex-simplicity-of-static-websites/
54 comments
Author here ^_^ for me it's much more important to be easy to write, than easy to read, and it accomplished that goal.
I almost never revisit parts of the page I've already written, they may sit there for years untouched, or I may delete them and do a whole different layout from time to time.
It's definitely painful to edit small details after months of not seeing the code, so it's not for people that need to do that often.
I also understand that for most people, indentation is not a good separator. I worked with Python for so many years, that I probably view white space differently than others. Symbols are visual overload for me, I just need 4 spaces to see structure and separation.
I almost never revisit parts of the page I've already written, they may sit there for years untouched, or I may delete them and do a whole different layout from time to time.
It's definitely painful to edit small details after months of not seeing the code, so it's not for people that need to do that often.
I also understand that for most people, indentation is not a good separator. I worked with Python for so many years, that I probably view white space differently than others. Symbols are visual overload for me, I just need 4 spaces to see structure and separation.
So, HTML was too cumbersome to write because of the </> symbols so instead you created an entire toolchain to compile it, based off some arbitrary HTML like language. That isn’t cumbersome…? Just write HTML my man.
I don't like it. It gives me pain in my hand muscles to have to hold Shift and write those symbols all the time. It also bores me and annoys me.
We're different my man.
We're different my man.
> I don't like it.
I agree. I don't like writing HTML either. That being said ....
> It gives me pain in my hand muscles to have to hold Shift and write those symbols all the time. It also bores me and annoys me.
I use vim, and with some macros and vimscript in my config, tags are not hard to write (especially if you're willing to make a ftplugin abusing the leader key + first letter of tag to automatically write the common tags).
Even without vim, I was pleasantly surprised at how VSCode (using some HTML plugin) handled raw HTML editing.
You don't need to ever hit the shift key if using vim, and you get pretty similar autocomplete in VSCode (and I assume other editors too).
I agree. I don't like writing HTML either. That being said ....
> It gives me pain in my hand muscles to have to hold Shift and write those symbols all the time. It also bores me and annoys me.
I use vim, and with some macros and vimscript in my config, tags are not hard to write (especially if you're willing to make a ftplugin abusing the leader key + first letter of tag to automatically write the common tags).
Even without vim, I was pleasantly surprised at how VSCode (using some HTML plugin) handled raw HTML editing.
You don't need to ever hit the shift key if using vim, and you get pretty similar autocomplete in VSCode (and I assume other editors too).
VS Code is fine for creating HTML but a pain in the ass for editing existing tag pairs.
You could use the Neovim plugin[1] which allows you to use Neovim as a backend server and access editing plugins[2][3] that way.
1. https://github.com/vscode-neovim/vscode-neovim
2. https://github.com/tpope/vim-surround
3. https://github.com/andymass/vim-matchup
1. https://github.com/vscode-neovim/vscode-neovim
2. https://github.com/tpope/vim-surround
3. https://github.com/andymass/vim-matchup
Unfortunately I did not start with vim, and when I tried to learn vim (and a few years after, kakoune), I had already created a strong muscle memory for Sublime Text and it was frustrating to start from scratch.
I agree that there are editor solutions for this, but I also write and edit websites on my iPhone sometimes. As you can imagine, it's a day and night difference between editing Plim and editing HTML on a phone.
I agree that there are editor solutions for this, but I also write and edit websites on my iPhone sometimes. As you can imagine, it's a day and night difference between editing Plim and editing HTML on a phone.
Hasn't this been solved with editor extensions such as Emmet?
div.thing {tab} <div class="thing">You don't have to hold Shift and write those symbols all the time. Use abbreviations. Use Emmet for repetitive blocks
You know you're not supposed to write the symbols in and around the tags by hand, right?
https://github.com/aca/emmet-ls
https://github.com/aca/emmet-ls
I see everyone keeps reminding me of Emmet. I know about it, but it does not exist on a phone or iPad where I sometimes need to do small changes while on the go.
I frequently travel for days without my laptop, and need to maybe add an FAQ entry or clarify a feature. Doing that with Plim is a breeze.
I frequently travel for days without my laptop, and need to maybe add an FAQ entry or clarify a feature. Doing that with Plim is a breeze.
I'll throw in that I love the look of plim, and if I were doing a lot of html authoring I would probably use it too.
I really like low-symbol languages for day to day stuff. It's why, as much as I deeply despise it, I still often use yaml.
If I need safety in some form, yeah - lots of symbols allow a lot more information density, and that helps resist misunderstandings. That's hardly necessary in a personal blog though.
I really like low-symbol languages for day to day stuff. It's why, as much as I deeply despise it, I still often use yaml.
If I need safety in some form, yeah - lots of symbols allow a lot more information density, and that helps resist misunderstandings. That's hardly necessary in a personal blog though.
It's less cumbersome for them to write their content, yes. There's initial upfront effort, but their subjective experience of actually using the system to do what they want to do is better.
It's the same reason why people invest dozens or hundreds of hours in configuring their editor - yes, the defaults work fine, but you can make them work better for you. And yes, you're probably not going to make that time back... but if the actual experience of using it is better, it's still a net win for the author.
It's the same reason why people invest dozens or hundreds of hours in configuring their editor - yes, the defaults work fine, but you can make them work better for you. And yes, you're probably not going to make that time back... but if the actual experience of using it is better, it's still a net win for the author.
They probably write a lot more html than setup code. And reducing friction while authoring is a big deal for many people - often the difference between things being written at all vs not.
What about SQL ? Give me a LISP and I can fix the most annoying aspects or twist my own `sqlet` dagger against myself and give me death.
Angle brackets are merely verbose sexpr's. And syntax is both meaningless and hugely impactful: semantics are the most important thing, but we spend all our time interacting with the syntax, so it makes sense to optimize for it.
Webdev is mired in non-essential complexity still. Small, focused tools that let you enjoy working on the web should be celebrated. Besides, HTML is merely an agreed-upon protocol for distributing hypertext. The workflow for authoring it is bound to be very personal.
Webdev is mired in non-essential complexity still. Small, focused tools that let you enjoy working on the web should be celebrated. Besides, HTML is merely an agreed-upon protocol for distributing hypertext. The workflow for authoring it is bound to be very personal.
Some people just enjoy complexity for the sake of complexity.
However if you try and convince them they're over-complicating, they'll fight you on that point.
I agree with your take, but I also think it's wasted effort.
However if you try and convince them they're over-complicating, they'll fight you on that point.
I agree with your take, but I also think it's wasted effort.
[deleted]
> I marveled at Hugo’s speed, loved the fact that it supports theming (although it’s not as simple as it sounds) and that it has a lot of useful stuff built-in like syntax highlighting, image processing, RSS generator etc. But it took me sooo long to understand its structure.
Exactly my feeling.
Exactly my feeling.
That's not the complexity of SSGs, that's the complexity of Hugo. It's just not well designed, and is too complex for what it does.
I think that people eventually get the Stockholm syndrome of "I understand how it works after N hours, so it must be ok", but the problem is that N is larger than with other SSGs.
Either way, it's nothing wrong with it, and it's a good SSG if you know how to use it, it just takes longer to learn compared to eg Zola (which still is a bit underdocumented, but much easier to grasp).
I think that people eventually get the Stockholm syndrome of "I understand how it works after N hours, so it must be ok", but the problem is that N is larger than with other SSGs.
Either way, it's nothing wrong with it, and it's a good SSG if you know how to use it, it just takes longer to learn compared to eg Zola (which still is a bit underdocumented, but much easier to grasp).
I came to say the same thing :| It doesn't help that Hugo really does not help you figure out that e.g. your var is slightly misspelled and is going unused. Or much of anything that could go wrong (and frequently does).
There's quite a bit to like at a glance, but I noped out pretty hard after actually trying to use it.
There's quite a bit to like at a glance, but I noped out pretty hard after actually trying to use it.
I’ve been slowly working on a DSL that takes a similar approach. I’m creating a language for UI designers to specify components:
https://github.com/matry/documentation
I’m using a pythonic syntax because it feels more intuitive to non-programmers. One thing I’m running into, and that you’ll run into as well, is that the lack of delimiters can be its own source of complexity. If you nest too deeply, it becomes hard to read.
https://github.com/matry/documentation
I’m using a pythonic syntax because it feels more intuitive to non-programmers. One thing I’m running into, and that you’ll run into as well, is that the lack of delimiters can be its own source of complexity. If you nest too deeply, it becomes hard to read.
Working on a similar thing that uses toml to define pages... But closed source, for now...
I like toml because it's easy to read and write as a human, even without text editor help...
I like toml because it's easy to read and write as a human, even without text editor help...
“Complex simplicity” is a good phrase that kind of gets at my theory that friction (simplicity of operation) in publishing is conserved across the stages of setting up, operating, and maintaining the publishing apparatus:
https://joeldueck.com/friction.html
If you make things simpler in one stage, you ultimately do so by making the other stage(s) more complicated.
https://joeldueck.com/friction.html
If you make things simpler in one stage, you ultimately do so by making the other stage(s) more complicated.
On this theme: https://indieweb.org/manual_until_it_hurts
I'm curious. What is "accolade-free code"? It's referenced and highlighted as if it had a link but it doesn't, and Google appears to think it's a hapax legomenon (or whatever the equivalent is for phrases instead of words).
I think I confused the translation here. I'm Romanian where the {curly brackets} are called "acolade". I read the word "accolade" in English a few times and wrongly assumed it means the same thing as in Romanian.
Ah. Thanks. Yes, "accolade" in English is an award or privilege, or the tap you get with a sword when you become a knight.
I wish English had a separate word for those too!
I really dig this; you do you!
To show my appreciation for your approach, I've translated your example into Wisp. It's.. not everything I'd have hoped for, but it was worth a shot. Might have been able join a few more newlines with a bit more thought.
https://www.illucid.net/static/alin23/src.html
To show my appreciation for your approach, I've translated your example into Wisp. It's.. not everything I'd have hoped for, but it was worth a shot. Might have been able join a few more newlines with a bit more thought.
https://www.illucid.net/static/alin23/src.html
Tried using Hugo a few times, each time I quit because figuring out how to use it is a PhD exercise in confusion
Hugos documentation ia hard to penetrate when learning how it works. I probably had 6 or 7 fals starts before i 'got' it. Which is a shame, because Hugo is really not that hard and it is very nimble and powerful.
There has been several rounds of discussions on how to improve the docs for newcomers, but as far as I know, it has not been finished.
There has been several rounds of discussions on how to improve the docs for newcomers, but as far as I know, it has not been finished.
> imgproxy server that needs to run somewhere publicly available, be kept alive and secure
Why make this runtime instead of a prepublish script (even a git commit hook or CI action)? Doesn't seem like your images would ever change so it introduces a point of failure, but I guess relieves you of ever thinking about images again?
Why make this runtime instead of a prepublish script (even a git commit hook or CI action)? Doesn't seem like your images would ever change so it introduces a point of failure, but I guess relieves you of ever thinking about images again?
No mention of Emmet for avoiding writing HTML by hand.
This looks very non-simplistic in all the wrong ways.
Not to say I haven't been down this path[1]; it's only after you give up and do the simplest thing possible that takes the least amount of time and knowledge that you realise how much time and effort you burned learning tools you will never use again.
There are two questions to ask when making your blog post:
1. What is the most important question that I want to answer in this post?
2. Why do I need to learn these other technologies to answer that question?
[1]"I just want a simple blog, lemme use plain html" ... 10 months pass ... "It would be nice to have a pro-looking thing with a contact form and comment box on each blog post, so lets use wordpress" ... 3 years pass ... "Comment boxes are overrated, all I'm getting is spam. I know, I can use emacs org-mode and export to HTML; I'm already using emacs for everything else!" ... 2 years pass ... "Org mode output just not flexible enough, even though I've beaten it into submission to do javascript, navigation, and auto-posts to reddit, HN, etc."
I am now at the point where I have a small shall script that runs pandoc on a markdown file. I don't think I'll ever change from this: markdown is damn quick to type, the flexibility of HTML, CSS and Javascript is there when I need it and I don't need buttons for HN, reddit, nor a comment form for each post.
So, honestly, just use markdown and a generator for your blog. Using anything that requires more knowledge than that results in less compelling blog posts, because you're focused on the wrong thing.
Not to say I haven't been down this path[1]; it's only after you give up and do the simplest thing possible that takes the least amount of time and knowledge that you realise how much time and effort you burned learning tools you will never use again.
There are two questions to ask when making your blog post:
1. What is the most important question that I want to answer in this post?
2. Why do I need to learn these other technologies to answer that question?
[1]"I just want a simple blog, lemme use plain html" ... 10 months pass ... "It would be nice to have a pro-looking thing with a contact form and comment box on each blog post, so lets use wordpress" ... 3 years pass ... "Comment boxes are overrated, all I'm getting is spam. I know, I can use emacs org-mode and export to HTML; I'm already using emacs for everything else!" ... 2 years pass ... "Org mode output just not flexible enough, even though I've beaten it into submission to do javascript, navigation, and auto-posts to reddit, HN, etc."
I am now at the point where I have a small shall script that runs pandoc on a markdown file. I don't think I'll ever change from this: markdown is damn quick to type, the flexibility of HTML, CSS and Javascript is there when I need it and I don't need buttons for HN, reddit, nor a comment form for each post.
So, honestly, just use markdown and a generator for your blog. Using anything that requires more knowledge than that results in less compelling blog posts, because you're focused on the wrong thing.
For blogs, I agree. And this is the solution I arrived at, just write markdown files, and have Caddy serve them as HTML without any setup.
But I mainly write presentation webpages for apps, people, events etc. and that's what all this article was about. A templating language is a godsend for that.
But I mainly write presentation webpages for apps, people, events etc. and that's what all this article was about. A templating language is a godsend for that.
Tried Hugo, Ghost and a few others.
Still stuck on WordPress for a lack of good plugin ecosystem.
Are things like Pug or Slim/Plim, etc. really worth the added complexity, dependencies?
For me it is. Of course I would have preferred to "just write Plim" and have the browser understand it.
How cool it would have been if the browser would understand different markup flavors (symbol-heavy, white space based etc.) and have integrated templating...
But it's ok, after the Makefile is stuffed with the pinned dependencies, I can forget about that and just write.
How cool it would have been if the browser would understand different markup flavors (symbol-heavy, white space based etc.) and have integrated templating...
But it's ok, after the Makefile is stuffed with the pinned dependencies, I can forget about that and just write.
I use Slim for all my static site needs, it's supported out of the box with Nanoc which is my tool of choice these days - although it's more of a static site toolkit than generator.
https://nanoc.app/
https://nanoc.app/
There's probably a reason why haml (and also coffeescript) didn't take off and got abandoned.
If anyone knows the reason, feel free to share.
If anyone knows the reason, feel free to share.
Author here! When CoffeeScript 2 got released about 6 years ago, me and a few others went all into it, because huge effort went into supporting ES6 features in the compiler.
Still, TypeScript appeared 1 year after and took over everything.
I had to use both heavily, and I am 3x slower and more verbose in TS than CS. But hobby dev is not what guides adoption.
It's what gets used inside companies that decides this, and companies prefer slow but stricter languages, that help devs collaborate. Not languages that allow super fast development but results into hard to revisit code.
Still, TypeScript appeared 1 year after and took over everything.
I had to use both heavily, and I am 3x slower and more verbose in TS than CS. But hobby dev is not what guides adoption.
It's what gets used inside companies that decides this, and companies prefer slow but stricter languages, that help devs collaborate. Not languages that allow super fast development but results into hard to revisit code.
I just finished a site they commisioned me to port to Jekyll from WordPress ([0], live version at [1]). And though I wasn't much happy about how Liquid makes the layout templating look dirtier quickly I still understand why static generators were a great idea and offer much more flexibility and reliability than WP - and to be honest I prefer Liquid's mess than PHP's mess.
Granted, at least Jekyll was conceived as a blogging system and quickly falls short when needing to do a bit more complicated stuff (like having multiple sections of content from a single Markdown file [2]), and alas it seems it's struggling to keep in pace with the numerous competitors it has now.
[0] https://github.com/acidrums4/ideawave
[1] https://acidrums4.github.io/ideawave/
[2] https://github.com/jekyll/jekyll/issues/246
Granted, at least Jekyll was conceived as a blogging system and quickly falls short when needing to do a bit more complicated stuff (like having multiple sections of content from a single Markdown file [2]), and alas it seems it's struggling to keep in pace with the numerous competitors it has now.
[0] https://github.com/acidrums4/ideawave
[1] https://acidrums4.github.io/ideawave/
[2] https://github.com/jekyll/jekyll/issues/246
Jekyll has a fork called Bridgetown which is, granted, a little more complicated. If you like Ruby but want a more fully-featured site generator there's Middleman which I highly recommend.
I guess if it works for you but I do not see the appeal to this at all
FWIW, I've been using http://zim-wiki.org for YEARS. Sites a little messy and I need to clean it up, but it's extremely functional; I host my college classes websites from it, to the point that I forced myself to learn the Canvas API, to just clone the page from this site to the front page of Canvas and change the links so they come back here.
http://jrm4.com
http://jrm4.com
Seriously, this is audiophile content for web nerds. No one cares what gold-plated setup you listen to Phish albums on; divert all that energy you're spending on software gardening into improving the content of your website.
I tried touching on that in this paragraph:
One could say I could have spent all that time on writing vanilla HTML, CSS and JS and I would have had the same result in the same amount of time. I agree, if time would be all that mattered.
But for some people (like me), feeling productive, seeing how easy it is to test my ideas and how code seems to flow from my fingertips at the speed of thought, is what decides if I’ll ever finish and publish something, or if I’ll lose my patience and fallback to comfort zones.
Having to write the same boilerplate code over and over again, constant context switching between files, jumping back into a project after a few days and not knowing where everything was in those thousand-lines files.. these are all detractors that will eventually make me say ”f••k this! at least my day job brings money”.I guess we all bring our own background to the topic. In my case, noodling on a static site generator is a classic procrastination tarpit, something I find myself doing when writing has hit a rough patch, an easy offramp from something more worthwhile.
For you it sounds like it serves a very different, and more positive purpose. So I'm kind of torn; I don't want to be in the position of saying "you are enjoying yourself wrong", but I also think this forum is already heavy with discussions of toolchains. Gearheads have every right to have long conversations about the elaborate constructions that make them happy, but on any forum they are going to find themselves in tension with people who just want the gear to do stuff.
For you it sounds like it serves a very different, and more positive purpose. So I'm kind of torn; I don't want to be in the position of saying "you are enjoying yourself wrong", but I also think this forum is already heavy with discussions of toolchains. Gearheads have every right to have long conversations about the elaborate constructions that make them happy, but on any forum they are going to find themselves in tension with people who just want the gear to do stuff.
It's ok for nerds to share their experiences with other nerds who like that sort of stuff. This is the content for them.
[deleted]
If the goal were to generate pages from a document DSL like Markdown I'd understand the need for a transpiler. But here the author's done it to make the HTML "look cleaner".
Boilerplate is barely reduced, it's mostly been replaced with different symbols and words. Now instead of some extra characters, you've got an additional build step and a new suite of tokens to learn.
And sure that code looks "clean", but it's much less clear than the original source would be. Whitespace is syntax, the delineation between tag & content is much less clear, you can no longer see where tags end without carefully following the indentation or using editor highlights. Then you've got HTML & CSS semantics in a YAML-but-not-quite presentation with both CoffeeScript (javascript-but-not-quite) AND Python, all right next to each other, with the only separation at the bottom end being a line break.
I just fundamentally don't understand it. I suppose it's not aimed at me.