

Show HN: Beautiful and Ridiculously Fast Websites With Static Blogging - calebhicks
http://store.statiq.io/what-is-statiq

======
calebhicks
A group of us got together and put this together.

We decided that Wordpress sucked for us. Then we stepped into static blogging
with Pelican. Then we realized that static blogging kinda sucks too. Setting
it up and the dearth of themes are rough.

Can you give us some feedback? We're still working on this together, and would
love to hear what you guys think.

~~~
underwater
Great idea and presentation. A few immediate questions: What are the limits of
what I can do with this? Can I add commenting, tags or search? How easy is it
to edit the pages (what syntax do I use)? And why do I need to provide a host?
Paying a little extra for included hosting seems a no brainer.

~~~
roberthahn
This is the kind of thing I think NearlyFreeSpeech.net[1] would be well suited
for.

They appear to have tuned their servers and business model for static web
sites - if they don't serve any of your files, you pay nothing. Otherwise, you
pay only for what you use.

Disclaimer: I've never used their services, but I've checked them out from
time to time.

[1]
[https://www.nearlyfreespeech.net/services/hosting](https://www.nearlyfreespeech.net/services/hosting)

------
gexla
I was looking for something like this the other day and found a mine-field of
services which seemed like they never went anywhere. Sometimes I would like to
be able to throw up a site where I can create content using something like
Editorially, have automatically backed up and not have to mess with everything
else involved in running a site and making sure content is backed up.

I was looking for something which could run Markdown files from Dropbox (and
pick the folder from which they are pulled.) I would also like to be able to
make posts (or even the entire site) private if needed (publishing workflow.)

------
joshbaptiste
[https://news.ycombinator.com/item?id=6787317](https://news.ycombinator.com/item?id=6787317)

~~~
jkhowland
Thanks for pointing this out. This was a post we pushed earlier, we weren't
quite ready to open the doors yet.

This post is a more comprehensive overview of what we're trying to do.

------
ricardobeat
That logo is taken [http://dcurt.is/](http://dcurt.is/)

~~~
bsamuels
I'm pretty sure that guy doesn't have a monopoly on using stylized
thunderbolts as a logo.

~~~
wmeredith
True, but his brand is already powerful and has established meanings and
connections in the same market with his blogging platform. It's not illegal or
anything, but why fight a mindshare battle you don't have to?

------
beambot
So... kinda like a cross between WooThemes and jekyll (or hyde)? Seems like a
pretty good idea -- especially for a large subset of business websites where
<favorite CMS> is overkill.

~~~
aharris88
Yeah, so it actually is using Jekyll right now for the engine, and we plan to
support Pelican in the future. You can just buy our themes if you want, or you
can use our engine to generate your posts in the cloud without all the setup.

~~~
etler
So is the target audience non technical people (or people who can't be
bothered)? Sounds like a good idea. I love jekyll, but I can't recommend it to
anyone not comfortable with HTML and CSS.

~~~
jkhowland
That's the exact same problem we had, and all of our potential clients had. We
want to make it easier to use, more accessible.

We talked to 3 types of customers. The non-technical were largely
disinterested. We're still too early for that. Agencies were _all over this_
for their clients though. Great feedback from them.

------
livestyle
Interested in your strategy for ecommerce sites. I wonder if foxycart
integration would make sense.

------
waps
I don't get this. As fast as static blogging is, in-memory applications:

1) will actually beat static files in speed

2) you lose none of the flexibility of databases. In fact, because your
effective query impact is going to be much smaller, you gain. Not in what can
theoretically be done, but in what can be done practically without impact on
response time, you gain a lot. Also expressivity gains (SQL is good, but it
doesn't match general programming languages) (e.g. drawing a graph of "this
person replies to this person and never replies to this other person" would be
feasible).

I suppose there's problems too:

3) you lose that your state is always on-disk. In other words : there's a
chance that you/your developer will get it wrong, but you won't notice it
until your process restarts, which can be months.

4) of course, you have to start monitoring memory usage in these kinds of
scenarios.

~~~
argonaut
... Serving up static HTML/CSS/JS will always be faster than having to render
on the server-side.

Now the tradeoff is that you can't have certain dynamic elements based on
state unless you use a third party service (i.e. comments). But that's
obvious.

~~~
waps
No it won't. There's lots of problems with doing that.

1) you need to -at least- check the disk for updates. On linux, you need to
update access time. This will take time. In memory has no such obligations.

2) you still need to compress the file in memory. You can cache the result of
the compression, but that won't buy you much. Specifically it'll be too large
to ... see point 3.

3) Because in practice pages are generated from very little data (the template
is -way- shorter than the filled in sent out text), the ability to work with
the data in little pieces without allocating large buffers in memory will
avoid trampling the cache, which is going to get you an insurmountable
advantage.

And this is ignoring the elephants in the room:

1) Because it's a static file, you'll have to send more data to the client
side in total to achieve the same result (e.g. look at how GWT does it, and
even there).

2) Because you still want to show customers "their" page, you'll need several
more roundtrips to achieve the same with javascript that you wouldn't need
with server pages (Note how one of the GWT pagespeed optimizations is to
dynamically generate the page initialization data using the webserver to avoid
an initial roundtrip).

3) Pure static files lose you a lot of features. Comments, scores, ... none of
that. That may or may not be acceptable.

~~~
boomlinde
1) You can have the kernel notify you upon a file system change via a watch
descriptor. It's not rocket science, and you don't have to do any polling.

2) It might not buy you much (I disagree), but is hardly a disadvantage over
any other approach where you'd want to send compressed http responses.

3) Let me get this straight; you're talking about the CPU data cache? It's not
going to be the bottleneck in a scenario where you are basically pumping data
into a socket. If it was, how would allocating a lot small buffers have an
advantage over a single large allocation, if the data was the same in the end?

As for elephants...

1) It depends on the expected result. A page built on static files doesn't
need to be static in any other sense.

2) I'm not sure why you think that dynamically generated "server pages" are
different from static ones in this case. The GWT pagespeed optimizations you
are talking about are not relevant to the discussion, since they are not
inherent to either static/dynamic backends.

3) As far as I'm concerned, this is the only valid point you have brought to
the discussion.

~~~
waps
1) and the atime updates (I am saying this because apache does make sure it
updates them, which runs them -at least- 1ms per file they serve, and yes they
accumulate these accesses, but they still cause limits and slowness) ? Caching
the file will, incidentally, make watch descriptors not work anymore for other
apps.

2) so it's identical. Meaning it's not an advantage of static files.

3) Actually the cpu data cache is going to be the bottleneck when you have
2x10G going into a single server (because you're using 92%+ of your data
bandwidth just pumping data into the network cards). Not writing (or reading)
to/from memory when you don't absolutely have to is what's going to make the
difference in speed. If you get to the point where you can expand templates
and compress them without hitting main memory (not that hard in chips with 16M
third level cache), it will make a huge difference.

And of course this is assuming it actually fits in physical memory. If
templates fit, but expanded they don't, templates win hands down (so expanding
per-user stats pages into static files, for example, is guaranteed to cost you
more than it buys you).

Elephants.

1) true, but it's going to cost you in roundtrips

2) yes they are. The optimization states that you optimize by having an
"initialize" call, to get all data you need to render the full user's page.
Then the dynamic backend calls that function, stores the result at the bottom
of the GWT serving page, and boom, you go from n roundtrips to 1. Since a
roundtrip is going to cost you at least 80-90 ms in any case except a local
LAN, this is one of those optimizations that if you don't have them, you can
forget about having your page displayed in less than 400-500ms.

Dynamic serving gets a bad rap because people are doing 10 mysql queries to a
database server (meaning a different physical machine) with explicitly
disabled caching and then complaining that actually takes time ... it's
ridiculous. Looking at some PHP code and the speed complaints on fora that
accompany it, it feels like putting your grandmother's dead grandmother behind
the wheel of a ferrari and complaining it doesn't move fast.

Having small programs generate data on cue is always going to be faster than
reading the actual data. I don't get why this isn't obvious to everyone. Hell,
it's how (and why) compression works.

~~~
boomlinde
1) You don't need to poll atime descriptors. Neither do you need to use watch
descriptors (although I don't understand your argument about them). You just
need a way to tell the server that you updated a page. It might have been a
good point if we were discussing specific implementations.

2) Are you saying that it was a completely irrelevant thing to mention in your
list of problems with generating static files to begin with? If so, I agree.

3) Whether you're right or wrong (I can't tell at this point, and I won't
simply decide on either until there are numbers to prove it), you are arguing
on the basis of very limited and somewhat unlikely scenarios. I could argue on
the basis of having very complex templates and page logic to generate
extremely small pages, but I don't since I realize that it's not very likely
to happen.

Elephants again...

1) No. If your use case is such that your static page contains the same
information what your dynamically generated equivalent would (and no one is
arguing for using static pages if this isn't possible), you don't need
additional round trips.

2) If all data you need to render to a page is static, you could easily go
from one roundtrip to none.

Let's bring another animal into the room:

With static files, you can enjoy the luxuries of very expressive languages
with slow runtimes to build your pages, without any performance impact on
serving them. Generating dynamic pages in a way that will even come close to
serving static files in terms of performance is going to mean spending more
effort than is viable for most projects.

