If you’re reading this, you are reading a web page generated by a static site generator I built. Before this, I used Hugo and then Zola. Both are
great at what they do, but they had a lot of features I didn’t need and some features I wanted that
they didn’t have. One of the key features I really wanted was the ability to format the HTML code
generated by the static site generator.
Today I felt really upset about something that I shouldn’t have to be. I needed to add a tool to an
open-source project I’m working on, and after some searching on the web, I found one that I could
use. But then I learned that the project had been moved to a paid service after being open source
for a while. I felt betrayed and unreasonably angry, even though I understood perfectly why the
developers chose to do this.
I think I’ve known this for a long time now but it’s only today that I’ve fully articulated this by
myself. A lot of smarter people have talked about this before but it’s only today that I’ve put this
idea into words on my own.
This is Part 3 of a series of posts about refactoring
Nitrolinks
out of Pondo. Last time we’ve
successfully copied the Nitrolinks tests from
Pondo
but left the original tests on Pondo. This time we’ll move them out of Pondo for
good.
This is Part 2 of a series of posts about refactoring
Nitrolinks
out of Pondo. Last time we’ve
successfully moved Nitrolinks out of Pondo
but we left most of the Nitrolinks-specific tests on the Pondo source code
itself. This time we’ll move the tests to Nitrolinks so we can narrow Pondo’s
test concerns.
I am building Pondo as an experiment on how
to build a functional, modern web application without necessarily using a large
front-end framework (e.g. Angular, Ember, React). The idea is to mostly develop
applications as one would within the usual semantics of the normal
Request-Response cycle. If you’ve used Pjax,
or Turbolinks then you’re familiar
with this.