I'd like to second Hugo. Static sites with Netlify are a joy, since they can handle however much traffic you want, there are no scaling headaches or updates or stuff for bots to randomly hack.

I'm currently trying to decide between Lektor and Hugo, Lektor's data model seems more powerful, Hugo seems harder to learn (worse-quality docs) but Lektor doesn't seem very actively maintained, and Hugo has a larger community around it.

Co-founder of https://forestry.io here.

As an interesting speed comparison, one of our users has a site with 2,000 blog posts that takes Jekyll 10 mins to build. We migrated it to Hugo and the build time went down to 900 ms.

We're big fans of Jekyll, but Hugo certainly beats it when it comes to speed.

That's awesome. I'll have to check this out. I wonder what type of speed improvements one could get rewriting this with crystal-lang (https://crystal-lang.org).

I'm also trying to decide between Hugo and Lektor (Note: I'm having some flask experience). At first view Hugo seemed superior but I looked at some important specifics for me like e.g. thumbnail generation, Plugin System (important for developers) or CMS like editing. All this stuff is not available in Hugo core but it's already built into Lektor. It seems the biggest weakness of Hugo is that it is statically built and not easy to extend (only easier to deploy). If you build your own Makefile/gulp etc. around it it may also work for you but Lektor is more flexible when looking at this. From a developers perspective Lektor seems more customizable... unless you are a die hard Go developer. I think Lektor community can outgrow Hugo's one because of the plugin system. Building a toolset around a binary to extend a page generator does not seem the right way @hugo team. But at the end it all depends on your requirements. Hugo is much much easier to deploy and many people do not want to extend their page generator.

I agree, but someone on the Hugo forums pointed me to this issue:

https://github.com/lektor/lektor/issues/180

The fact that it's such an egregious issue (85 minutes for 2000 posts?!) that has been open for 9 months doesn't give me much hope in the development speed of Lektor. This also matches my experience, as I see trivial issues and PRs open for months in Lektor's repo...

The Lektor dev (it wasn't Armin) told me on Gitter that development has stalled a bit, but will hopefully pick up in 2017. I certainly hope so, becaue it's a well-designed site generator.

maybe when community and development speed and extensibility are the main requirements it all leads back to Jekyll :/ if I would be a ruby guy it would be definitely my first choice. Hugo is the speedy gonzales with easy deployment but lacks good extensibility when you want to go into the code level :(

I think you're right... Bah, just when I was convinced by Hugo, you convinced me to use Lektor again :P

sorry :D it really depends on your requirements. If Hugo in its current state covers you or if you can live with a light toolchain around Hugo go Hugo (I think many people do not need to touch the go code). There is nobody saying that you cannot write a little python code which is run before/after hugo (actually some people are doing that!). But if you want total control/extensibility with your python code in the page generator the Lektor plugin system will give you more power.

I decided to go with Lektor in the end, since it's much easier to work with and good enough for my purposes for now. Plus, since I'm a Python dev, I can extend it much more easily.

I am bep, the lead maintainer of Hugo. A plugin system will happen in Hugo, and I don't think it will take too long to get there -- we have been thinking about it for some time, and it feels natural to have that before we call it 1.0. CMS like editing is something that could live well outside of Hugo, me thinks.

Thanks bep. I'm really looking forward to that. With a plugin system the Hugo community will also grow IMHO. Looking forward to it. I agree that CMS like editing should not necessarily be inside of Hugo.

Oh that's exciting. Will be a great addition to a really good system.

Looking forward to it!

Yeah, the lack of thumbnail generation is an issue. It's definitely something which should be built in.

Agree.

bep (Hugo maintainer)

I looked into snipcart however the admin was slow, and the pricing was much more expensive then Shopify when at scale (revenues in the millions).

Over the holidays I spent the time to write a Sinatra based replacement for the Shopify Checkout. There is a big opportunity for someone to do with ecommerce what Discorse did for forum software.

Wouldn't revenues in the millions justify in not having Shopify but some custom integration with whatever payment processor you are using?

Yup, it's absolutely getting to that point, but not for $$$ reasons. Shopify Plus, their enterprise plan is fixed price. This is why I spent much of the holidays writing our own custom cart.

When was the last time you tried Snipcart? We (Snipcart team) noticed a few hiccups with dashboard perf and made some improvements a short while back. If you give it another go for another project, don’t hesitate to let tell us if you think it’s still lacking. Also, we do monthly fixed fees for merchants with >20K/monthly sales.

Working on that since 2015 ... written in Go. Lots of work to do.

Slightly offtopic: I'm very interested in trying Snipcart, again. Back when we had to decide between Snipcart and Shopify's SDK for a static site, Snipcart's lack of product management was a dealbreaker.

Shopify's administration interface, in contrast, is fantastic. However there are some issues which Shopify doesn't intend to fix at all, like their handling of EU vat calculation or the fact that refunds aren't enough to get Shopify's transaction fee back (like it is the case for Paypal, Stripe and others) - with Shopify you have to cancel the order, which in my opinion, is a misleading order status. A refunded/exchanged order is not a canceled order.

While products and variants are still defined on-site (unless you’re using a CMS plugin), we—Snipcart—did ship out-of-the-box inventory management in the dashboard a few months ago. Keep us in the loop about that feature next time you try out the product. Feedback always goes a long way for us!

I know. I actually talked to you guys and you were quite helpful. Unfortunately the product management wasn't ready back then. And, frankly, inventory management alone isn't enough in our case. Our shop system is used by non-tech savvy people and they still need to be able to create products, variants, etc. in a user friendly way.

Shopify's biggest issue is the fact that you can't edit the line items for an order, or the billing information. This is a monumental flaw, which has been round since day 1.

To get round this Shopify's sale people recommend hacks like 3rd party app that delete the original order and create a new order. This actually has a whole heap of unintended consequences. I'd say this is the biggest reason for us looking for an alternative.

The best ecommerce backend I've seen is Neto.com.au however their performance (front end site latency) is shockingly terrible.

Well, thanks to you I'm now a netlify/jekyll user.

Appreciate the recommendation, really (I’m one of the devs at Snipcart). We’re actually going to publish a piece on how static & JAMstack set ups affect clients in modern projects real soon—we have a strong dev shop/agency background so that aspect’s always been interesting to us. Would love to hear your thoughts on it so we’ll try to share on HN too; we’ll be focusing a lot on both “static” CMS & headless/API-first CMS like Prismic & Contentful. Have you tried these BTW, or do you find them overkill for small-scale projects?

I like the idea of services like Prismic and Contentful, but yes I find them overkill for smaller projects.

For larger ones I'd be worried about being tied too closely to a company which may or may not be around in a few years - I'd probably look to open source project instead.

For example Drupal has good user and content management features, and with D8 there's more interest in 'headless' Drupal, where it becomes an API backend to custom front-ends.

Another note is that there are very few good (or cheap) solutions for selling digital downloads in Europe due to the VAT regs. Gumroad is the main one, followed by Etsy - though it's a very different beast.

Any other suggestions would be welcome...

Sadly, two years on now, EU VAT is still utterly crazy. It's like they don't even realise how much of a burden that system is for small businesses selling online. :-(

The businesses I have that have to deal with it all use some sort of custom integration, because we never found any service that could do what we needed and didn't involve some unacceptable level of risk (like our entire business becoming unable to operate if the service went under suddenly, for example).

Even with a lot of automation and a system designed for exactly what we do, complying with the EU VAT rules still takes an absurd proportion of the time we spend on administrative overheads.

Selz has good support for European tax regulations. Besides that the admin interface is pretty good.

Another good solution is the Shopify Buy Button combined with SendOwl for digital goods delivery.