21–30 of 47 posts
If you need a way of deploying a Hugo site, I highly recommend Stout [1]. 1. http://stout.is
My vote for deploying static sites goes to https://surge.sh/ . It's wicked simple and CDN backed!
If you're interested in the beta, hit me up on twitter @_brianknapp.
If you need a way of deploying a Hugo site, I highly recommend Stout [1]. 1. http://stout.is
I'm currently using a simple script that pulls together fossil, s3cmd and gnu parallel to send the content over to s3. Fossil is used to track what changed, s3cmd is the work horse and parallel uploads multiple files at a time.
Earlier quoted context omitted.
I installed and played with Jekyll on a windows box. It was a horrible experience because of installing Ruby and all the dependencies. I'd like to give Hugo a shot just because I know it's Go and it will likely be a single binary with no deps that just works.
> I know it's Go and it will likely be a single binary with no deps that just works. It is and it does.
My pros and cons of Hugo:
+ It's fast.
+ Like, really, really fast. I'm looking at + A lot of really nice out-of-the-box stuff like markdownifying arbitrary strings, rss and sitemaps, etc.
+ Extensible front matter system. (I abuse it to stuff an arbitrary JSON object into each page.)
+ Did I mention how fast it was?
- Debugging is hell. Error messages are unintelligible and generally distract from whatever the actual issue is.
- The structure of a theme is sort of unintuitive, but that may be personal preference.
- Lack of support for more user-friendly templating languages like Jinja2 (this is likely due to speed, but I'd still like the options.)
Earlier quoted context omitted.
It's easier to write HTML by hand if you only have a few pages. But if you have a few hundred or a few thousand pages a site generator can save you a lot of time and sometimes your sanity.
Apart from that, separating content and design can also be a big deal for working with different kinds of tooling. You can use hugo to fetch JSON, YAML or CSV data from remote URLs and use those data as part of the build process. And if you use local data files instead of HTML you can use a tool like netlify-cms (github.com/netlify/netlify-cms) to give end users an easy way to work with that structured data without e…
Also worth mentioning is OSG [2], a sitemap generator written in go that I use in my bash script. It's very fast. This may have some advantages over hugos built in sitemap generator depending on your site, though I think I would use hugos in most cases. Might be useful for others using other static generators that don't support sitemaps and also have other CMS's and carts / forums installed too.
I use hugo on my personal blog at the moment. http://utkarshsinha.com/ A few things I've found interesting are: - Getting the layout just right takes a bit of tinkering (I mean the layout, theme and include file locations - not the CSS). - The `hugo` executable is just perfect. hugo server --watch is all you need (plus it's super fast!) - Also, I'm not a Ruby person. I don't need a whole Ruby ecosystem working on my…
- Grab the repo https://github.com/spf13/hugoThemes and flip through the themes. Personally, I don't keep the repository in my Hugo project, but just have a soft link to the base directory. Then, the command `hugo server --theme=MyThemeHere`, let's me instantly see what my website looks like under a new theme.
- The ruby gem s3_website (https://github.com/laurilehmijoki/s3_website) lets me update my Amazon hosted website instantly. Basically, I just run `rm -rf ./public && hugo && s3_website push` after adding a new page and I'm done.
- In any case, like liquidmetal, I'm not a Ruby person, but I was able to easily modify the themes into something that worked well for me. I started using Hugo after running through the other popular static site generators and found Hugo the easiest to get up and running and maintain.
Earlier quoted context omitted.
> You want to avoid dealing with Ruby, (...) It annoys me when using a tool require a functional development environment for the ecosystem it is based upon. E.g., ruby-based tools install via 'gem' and node-based tools install via 'npm', both of which are potentially huge hassles. A nice aspect of go-based tools is that you can always just download a binary.
It is awesome to be able to build a binary with go. But despite the recent Node major version upgrades, I've had almost no problems with npm, while I always seem to have issues with Ruby/gem installs. Binaries with no dependencies still win for convenience, but even Go has an ecosystem of libraries to deal with if you need to rebuild something. So I see the three on a spectrum: Go is always awesome, NodeJS usually wo…
If you need to build a version of master, or the project doesn't provide a static binary, or you don't wish to trust some random binary on the internet, or you wish to package a Go binary, it suddenly becomes terrible.
1. Build a version of master -- Go does not have a way to version or lock dependencies, so it's possible master will only build on the developers machine. The state of the art solution for that is vendoring, but each vendoring tool behaves slightly different, and even that results in some hell. It's not fun.
2. No static binary -- See 1, except now you're supposed to use 'go get' which is one of the most error-prone pieces of shit I've ever seen. It won't work with vendoring, so have fun.
3. Don't trust a random binary on the internet -- See 1 or 4
4. Package for a distro -- Good luck packaging go well. The informal ad-hoc dependency mess ensures that properly packaging go is almost impossible. The vendoring tools means you'll have hell modeling dependencies so you can react to security issues. Basically, your life will suck.
Ruby and NodeJS have none of those problems. To build a version of master, you have a gemfile / package.json that, if it follows specifications, will correctly tell you everything, down to the version, that should be installed.
Distros have tons of tools for packaging those languages and modeling them well. It works and is usually easy.
There's a single distribution method (npm / rubygems) so you don't have to check if there's a site with a curl | bash script, or a static binary download, or a github release page, or some other strange situation.
> NodeJS also has a larger pool of experienced developers
Citation needed. I have no qualm with the "larger pool" bit which very well could be true, but "experienced" and "NodeJS" don't go together so often in my book