About the "speed text" about hugo-docs-concept HOT 17 CLOSED

On an added note:

I guess that the Jekyll creator didn't think too hard about speed. "It is static, and I deploy by a script in the background, so it doesn't matter if it takes 10 or 60 seconds." Which is kind of true; but the big win in Hugo's case is if you combine the speed with the Live-Reload feature (and also with the Netflify preview feature).

from hugo-docs-concept.

I don't think we should add more, so it would come at the expense of something else. Livereload isn't hard to accomplish outside of Hugo (I use Browser-sync nearly as much as Hugo's built-in).

from hugo-docs-concept.

Agree, the one-liner above is fine.

from hugo-docs-concept.

@bep You know the Smashing Magazine Hugo launch. That site has over 7,000 pages. Build time is <2 min (though that's on a tweaked, and expensive server).

from hugo-docs-concept.

@bep would love it if you could weigh in on this homepage design issue when you have an opportunity. #3

from hugo-docs-concept.

I agree the copy needs to change (we have a slightly different version in this discussion on the homepage design).

Here's a VERY rough start on a replacement, based on these assumptions:

1. Go's concurrency deserves some of the credit.
2. Whether or not one can do this in Ruby, etc. no one has accomplished what Hugo has so far, and Hugo's speed is a very important factor for those who choose it.

"Hugo is built for efficiency and Golang's concurrency makes it the fastest tool of its kind. At less than .7 ms per page, the average site builds in less than a second."

from hugo-docs-concept.

Thanks, @bep

I think you're giving Go too much credit, or, you're giving Go all the credit. It's like saying that it isn't possible to create a fast static site generator in Ruby or Python, which is bullshit.

It's certainly not intended as a knock on the incredible development work that has helped make Hugo so darn zippy but is more, at least in a marketing sense, leveraging Golang's (I believe) well-known concurrency model and using it as supplemental support for the blistering speed of Hugo. But you're right that we already say it's the fastest, so we can pull the second half of the first sentence. We should mention "no runtime dependencies" because it's a nice feature:

Jettison expensive runtime dependencies. For the first time, measure build times in micro- and milliseconds.

For reference, from "Why I Built Hugo":

I wanted to develop a fast and full-featured website framework without any dependencies. The Go language seemed to have all the features I needed. I began developing Hugo in Go and fell in love with the language. I hope you will enjoy using Hugo (and contributing to it) as much as I have writing it.

And also from the usage page:

Because Hugo is so blazingly fast both in website creation and in web serving (thanks to its concurrent, multi-threaded design and Golang heritage), some users prefer to use Hugo itself to serve their website on their production server.

This brings up another question for the team, but that will be in another thread.

from hugo-docs-concept.

Go's concurrency model is powerful because it is easy to use, not because it is faster than any other -- harder to use -- concurrency model. But that is beside the point, my main point was to "split the credit" somehow.

I have been coding fast and hard on the "multi output" feature lately, and have not thought too hard about performance doing it. Yesterday I did some benchmarks that showed a fairly significant slowdown. Which I will fix, but my point being: Go will not save sloppy programmers.

from hugo-docs-concept.

Here's something noncommittal, but perhaps a safe choice and gets to the heart of the matter. If this is ever not a true statement, the copy can be changed:

"Hugo is the fastest tool of its kind. At less than .7 ms per page, the average site builds in less than a second."

from hugo-docs-concept.

@bep
How about the following, slightly tweaked from my revision above?

Jettison expensive runtime dependencies and let Hugo build your site in micro- and milliseconds.

Jettison expensive runtime dependencies and let Hugo build your site in micro- and milliseconds.

Or even...

Forget expensive runtime dependencies and let Hugo build your site in micro- and milliseconds.

I'm thinking about less common words like "jettison" for audiences who speak English as a second language, at least until the docs can be internationalized based on our GA data. Thoughts?

As I mentioned, we already talk enough about Go, and the three above options now point to Hugo as fast rather than just Golang. Or do you think the above three options implies too much "magic" on the part of Hugo; i.e., in reference to your previous comment about the project not necessarily saving sloppy programmers?

The homepage content is of course very important, but my time has really been focused on heavier revision in the docs themselves. I only mention this because I don't want us to get engulfed in copywriting details when there are much bigger content-related questions to be discussed.

from hugo-docs-concept.

My take:

Hugo is the fastest tool of its kind. At less than 1 ms per page, the average site builds in less than a second.

The "jettison" and "expensive runtime dependencies" sounds very foreign to my Norwegian ears.

from hugo-docs-concept.

bingo. thank you

from hugo-docs-concept.

The "jettison" and "expensive runtime dependencies" sounds very foreign to my Norwegian ears.

@budparr 's works for me 😄 NB, "polyglot"

from hugo-docs-concept.

Sure @budparr what do you think about a new block for something sorta developer-friendliness related (ie, Bjorn's point re: LiveReload) in the homepage?

from hugo-docs-concept.

And, I remember a year ago or so, a guy was doing a proof of concept for a big US site with 500 thousand pages. Which is unthinkable with Jekyll and the others. But it it may be within reach for Hugo.

from hugo-docs-concept.

But Hugo's live-reload is better than both Gulp and Grunt's variant.

I guess Smashing Magazine has some "expensive templates", which is an area with some obvious room for improvements in Hugo.

from hugo-docs-concept.

I should also add that that includes the entire asset pipeline, which accounts for a small percentage, but there's an awful lot there aside from the standard site. Nonetheless, a nice use-case, because that site wouldn't be possible in Jekyll, etc.

from hugo-docs-concept.