aboutsummaryrefslogtreecommitdiffstats
path: root/posts/2019/rework-with-nikola.rst
blob: 41fdda9c6d104549152d136f746daf812b4c6211 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
.. title: Rework with Nikola
.. slug: rework-with-nikola
.. date: 2019-04-21 00:30:05 UTC+02:00
.. tags: nikola, pelican
.. category: webdev
.. link: 
.. description: 
.. type: text

To revive my blog, I have spent the last few days converting my website from
|pelican| to |nikola|.
So far the experience has been quite great and I'll try to shortly sum up why.

.. TEASER_END

For me, the use of static site generators has always been about ease of use and
robustness. However, with |pelican| I eventually found myself in a situation
with too many customizations (theme, functionality only achievable through
extra plugins). This obviously proved quite limiting.

I looked around for other static site generators already more than a year ago:
By now there are |static_site_generators|. Languages such as |Ruby| or
|javascript| (in whatever hip framework of the day) were an absolute no-go for
me, but I wanted something that could potentially do templates in Jinja2, which
is quite powerful and versatile and I had already gotten acquainted with
through working with |ansible|.
|nikola| provides just that, being Python based (like |pelican|).

Last year I had the opportunity to work with |nikola| on the website for
|lac2018|, which was a very pleasant experience. There I was able to integrate
scripts (in a disgusting way, I have to admit) to scrape calendar events and
turn their information into pages and automatically deploy it and additional
data required for our streaming service with the |voc|.

This week I finally pulled the plug on the old theme and way of building and
deploying my website. This felt quite good, as I deleted quite a few things.
The advantages of |nikola| over |pelican| became apparent very early:

* Less fragmentation: The CLI is much cleaner, there is only one configuration
  file
* Easier integration: Multi-level pages, navigation menu, image galleries and
  robots.txt generation without hackery and additional plugins
* more strict use of ReStructuredText

In the end I was quite happy to not deal with so many custom solutions anymore
and even exchanged my custom theme with one of the current default ones. That
being said: Theming seems also more straight forward to customize... I just
didn't feel like doing that.

Closing, I would like to add, that I hope this will lead to a more frequent
release flow on my website again. As you can imagine *a lot* has changed since
2016. More on that in the upcoming posts. Promise!

.. |pelican| raw:: html

  <a href="http://blog.getpelican.com/" target="_blank">Pelican</a>

.. |nikola| raw:: html

  <a href="https://getnikola.com/" target="_blank">Nikola</a>

.. |static_site_generators| raw:: html

  <a href="https://www.staticgen.com/" target="_blank">plenty</a>

.. |ruby| raw:: html

  <a href="https://www.ruby-lang.org/en/" target="_blank">Ruby</a>

.. |javascript| raw:: html

  <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript" target="_blank">JavaScript</a>

.. |ansible| raw:: html

  <a href="https://www.ansible.com/" target="_blank">Ansible</a>

.. |lac2018| raw:: html

  <a href="https://lac.linuxaudio.org/2018/" target="_blank">Linux Audio Conference 2018</a>

.. |voc| raw:: html

  <a href="https://c3voc.de" target="_blank">VOC</a>