21–30 of 92 posts
open source headless CMS Strapi https://strapi.io and Nuxt.js frontend.
If anybody knows a python and flask based headless CMS let me know!
Earlier quoted context omitted.
Having few assets is better than having a fancy asset pipeline. https://www.gatsbyjs.org/ supports code splitting and since it uses JavaScript, CSS generation libraries like styled-components, Glamourous, and JSS are available. That means only outputting the CSS and JS that are needed for the page. This is great for blogs where someone might only read one article. The Hugo community is working toward minimal assets t…
> Having few assets is better than having a fancy asset pipeline. It's not about a fancy asset pipeline. It's taking app.css and turning it into app.a5fec617.css so that you can configure your web server to cache it forever. It's important to do this for CSS, JS and all of your images and other assets. Each blog post of mine has a cover image and with 170 blog posts, that's 170 blog images that need to be md5 tagged.…
_config_local.yml:
html_refresh: true
html_refresh_rate: 5
jekyll serve --config _config.yml,_config_local.yml --force-polling
{% if site.html_refresh %}
{% endif %}
Hugo’s key differentiators: 1. Ease of install 2. Speed (critical for large sites) 3. Integrated live-reload while editing in near realtime 4. Multilingual capabilities 5. Flexible 6. Very strong community 7. Very good & comprehensive documentation (but not perfect…yet)
Other than 3., all other points are valid for Jekyll as well. So why move, other than for the sake of just migrating (which can be fun too...)?
My Jekyll(Ruby) script was running over a day and never finished. Hugo(Go) ran in about 5 minutes. Granted there are over 10,000 pages being generated by Jekyll but it was so painfully slow, I couldn't possibly have a daily CI system that generated the site.
I'm still fixing some https issues with GitHub static site hosting, but it should be working soon.
We’re running our blog on Jekyll. Is there any good reason to migrate to Hugo? In the article I’ve found this comment: Hugo’s key differentiators: 1. Ease of install 2. Speed (critical for large sites) 3. Integrated live-reload while editing in near realtime 4. Multilingual capabilities 5. Flexible 6. Very strong community 7. Very good & comprehensive documentation (but not perfect…yet) Other than 3., all other point…
I feel like people spend more time migrating blogging engines than actually blogging.
I used Ghost, Octopress (which was basically Jekyll), a variety of SSGs that I tested and never got to deploying, and then Pelican.
Since January 2016, though, infrastructure work basically stopped and I just write things, and occasionally dink the theme.
Earlier quoted context omitted.
> Having few assets is better than having a fancy asset pipeline. It's not about a fancy asset pipeline. It's taking app.css and turning it into app.a5fec617.css so that you can configure your web server to cache it forever. It's important to do this for CSS, JS and all of your images and other assets. Each blog post of mine has a cover image and with 170 blog posts, that's 170 blog images that need to be md5 tagged.…
Without md5 tagging but with a reasonably configured web server, the browser gets an eTag in the response headers to the first request to load that cover image , and sends it in the headers to the second request and gets a 304 Not Modified response with an empty body. The size of the cover image is completely moot when comparing a proper Hugo config vs a proper asset pipeline config.
If the url stays the same, you never know what version your visitors will get. You might publish a new version, but the user would not see it due to browser caches or proxies.