The complex simplicity of my static websites
alinpanaitiu.com
alinpanaitiu.com
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.
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.
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.
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.
We're different my man.
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 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.
1. https://github.com/vscode-neovim/vscode-neovim
div.thing {tab}
expands to <div class="thing">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 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.
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.
Exactly my feeling.
There's quite a bit to like at a glance, but I noped out pretty hard after actually trying to use it.
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).
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.
I like toml because it's easy to read and write as a human, even without text editor help...
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.
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.
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.
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?
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.
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.
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.
If anyone knows the reason, feel free to share.
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.
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
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”.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.