FYI: You can find more than 200+ (free, open source) ready-to-fork (use) Jekyll themes on Dr Jekyll's [1]. PS: Dr Jekyll's itself is an (open source) Jekyll site on GitHub Pages. Happy Jekylling.
[1] https://drjekyllthemes.github.io
Last time I tried GitHub Pages it got stuck in cache for several hours, could not get the article to update.
So switched to Netlify (https://www.netlify.com) which took about 15 minutes to setup for Jekylll, custom domain and SSL. Was a relief to be in control again.
I've used GitHub pages for small things like open source projects and blogs. But I recently switching to putting everything in an S3 bucket, and putting CloudFront or CloudFlare in front. I just didn't like abusing GitHub, and sometimes my site would go down, or the requests would take a really long time. Also, I only pay a few cents to put my site on S3.
I was using a very simple deploy script that just ran the aws command line tool, and then made a simple curl request to invalidate the cache in CloudFlare. I've seen Netlify mentioned a lot, and I was about to say that I don't really need it...
But I just signed up, and I was immediately convinced to switch over. Their sign up flow is amazing. It really is like a Heroku for static content.
The main thing is that I don't have to run my deploy script anymore, and I just `git push`. I could set up the same flow with GitLab CI, but this is just a much nicer service, and it's free. And they do cache invalidation automatically. I don't know how their CDN compares to CloudFlare or CloudFront, but I'm sure it's good enough.
P.S. Another thing to mention is that I'm actually generating a static site from my Rails app. So far I really like using Rails helper methods and libraries to generate my static landing page, such as the recaptcha and stripe gems. I'm using "stripe-rails" to define all my plans with a DSL in config/stripe/plans.rb, and then that automatically generates my pricing page HTML. Then I just run `wget --recursive` to download the root page and all of the links.
I have my root domain record pointing to a CDN where I host the static files, and then the sign up or sign in links point to the Rails site running on a subdomain, e.g. app.domain.com. I really love this setup, because no matter how much traffic your site gets, the landing page will never go down.
Similarly didn't understand the value add of Netlify, until I tried it. Now I can't imagine going back to the S3 bucket + Cloudfront setup.
BTW on our Middleman Netlify app, the assets generated are served up by a Cloudfront domain, so I'm assuming that's what they are using. You can inspect the page: https://monograph.io/
How can I trust them that they will be not screwing me with their free tier? Their next tier is $45 per month, seriously? Why not take $5/10/20 per month and at least earn my trust. I'm not going to use anything for free. If it's free either they burning VC money or I'm the product.
I cannot imagine hosting a static site with a company that only has a free tier, a $50/mo tier, and a $290/mo tier. $290/mo to host a Jekyll blog? What the fuck?
Either it's a scam, or it's meant to be used for far more than a Jekyll blog. So the parent's suggestion that "if you're frustrated with Github Pages, use this super expensive and overengineered service instead" comes off to me like the worst kind of advertising.
They're not even in the same league. Netlify is designed for something far more than Github Pages.
What puts me at quite a dilemma is the question, if I were a wordpress blog would I pay 45 a month for wordpress? How about with no plugins? OK, now how about for 290 a month? Suddenly just learning to deploy without netlify, on your own, becomes a lot more economical than paying the convenience tax.
Noticed that too when i re-read it, I do not work there and are not related to them in any other way than hosting my blog there. But I like their service and dont mind promoting it :)
Yeah, I'm a fan. I used their Netlify-CMS, and fell in love. You can either have them host your site wherein they put all your static assets on cloudfare, or self-host it all and set up the git push scripts yourself. I went with the latter method and set up a service worker to cache most of the site.
The result is a lightning fast static site with dynamic content that is easy for a non-developer to use!
Instead of committing generated HTML to a git repo, you could use GitLab Pages and use any static site generator and run any custom scripts you like.
They run commands on a container, you are not restricted to the blessed GitHub choices.
I've started playing around with using Firebase to host static sites. The free tier is pretty generous, and I won't exceed any of those restrictions anytime soon. SSL by default, custom domains, etc. are pretty nice. It's a Google product now, so do with that what you will, but setup was really straightforward.
I haven't used Firebase since before they were acquired by Google. Have they added features that allow you to serve web pages? Do you have some sort of UI set up to manage it or do you just manually update Firebase?
More or less, you have a directory with all your static pages, you say `firebase deploy` and then it creates a new version of your site in the firebase UI, where you can roll back to any previous version as needed. In a Hugo/whatever fashion, you'd have a script in your repo to regenerate that directory and then deploy. Still experimenting with the flow, but that seems to be the right one.
Haven't used Netlify, so I can't speak to it, unfortunately. Getting a POC set up for Firebase was painless though, so if you're familiar with Netlify, that may make a good blog post!
Unless Jekyll has changed a lot, using themes is a major pain. Since Jekyll doesn't enforce any particular structure, there's no way to have drop-in themes. Using a new theme is really about cloning a theme and then re-writing your site to hopefully make use of it. Or pick at bits and pieces you like and make your own custom theme.
I'm amazed there's no mention of GitLab's Pages. They seem to be quite superior in this aspect.
You can just configure CI to run any arbitrary script(s), and publish the resulting files. This also includes Jekyll (which is trivial to set up), but also other much complex scenarios.
Another Jekyll advantage: Jekyll it makes it easy to host a blog under your main domain.com/blog, without the need to use a subdomain, without the need to fiddle with Wordpress and without the need to switch your whole website to a (new) CMS. This is a huge timesaver (We use it at https://a9t9.com/blog and a very happy with it.)
I don't see why this is a problem. I don't use themes at all and I have my own look and feel. If you check the docs you will see that overriding the default theme is oretty straightforward.
Unless I'm mistaken, it seems the author missed this short paragraph in the docs:
With a clear understanding of the theme’s files, you can now override any theme file by creating a similarly named file in your Jekyll site directory.
So the gem is the base theme and you overwrite any of those theme files by inserting a same-named file in the same dir structure in your project root. I've haven't jumped to Jekyll 3 yet but if I'm reading this correctly, this doesn't seem like that big of a deal.
Except you don't drop the entire theme code into your project, just the pieces you want to overwrite. I have to believe here that the idea was to make themes extendable, not customizable (in the way previous Jekyll themes operated). This feels very similar to the concept of a child theme in WordPress, which simply extends the parent theme. Since we're just extending the parent theme and not editing those files, sure, put them in a gem and let me leave them out of my repository. Now you're only tracking the delta of your changes, not the whole theme. When done correctly, this should also let you more easily swap out the parent theme to something different while maintaining your changes with minimal effort.
Again, I haven't played with this yet, but the more I think about it the more it makes sense and I'm kind of looking forward to porting a few of the sites I manage.
> I have seen some repositories where people have written Travis jobs to do this exact thing. I feel that is an overkill, a slow process and downright exploitation of a free service
Is the “exploitation of a free service” part valid?
part of the point of jekyll to me is being in control of all the markup on the page, which is why the idea of using a theme goes against how I would use it.
I never understood the purpose of those "static page generators". The only thing they really do is add a html header to your text? Honestly, for all that hassle I prefer to copy-paste manually a few lines of html every time that I write a new file, and that's it.
Out of curiosity, which static page generator is this? I'm especially interested in generating JSON for clientside search, freeing me from linking to Google...
One I'm writing myself, but generating JSON for clientside search is actually fairly simple with most generators.
Like this quick and easy Jekyll article [0][1].
It all kinda depends how detailed you need your search engine to be. Fuzzy matching requires a little bit more JS. My go-to is lunr.js [2] to take care of all of that for me.
But basically all you need is a page that can iterate over all other pages that exist, (like a TOC would), and that can plug on the data into your search function for you.
That's just what's up for now. I'm in the middle of rebuilding one I wrote around Pandoc, so I tossed Jekyll up for now, though Jekyll is capable of everything I described, I just don't like its way of doing things.
Jekyll also makes use of Liquid (https://shopify.github.io/liquid/) which works great for auto generating page content. As an example I setup a simple one page Jekyll site that has a liquid script that automatically embeds in alphabetical order all images found in a folder.
Really? Well, this is just personal preference. I actually find html clearer for very simple documents. There are so many different markdown flavors that it is in practice rather ambiguous. You cannot easily copy markdown text from one conntext to another. For html, it is much easier.
> I want an automatic table of contents.
That's a really good reason, and probably the only reason that i can imagine to use generators.
> Source code highlighting is nice too.
I have been beaten not once, not twice, but three times by silent changes in jekyll setups that changed the rendering of my code (so everything looked really bad, with negative red blocks, etc). I hated this so much, and was so enraged, that I converted all my documents to pure html and now I am much happier. The reasons for the changes that broke my pages were completely banal ones, like moving from pygments to ruby-whatever (or vice-versa), etc.
The nice thing about generators IMO is that when you want to change something on every page (a simple example being a <meta> tag or the page heading) you just have to update the template and run the script, instead of updating every file.
I don't really love Jekyll either, that's why I have my own generator written in Node, and my dependencies are defined strictly in my package.json to keep things like markdown parsing from breaking.
Heck, generators can just be a sh script with some sed commands.
They do much more: primarily, they translate from markdown to HTML. This is, you don't write your content in HTML, you write it in a markup language that the static generator converts in an HTML document. Then, they can manage tags, paginating, menu structures, etc.
For instance, you can write
> {% note %} Something I want to emphasize {% endnote %}
And this will be converted by the generator into a properly-styled <div> according to your theme. If you change the theme, another run of the generator will convert the note to a different style, without you needing to change your content.
In that example yes, but if I put {% author %} Name {% author %}, a static build system can put the author name centered in the top of the page, or in a signature at the bottom, or in a floating div on the sidebar, or...
In your HTML document, you would need to change the structure manually for each content file, of which you can have thousands.
