document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-03-24 02:20:09 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #5724 from ypingcn/master

Browse Source 
Translated:20170518 Hugo vs. Jekyll Comparing the leading static website generators.md
This commit is contained in:
Xingyu.Wang 2017-06-23 20:45:08 +08:00 committed by GitHub
commit 738c555d90
2 changed files with 91 additions and 103 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
sources/tech/20170518 Hugo vs. Jekyll Comparing the leading static website generators.md
View File

@ -1,103 +0,0 @@
translating by ypingcn
Hugo vs. Jekyll: Comparing the leading static website generators
============================================================
### If you're building a new website, a static site generator may be the right platform for you.
![Hugo vs. Jekyll: Comparing the leading static website generators ](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/rh_003784_02_os.comcareers_os_rh2x.png?itok=4wXjYMBw "Hugo vs. Jekyll: Comparing the leading static website generators ")
>Image by : opensource.com
Unless your spirit animal is Emily Dickinson, when you make a thing, you want to share it with the world. Sharing your work means that you need a website. Of course, you could simply partake in digital sharecropping and use any of the various social media sites to get your work in front of an audience. There sure are plenty to choose from... and not just "conventional" social media sites. With places like Artstation, Flickr, Soundcloud, and Wattpad, there's an outlet for you, whatever your medium.
And actually, you  _should_  use those sites. It's where the people are, after all. However, none of those places is truly yours. None is a home base that  _you_  control and that you can ensure will be there for people to find regardless of the waxing and waning trends of social media.
Programming and development
* [New Python content][1]
* [Our latest JavaScript articles][2]
* [Recent Perl posts][3]
* [Red Hat Developers Blog][4]
Control. That's the value of having your own place on the web.
But this article isn't about setting up a domain name and hosting for your website. It's for the step  _after_  that, the actual making of that site. The typical choice for a lot of people would be to use something like [WordPress][6]. It's a one-click install on most hosting providers, and there's a gigantic market of plugins and themes available to choose from, depending on the type of site you're trying to build. But not only is WordPress a bit overkill for most websites, it also gives you a dynamically generated site with a lot of moving parts. If you don't keep all of those pieces up to date, they can pose a significant security risk and your site could get hijacked.
The alternative would be to have a static website, with nothing dynamically generated on the server side. Just good old HTML and CSS (and perhaps a bit of Javascript for flair). The downside to that option has been that you've been relegated to coding the whole thing by hand yourself. It's doable, but you just want a place to share your work. You shouldn't have to know all the idiosyncrasies of low-level web design (and the monumental headache of cross-browser compatibility) to do that.
Enter static site generators. You get the speed and security of static HTML pages, but with a workflow that's closer to the convenience of a dynamic site. The two frontrunners in the static site generator world are [Hugo][7] and [Jekyll][8]. (By the way, Paolo Bonzini has a great article on [getting started with Jekyll][9].) But which one is the right choice for you? Hopefully by the end of this article, you'll have a better idea. We're evaluating both static site generators based on how quickly you can get started, availability of themes, editing workflow, and extensibility.
### Getting started
Fair warning, both of these tools will require you to work with them from the command line. Most of the commands are straightforward and easy to remember, but let's adjust our expectations accordingly. This is not a point-and-click interface.
Installation for both Jekyll and Hugo is pretty simple. Jekyll installs as a RubyGem, and Hugo offers a very handy all-in-one binary to get you started quickly. Because of the single install package, Hugo edges ahead here slightly. Although the RubyGems install method for Jekyll is easy in its own right, it  _does_  require that you already have a properly installed and configured Ruby environment on your computer. Outside of the community of designers and developers for the web, most folks don't already have that setup.
Once installed, though, both Hugo and Jekyll are pretty evenly matched. They both have great documentation and quick-start guides. You start a new site with a single command (in Jekyll, it's **jekyll new <your_site>** and in Hugo, **hugo new site <your_site>**). This sets up a general directory structure and scaffolding for your site. Directory structures and basic configuration are pretty similar. Jekyll uses a **_config.yml** file and Hugo uses **config.toml** (although you  _can_  use YAML or even JSON syntax with Hugo's config if you're more comfortable with either of those). The front matter metadata at the top of each content file uses the same syntax as the config. After that, all page content is written in Markdown.
I will say that in terms of getting you started with your very first statically generated site, Jekyll has a slight advantage over Hugo because it starts with some basic content and a default theme. You can use these as example templates as you start building your site. Hugo has no example content or even a default theme. That said, example content and default themes are usually the first things I delete when I'm making a new site with any tool, so Hugo actually saves me a step.
### Themes
As I mentioned, Hugo doesn't ship with a default theme at all, so that's probably one of the first things you're going to want to set up. Jekyll has a decent default theme, though it's pretty bare bones. You'll probably want to go theme hunting with your Jekyll site, too.
Both Hugo and Jekyll have a pretty diverse assortment of themes for all manners of website types from single-page ID themes to full-blown multipage sites with blog posts and comments. Despite that, it's not exactly easy to find a theme that suits your needs. In either case, the place to go for themes—[themes.gohugo.io][10] for Hugo and [jekyllthemes.org][11] for Jekyll—is basically a single large page full of theme screenshots. Once you click on a theme, you can get some pretty detailed information about it, but that initial search is pretty rough. Hugo's theme page has some basic tagging built into it, but in general, theme searching and presentation is something I feel both projects really need to work on.
Theme management is also an interesting topic. In both cases, nearly every theme is a Git repository (often hosted on GitHub) that you clone into your website scaffolding. In Jekyll, there's an additional step of using RubyGems' **bundle** to ensure that the theme is managed with the site. Most themes already come with a **Gemfile**, making this step relatively painless. If the theme doesn't already have a **Gemfile**, it's fairly easy to add. In Hugo there's no bundling step. Just point to the theme from your **config.toml,** and you're good to go.
I've found that I'm partial to the way that Hugo handles themes. You clone (or create) themes into their own space in a **themes** subdirectory. Not only does it make it relatively easy to switch between themes when you're first starting out, but it also gives you the ability to override any component file of a theme with your own file. This means you can customize a theme to your tastes without messing too much with the source of the original theme, allowing it to stay generic enough for other people to use. Of course, if you have a change that you feel other users of the theme may find worthwhile, you can still edit that source and submit a pull request to the theme maintainer.
### Workflow
The workflows for building your site in Jekyll and Hugo are pretty similar once you have your initial configuration set up. Both have a live **serve** command that runs a small, lightweight web server on your computer so you can test your site locally without needing to upload it anywhere. The really nice thing is that whether you're running **jekyll serve** or **hugo serve**, both are configured by default to watch for any changes you make to your site as you work on it. When you look at the locally served version of your site in a browser, it automatically updates with any change you make, regardless of whether that change is to content, configuration, theme, or just an image. It's really quite handy and a great time-saver.
You write the content for your site in both systems using [Markdown][12] syntax. If you don't happen to be familiar with Markdown, it's a very simplified means of writing in plain text while still allowing for some nice formatting marks. It's very easy to work in and human-readable. And because it's in plain text, your content (and therefore your site) is easily version controlled. It's pretty much the main way I write almost everything these days.
New content can be added to your site scaffolding by manually creating files in the right place. It just needs to be a Markdown file with the appropriate "front matter" metadata at the top of the file. As with the configuration file, Jekyll uses YAML syntax for front matter, while Hugo will accept TOML, YAML, or JSON (default is TOML). That new page file needs to be placed in the correct directory within your site's scaffolding. In Jekyll, you have separate **_drafts** and **_posts** directories for storing your work in progress and your completed content pages, respectively. In Hugo, there's only a single **content** directory. You specify whether a post is a draft or not within that content file's front matter.
Now, although it's possible to do all of this manually, Hugo does offer some convenience functions to ensure that your new file is created in the correct spot in the scaffolding and that files are pre-populated with appropriate front matter. It's simply a matter of going to your site's directory in a terminal and typing **hugo new content/<page.md>** where **<page.md>** is the new page you want to create. You can even set up templates called **archetypes** that hold customized front matter for pages of different types (like if you have both a blog and a podcast on your website).
When your site is ready to ship, you can shut down your preview server and issue a command to build the actual pages of the site. In Jekyll, that would be **jekyll build**. In Hugo, it's just **hugo**. Jekyll puts the completed site in the **_site** subdirectory, while Hugo puts them in a subdirectory named **public**. In either case, once you do that, you have a completed static website that you can upload and have hosted nearly anywhere.
### Extensibility
Both Hugo and Jekyll give you the ability to customize your site down to the smallest thing. However, in terms of extensibility, Jekyll currently leads in a big way because of its plugin API. Because of this plugin architecture, it's relatively easy to add functionality to your Jekyll-generated site with reasonably short snippets of code available through the Jekyll community or that you write yourself.
Hugo does not currently have a plugin API at all, so adding that kind of functionality is a bit tougher. There's hope that the ability to write and include plugins will be added in the future, but it doesn't appear that anyone is working on that yet.
### Conclusion
By and large, Hugo and Jekyll are pretty similar. It really comes down to determining how you're most comfortable working and what your site needs. If you already have a RubyGems environment set up and you need the extensibility of plugins, then Jekyll is the way to go. However, if you value a simple workflow and a straightforward means of customizing your site, then Hugo would be your top pick.
I find that I'm more drawn to Hugo's approach, and in building a small handful of sites, I haven't yet had a need for any plugins. Of course, everyone's needs are a little bit different. Which static site generator would you choose for your site?
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/5/hugo-vs-jekyll
作者：[Jason van Gumster ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/jason-van-gumster
[1]:https://opensource.com/tags/python?src=programming_resource_menu
[2]:https://opensource.com/tags/javascript?src=programming_resource_menu
[3]:https://opensource.com/tags/perl?src=programming_resource_menu
[4]:https://developers.redhat.com/?intcmp=7016000000127cYAAQ&src=programming_resource_menu
[5]:https://opensource.com/article/17/5/hugo-vs-jekyll?rate=lZDKuqOQ7lVUon-ZKebR5SUCyXDz5oCQ_zoCSBPolOQ
[6]:http://wordpress.org/
[7]:http://gohugo.io/
[8]:https://jekyllrb.com/
[9]:https://opensource.com/article/17/4/getting-started-jekyll
[10]:https://themes.gohugo.io/
[11]:http://jekyllthemes.org/
[12]:https://daringfireball.net/projects/markdown/
[13]:https://opensource.com/user/26430/feed
[14]:https://opensource.com/article/17/5/hugo-vs-jekyll#comments
[15]:https://opensource.com/users/jason-van-gumster

91
translated/tech/20170518 Hugo vs. Jekyll Comparing the leading static website generators.md Normal file
View File

@ -0,0 +1,91 @@
Hugo vs. Jekyll ：两大领先的静态页面生成器之间的比较
============================================================
### 如果你正在建一个新网页，一个静态页面生成器或许是个正确的选择。
![Hugo vs. Jekyll: Comparing the leading static website generators ](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/rh_003784_02_os.comcareers_os_rh2x.png?itok=4wXjYMBw "Hugo vs. Jekyll: Comparing the leading static website generators ")
>图片提供 : opensource.com
除非你是像狄更生那样深居简出的人，当做了点事情后，你就会想要与这个世界分享。分享你的作品意味着需要一个网页。当然，你可以简单地参与数字时代的收益分成（digital sharecropping），使用任何不同的社交网站来将你的作品呈现在观众面前。还有很多选项可以选择，不仅仅是传统的社交网站。例如 Artstation、Flickr、Soundcloud、Wattpad，不管你的媒介是什么，总有属于你的网站。
实际上，你_应该_使用这些网站，毕竟，人们都在这些网站上。然而，没有一个地方是真正属于你的。没有一个网站是你能保证不管社交趋势如何，人们都能在该网站上找到你的作品的。
控制权，是拥有一个在网上属于自己的地方的价值。
但是这篇文章不打算介绍注册域名和托管你的网站。要介绍的是_后续_的步骤，真正地制作网页。对于很多人来说，典型的选择是使用像 [WordPress][6] 那一类的软件。在大多数域名托管商上，只需一次点击即可安装，然后就会有海量的插件和主题可供选择。插件和主题的选择取决于你想要制作的网页的类型。但是WordPress不仅对于大部分网页来说有点过犹不及，还给了你一个有许多活动部件的动态页面。如果你没有保证这些部件是最新的，这些部件可以造成重大安全隐患，你的页面因此被劫持。
替代方法是拥有一个静态网页，在服务端没有任何动态内容生成。原先的 HTML 和 CSS （或许还有点 Javascript 也挺好）。这选项不好的一面是以后你要亲自动手编写所有的代码。这是可行的，但你只是想要个地方来展示你的作品。你没必要知道底层网页设计的特性（和重要的但却令人头疼的跨浏览器兼容性）。
使用静态页面生成器。你得到了静态 HTML 页面的速度与安全，但是是以有着接近于动态页面的便利性的工作流程完成的。在静态页面生成器世界的两大先驱是 [Hugo][7] 和 [Jekyll][8] ，（顺道说下，Paolo Bonzini 的文章 《[getting started with Jekyll][9]》 写得不错）但是哪一个才是你的正确选择？希望阅读完这篇文章，你将会有个更好的想法。我们将基于易上手性、主题可用性、编辑方式和拓展性这几点评估这两个静态页面生成器。
### 开始
公平地提醒一下，这两个都需要你在命令行下使用他们。大部分命令都很直接和易于记忆，但是让我们相应地调整下我们的期望吧，这不是点击几下鼠标就能做事的界面。
Jekyll 和 Hugo 的安装都相当的简单。 Jekyll 以 RubyGem 的方式安装，Hugo 提供了一个方便的多用途二进制文件让你迅速上手。因为简单的安装包，Hugo 微弱领先。虽然 Jekyll 的 RubyGems 安装方式本身就很简单，但是它_确实_需要你已经在你的电脑上正确安装并且配置好 Ruby 环境。除了社区设计者和网页开发者，大部分的使用者并没有提前安装好。
虽说是这样，但是一旦安装好，Hugo 和 Jekyll 都很好用。它们都有良好的文档和快速开始文档。你用一个简单命令新建一个页面（在 Jekyll 里是 ** jekyll new <your_site> ** ，在 Hugo 里是 ** hugo new site <your_site> ** 译者注：<your_site> 指代你网页的名称）。这一步新建了一个通用目录结构和你网站的大致内容。目录结构和基本的配置都十分相似。Jekyll 使用一个**_config.yml** 文件，Hugo 使用**config.toml**（虽然你_能_在 Hugo 的配置里使用 YMAL 或者 JSON 语法，如果觉得其中一个使用起来更舒服的话）。每个内容文件的前置配置（front matter）元数据使用相同的配置语法。然后，所有的内容都是用 Markdown 写的。
我想说就帮助你开始第一个静态网页这一点来说，Jekyll 稍微领先于 Hugo ，因为它能以一些基本的内容和一个默认主题开始着手使用。当在建设网页时，你能使用这些内容作为一个样板。Hugo 没有样例内容，甚至没有一个默认主题。这就是说，样例内容和默认主题是我在用任何工具建设网站时第一个删除的内容，因此Hugo 事实上帮我节省了这一步。
### 主题
正如我所提到的，Hugo 根本没有默认主题，所以主题可能是你打算最先设置的。Jekyll 有一个得体的默认主题，虽然它只是个骨架。你或许也会想去为你的 Jekyll 页面找一个主题。
Hugo 和 Jekyll 都有多种多样的各类主题，网页样式从单页面的主题到带博客发布评论的完善多页面主题都有，一应俱全。尽管如此，想找到满足你需求的主题事实上并不简单。无论使用哪个，主题网站——Hugo 的 [themes.gohugo.io][10] 和 Jekyll 的 [jekyllthemes.org][11] ，基本上都是一个充满主题截图的巨大网站。一旦你点击主题，你能得到关于主题的一些十分详细的信息，但是初始搜索相当困难。Hugo 的主题站有一些基本的标签分类，但是大体上在我看来，主题搜索和展示都是这两个项目需要继续努力的。
主题管理也是一个有趣的主题。在两个项目中，几乎每一个主题是一个 Git 仓库（经常是托管在 Github 上），你需要克隆（clone）下来到你的网页建设地。在 Jekyll 里，有使用 RubyGems 的**bundle** 的额外一步来确保主题是由网站管理的。大部分主题都有一个 **Gemfile**，使得这一步骤轻松不少。如果主题没有一个**Gemfile**，添加也相当简单。在 Hugo 里没有捆绑这一操作，只要在**config.toml** 指向你的主题即可。
我发现我偏爱 Hugo 的主题处理。你克隆（clone）（或者新建）主题到它们自己的**themes** 子文件夹里。这不仅使得当你开始时能轻松地切换主题，而且也能让你用自己的文件重写主题里的任何组件。这意味着你能根据自己的品味自定义主题，不用混合太多的原始主题，使得这主题对于其他人也是通用的。当然如果有一个你觉得其他用户会觉得值得的改变，你仍然可以编辑源文件，提交一个PR（ pull request） 给主题维护者。
### 工作流程
一旦你设置好初始的配置，Jekyll 和 Hugo 的网站建设流程都很相似。两者都有一个实时的 **serve** 命令，能在你的电脑上运行一个小型、轻量网页服务器，所以你能在在本地测试你的网站而不用上传到哪里。很棒的是无论你是运行着**jekyll serve** 还是**hugo serve**，都默认配置为当你工作时，监视任何你对网站的所有修改。当你在浏览器里看本地版的网站时，它会根据你的修改自动更新，不管你改的是内容、配置、主题、还仅仅是一张图片。这确实很方便和节约时间。
在两个系统中都是用 [Markdown][12] 写你的网站内容。如果碰巧你不熟悉 Markdown，（我来解释下）它是种很简单的纯文本编写方式，还能有一些很好用的格式化符号。它很容易使用而且可阅读。而且因为是纯文本，你的内容（其实是你的网站）很容易控制版本。这是我最近写几乎所有东西的主要方式。
新内容能通过在正确的地方手动创建文件添加到网站里。新文件只需要是有恰当前置配置（front matter）元数据的Markdown 文件即可。至于配置文件，Jekyll对于前置配置使用 YAML 语法，Hugo 接受 TOML、YAML或者JSON（默认是TOML）。新文件需要放置在正确的文件夹内。在 Jekyll 里你需要把你编写中的文件和完成了的内容页分别放在 **_drafts** 和 **_posts** 目录中。在 Hugo 中只有单独一个 **content** 目录。你根据文件的前置配置判断这是否是一个草稿。
现在，虽然可以手动完成所有这些事情，但是 Hugo 提供了一些方便的函数确保你的新文件创建在正确的文件里，那些文件也用恰当的前置配置预先配置好了。
简单地在终端中进入你网站的目录，输入 **hugo new content/<page.md>** ， **<page.md>** 代表着你想新建的新页面。你甚至设置些包含为不同页面自定义的前置配置、叫** 原型 **的模版（例如在你的网页上同时有博客和播客）。
当你的网页弄好后，你能关闭你的预览服务器和用一个命令来建立你网站的真正页面。在 Jekyll 里是**jekyll build**，Hugo 就仅仅是 **hugo**，Jekyll 把完成好的页面放在 **_site** 的子目录中。然而 Hugo 把这些文件放在名为 **public** 的子目录中。不管哪种情况，一旦你这样做了，你就有一个完整的静态网站，你能上传并把它托管在几乎任何地方。
### 可拓展性
Hugo 和 Jekyll 都能让你自定义你自己的网站上甚至最小的一个点。然而就可拓展性而言，现在 Jekyll 远远领先因其插件 API。因为这种插件结构，很容易为你 Jekyll 生成的网站添加功能，通过Jekyll 社区或者你自己写的相当短的代码片段就能完成。
Hugo 现在根本没有插件 API，所以添加功能有点难。希望以后支持编写并包含插件。但是现在看不出有人在做这一点。
### 结论
大体上讲，Hugo 和 Jekyll 十分相似。归根结底由你工作体验和你的网站需求决定。如果你已经设置好了 RubyGems 环境而且你需要插件的可拓展性，Jekyll 是你的选择。然而，如果你看重一个简单的工作流程，一个直接自定义网站的方式，那你首选 Hugo。
我发现我更喜欢 Hugo 的方法，而且在建一个小型网站，我不需要任何插件。当然，每个人的需求都不同。你会为你的网站选择哪一个静态页面生成器？
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/5/hugo-vs-jekyll
作者：[Jason van Gumster ][a]
译者：[译者ID](https://ypingcn.github.io/wiki/lctt)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/jason-van-gumster
[1]: https://opensource.com/tags/python?src=programming_resource_menu
[2]: https://opensource.com/tags/javascript?src=programming_resource_menu
[3]: https://opensource.com/tags/perl?src=programming_resource_menu
[4]: https://developers.redhat.com/?intcmp=7016000000127cYAAQ&amp;amp;amp;amp;src=programming_resource_menu
[5]: https://opensource.com/article/17/5/hugo-vs-jekyll?rate=lZDKuqOQ7lVUon-ZKebR5SUCyXDz5oCQ_zoCSBPolOQ
[6]: http://wordpress.org/
[7]: http://gohugo.io/
[8]: https://jekyllrb.com/
[9]: https://opensource.com/article/17/4/getting-started-jekyll
[10]: https://themes.gohugo.io/
[11]: http://jekyllthemes.org/
[12]: https://daringfireball.net/projects/markdown/
[13]: https://opensource.com/user/26430/feed
[14]: https://opensource.com/article/17/5/hugo-vs-jekyll#comments
[15]: https://opensource.com/users/jason-van-gumster