i use the engine for some commercial work at the moment, i might open-source it eventually as well (if there is enough interest in it). but at the moment it's just a bunch of make-shift scripts thrown together which are not really in a publisheable shape
Yeah, that's nasty. It's a blog post, it's about as close to static content as you can get. It's not even listed in the pros and cons that this is a perceivable issue, which you can see once you allow the swathes of JavaScript to download and execute.
lol at the irony of my comment, I honestly had no idea.
I personally wouldn't use this for my blog because in my opinion a blog shouldn't require Javascript to display content, but I know I'm in the minority there and it's important that people try different things and push the boundaries. Thank you for sharing this OP!
I strongly agree. It's fine if you want to use javascript to augment appearance and behavior, but if a blog post won't load something basically readable in lynx or w3m or similar, you've taken a wrong turn somewhere.
that's like saying that "if you can't print it on punch cards it's all bad". the progress didn't stop with lynx. probably good 90% of the modern internet won't work without javascript
> The overwhelming majority of users have javascript enabled.
I find that it's often developers who don't, making it a questionable tradeoff (in my mind) for a blog written by one. For this very reason I choose to use absolutely no JavaScript on mine. (Correction: Oops, Gists are included via JavaScript — I'll be replacing them with code blocks ASAP.)
I had some of the same annoyances as the OP, and chose Jekyll + GitHub Pages instead (http://nkantar.com/choosing-jekyll/). I found that optimizing for my workflow (write Markdown, commit, push) was more worthwhile than having absolutely zero generation tools (which I don't even need if I simply create a new file on GitHub, as a neat bonus I've used at least once so far).
I wrote my own blogging engine [1] back when there weren't many (any?) to choose from (started it in 1999), and geared the workflow of posting to my preferred method: email (although it helps that I run my own server) and I'm surprised that method isn't used more often.
I can also use a web interface if I am desperate, as well as adding an entry as a file (the email interface is similar to the file mechanism---it just pulls the entry out of the body of the email).
Granted, the language I used is rather unorthodox, but it works.
I found Jekyll really really hard to get up and running despite the documentation promising it would be easy. (This is a running theme: https://news.ycombinator.com/item?id=9920740) So I wrote this blog post to explain lots of the aspects that confused me and some others besides targeted towards somebody who is not intimately familiar with all the things involved: http://softholmsyndrome.com/2015/04/16/using-jekyll-taming-h...
EDIT (Thu Jul 23 21:33:12 PDT 2015): The formatting on that post seems to be borked a bit, I'm working on it.
I've been asked by some very mildly technical designers to write up how to use Jekyll (especially with GitHub Pages), so until I get around to doing that, I'm gonna' send them to your post as a "here's basically what you might have to look forward to".
That said, I had no real issues setting it up on OS X and Debian/Ubuntu, but then I was at least somewhat familiar with how all the parts are supposed to work.
Thanks, I'm not entirely satisfied with the quality of that post so knowing people will actually read it is a serious motivator to make it better, which I'm doing right now.
i used jekyll as well, and it's alright. this thing gives you the same workflow minus dependency on ruby runtime or a specific hosting platform that supports jekyll (like github for example).
I suppose I chose dependency on Ruby over dependency on client-side JS, though they're not mutually exclusive anyway.
It's a neat concept, for sure, and incredibly similar to something I once wanted to implement for photo galleries (and might still, since this actually seems to work quite well).
If you have a loading spinner and your site already loads in <500ms, just get rid of the spinner. Your brain filters out short transitions anyway, so all a loading spinner does with such a brief time span is distract the user from whatever they were thinking about.
because that's an extra moving part, i will have to handle those compiled files separately, collect them somewhere, copy to S3 or whatevers. I don't want that. I want a simple thing that has just the content and a shallow presentation layer that just shows the content in a browser, that's it. No extra transformations or anything, this way the system is immediate and simple. markdown + front-end, no other moving parts
Hm, really? When I click on those links they all show me that they didn't find anything. Ok I see that google did find what I was looking for, I wasn't expecting that. But none of the other search engine did for me. I only got: "No more results.", "По вашему запросу ничего не нашлось", "No results found for site:http://nikolay.rocks How I Blog Now." and "We did not find results for: site:http://nikolay.rocks How I Blog Now."
But that doesn't seem like a nice thing to read, I mean it is better than nothing, but to do that you wouldn't need your own domain and all the JavaScript.
