5 ms·

Hexo – A fast, simple and powerful blog framework

65 points by juanfatas 13y ago

piranha 13y ago
Writing "incredibly fast" and not providing any clues of how fast is it is not exactly the best way to promote an application IMO. Update: okay, it generates simplest site possible with 250 posts in 7 seconds. This is not the worst performance (it's faster than Jekyll), but I won't call this 'incredibly fast'. :\ And why the downvote, by the way? Is pointing out statements, which may not hold any value, wrong? Especially if they do not hold any value?
- wting 13y ago
  I'm guessing you're getting downvotes because it's a trivial reply that doesn't add to the discussion. One could make the argument that Hexo is fast because it's: - fast to compile: probably faster or equal to industry standard Ruby/Jekyll - fast to install: npm - fast to deploy: single command for Heroku / GitHub Pages - fast to write: Markdown You're taking the one word "incredibly" and blowing it out of proportion. We're not talking about super computing here, fast is a relative construct.
  - piranha 13y ago
    > - fast to compile: probably faster or equal to industry standard Ruby/Jekyll Jekyll is slow enough to not count something faster than Jekyll 'incredibly fast'. It should be much faster than Jekyll to be at least 'fast'. For me, fast is that it can regenerate page while I'm switching from editor to browser. This one can not (7 seconds for almost nothing).
C1D 13y ago
It would be nice to see some benchmarks, comparing with WordPress and others blogging platforms.
- wting 13y ago
  There is no need for benchmarks, because presenting static files will always be faster than dynamic web apps like WordPress. Hexo (and Jekyll, Pelican, etc) pre-compile from Markdown to HTML which then gets served up as a static resource from the web server. On the other hand with Wordpress, the server has to compile the HTML every time a user visits.[0] For the server, HTML is just another static resource to transmit. You might as well ask to see benchmarks between displaying an image vs WordPress blog. [0] This can be mitigated with caching, but static resources are easier to cache and the caching logic is now handled by the app rather than CDNs.
deleted 13y ago
[deleted]
- hayksaakian 13y ago
  You have the power to remove them. There was a popular HN post recently advocating having no comments at all.
  - deleted 13y ago
    [deleted]
callmeed 13y ago
This looks like a nice, Node port of Jekyll. Not really how I prefer to blog. My idea for a blogging platform (maybe even a service), if I ever get to it, would be a combination of Jekyll and Posterous. In other words, you'd have: * A Jekyll dir structure on the server * You write a post via Email * The email is POSTed to the service via MailGun * The service writes a new HTML file in the Jekyll dir and runs `jekyll build` BAM, you have the speed of a static site, the wysiwyg editing features of whatever email client you use, and the ability to post from any computer/phone/tablet (not just one with git configured).
- jacques_chester 13y ago
  This is an example of what I call a POST-driven architecture; most designs are GET-driven. GET-driven means that you need GET events to prompt the system to generate new pages and possibly cache them. This has problems. The main one is that generating pages from scratch is costly compared to serving a flat file. So we turn to caching. But here arises a problem. GETs do not change content. So any system that relies on GETs as its source of activity will have inevitable mismatches between the cache and the content. This is where TTLs and LRUs and a whole bunch of other stuff comes into play. What if, instead, we used a POST-driven architecture? Instead of relying on stochastic noise to determine what to do, we could rely on changing stuff when we actually receive the instruction to change stuff. So instead of updating the cache on a certain number of GETs, or on a TTL or some other basis, we update the cache when a POST invalidates it. "Easy". If you avoid the naive scheme that early versions of Movable Type used (rebuilding a whole site upon each post), the whole thing goes a lot quicker. And you get to keep comments. In 2010 I did some preliminary research as part of an honours project proposal, but went with a different project. But it's still one of my pet peeves.
- don_draper 13y ago
  >>* The service writes a new HTML file in the Jekyll dir and runs `jekyll build` With Jekyll once it is up on say AWS you don't have to worry about it. You add a service in the mix, that means you need a server, that means you have an attack vector to worry about, among other things. People like Jekyll because it is so simple. Once you start adding services, it's no longer simple.
singular 13y ago
Seems interesting, I've always appreciated the simplicity of a Jekyll-type approach. Apologies for semi-hijacking to mention it but, I take a slightly different approach in my personal blog (custom, messy code) - I rsync markdown documents to my webserver which are compiled into HTML and put into a redis in-memory collection which the server uses to render the blog. That gives you in-memory caching for free and avoids having a whole bunch of static files having to be generated every time. I use node on the backend and angular on the frontend to allow for a single-page website. Currently the solution involves regenerating all HTML each time files are rsync by a script run remotely via SSH, however I ultimately intend for it to use an inotify-style approach to only import files that have actually changed, running both locally and remotely, so publishing an article need only require you to write some markdown and save it in a particular folder. Though of course all this (currently) requires you to have a server such as linode to which you can rsync + have a remote serving script watch a folder, I mention it so to ask whether anybody would be interested in me cleaning it up and open sourcing it?
- cnu 13y ago
  If you have compiled it to HTML, wouldn't it be more efficient to serve it up as static HTML files via nginx (or any web server). Why store the HTML in redis and serve off it via an application?
  - singular 13y ago
    With aggressive disk caching on servers static files are probably near enough in-memory anyhow (+ I'm sure you could configure a modern web server application to cache anyhow), so yeah it's probably pretty fast. However it's more limiting to simply serve static files - you're limited to what you've generated. With redis you can serve it as json data and use it dynamically for e.g. search or showing all articles with a given tag, in a given date range, etc. Additionally, I'm not a big fan of a whole bunch of static files sat in a folder somewhere that needs to be regenerated every time I change something. Personal preference, perhaps :-)
    - nilved 13y ago

65 points by juanfatas 13y ago

Writing "incredibly fast" and not providing any clues of how fast is it is not exactly the best way to promote an application IMO. Update: okay, it generates simplest site possible with 250 posts in 7 seconds. This is not the worst performance (it's faster than Jekyll), but I won't call this 'incredibly fast'. :\ And why the downvote, by the way? Is pointing out statements, which may not hold any value, wrong? Especially if they do not hold any value?

wting 13y ago
I'm guessing you're getting downvotes because it's a trivial reply that doesn't add to the discussion. One could make the argument that Hexo is fast because it's: - fast to compile: probably faster or equal to industry standard Ruby/Jekyll - fast to install: npm - fast to deploy: single command for Heroku / GitHub Pages - fast to write: Markdown You're taking the one word "incredibly" and blowing it out of proportion. We're not talking about super computing here, fast is a relative construct.
- piranha 13y ago
  > - fast to compile: probably faster or equal to industry standard Ruby/Jekyll Jekyll is slow enough to not count something faster than Jekyll 'incredibly fast'. It should be much faster than Jekyll to be at least 'fast'. For me, fast is that it can regenerate page while I'm switching from editor to browser. This one can not (7 seconds for almost nothing).

C1D 13y ago

It would be nice to see some benchmarks, comparing with WordPress and others blogging platforms.

wting 13y ago
There is no need for benchmarks, because presenting static files will always be faster than dynamic web apps like WordPress. Hexo (and Jekyll, Pelican, etc) pre-compile from Markdown to HTML which then gets served up as a static resource from the web server. On the other hand with Wordpress, the server has to compile the HTML every time a user visits.[0] For the server, HTML is just another static resource to transmit. You might as well ask to see benchmarks between displaying an image vs WordPress blog. [0] This can be mitigated with caching, but static resources are easier to cache and the caching logic is now handled by the app rather than CDNs.

deleted 13y ago

[deleted]

hayksaakian 13y ago
You have the power to remove them. There was a popular HN post recently advocating having no comments at all.
- deleted 13y ago
  [deleted]

callmeed 13y ago

This looks like a nice, Node port of Jekyll. Not really how I prefer to blog. My idea for a blogging platform (maybe even a service), if I ever get to it, would be a combination of Jekyll and Posterous. In other words, you'd have: * A Jekyll dir structure on the server * You write a post via Email * The email is POSTed to the service via MailGun * The service writes a new HTML file in the Jekyll dir and runs `jekyll build` BAM, you have the speed of a static site, the wysiwyg editing features of whatever email client you use, and the ability to post from any computer/phone/tablet (not just one with git configured).

jacques_chester 13y ago
This is an example of what I call a POST-driven architecture; most designs are GET-driven. GET-driven means that you need GET events to prompt the system to generate new pages and possibly cache them. This has problems. The main one is that generating pages from scratch is costly compared to serving a flat file. So we turn to caching. But here arises a problem. GETs do not change content. So any system that relies on GETs as its source of activity will have inevitable mismatches between the cache and the content. This is where TTLs and LRUs and a whole bunch of other stuff comes into play. What if, instead, we used a POST-driven architecture? Instead of relying on stochastic noise to determine what to do, we could rely on changing stuff when we actually receive the instruction to change stuff. So instead of updating the cache on a certain number of GETs, or on a TTL or some other basis, we update the cache when a POST invalidates it. "Easy". If you avoid the naive scheme that early versions of Movable Type used (rebuilding a whole site upon each post), the whole thing goes a lot quicker. And you get to keep comments. In 2010 I did some preliminary research as part of an honours project proposal, but went with a different project. But it's still one of my pet peeves.
don_draper 13y ago
>>* The service writes a new HTML file in the Jekyll dir and runs `jekyll build` With Jekyll once it is up on say AWS you don't have to worry about it. You add a service in the mix, that means you need a server, that means you have an attack vector to worry about, among other things. People like Jekyll because it is so simple. Once you start adding services, it's no longer simple.

singular 13y ago

Seems interesting, I've always appreciated the simplicity of a Jekyll-type approach. Apologies for semi-hijacking to mention it but, I take a slightly different approach in my personal blog (custom, messy code) - I rsync markdown documents to my webserver which are compiled into HTML and put into a redis in-memory collection which the server uses to render the blog. That gives you in-memory caching for free and avoids having a whole bunch of static files having to be generated every time. I use node on the backend and angular on the frontend to allow for a single-page website. Currently the solution involves regenerating all HTML each time files are rsync by a script run remotely via SSH, however I ultimately intend for it to use an inotify-style approach to only import files that have actually changed, running both locally and remotely, so publishing an article need only require you to write some markdown and save it in a particular folder. Though of course all this (currently) requires you to have a server such as linode to which you can rsync + have a remote serving script watch a folder, I mention it so to ask whether anybody would be interested in me cleaning it up and open sourcing it?

cnu 13y ago
If you have compiled it to HTML, wouldn't it be more efficient to serve it up as static HTML files via nginx (or any web server). Why store the HTML in redis and serve off it via an application?
- singular 13y ago
  With aggressive disk caching on servers static files are probably near enough in-memory anyhow (+ I'm sure you could configure a modern web server application to cache anyhow), so yeah it's probably pretty fast. However it's more limiting to simply serve static files - you're limited to what you've generated. With redis you can serve it as json data and use it dynamically for e.g. search or showing all articles with a given tag, in a given date range, etc. Additionally, I'm not a big fan of a whole bunch of static files sat in a folder somewhere that needs to be regenerated every time I change something. Personal preference, perhaps :-)
  - nilved 13y ago