Using Jekyll and GitHub Pages
pulkitsharma07.github.io
pulkitsharma07.github.io
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.
The result is a lightning fast static site with dynamic content that is easy for a non-developer to use!
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.
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/
https://wordpress.com/pricing/
Same thing here.
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.
I use Hugo for my static sites:
- https://scripter.co - https://ox-hugo.netlify.com - https://ox-hugo.netlify.com/test (yes, that's a different Hugo site than above)
Personally I would skip GitHub and just put it up on a cheap vps, you can set it up to auto compile on a git push like GitHub as well. [2]
[1]https://learn.cloudcannon.com [2]https://www.digitalocean.com/community/tutorials/how-to-set-...
You can set things up so Travis has a bunch of encrypted variables and can push to your github.
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.
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.
According to the SEO Guru(s), this brings a SEO advantage https://moz.com/community/q/moz-s-official-stance-on-subdoma...
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.
I can't see why someone should use gem-based themes, when eventually they'll need to dump the entire code into the Jekyll project.
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.
Is the “exploitation of a free service” part valid?
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.
an <em> emphasized </em> word
In your HTML document, you would need to change the structure manually for each content file, of which you can have thousands.
I want an automatic table of contents.
Source code highlighting is nice too.
I use mdbook and not Jekyll anymore, but it's similar stuff.
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.
Just use ones that follow http://commonmark.org/ They should render the same.
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.
My static generator:
* Renders boilerplate
* Builds the correct file paths
* Generates a JSON tree for a clientside search engine
* Generates a RSS feed
* Creates a global navigation menu
* Examines all my code blocks, and if they're valid, also renders output into the finished file
* Spelling and grammar checks my pages
I could do all that manually, but it'd be a pain and take a lot longer.
Not OP, but it's on their profile.
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.
[0] http://mathayward.com/jekyll-search/