Open-sourcing my new blogging engine implementation

[tlarkworthy]

It seems the development tool that builds and obfuscates the application is not available, which makes it a dubious classification of open source.

[MadRabbit]

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

[click170]

It seems to require Javascript to load the content. Is there information about this elsewhere that doesn't require Javascript to view?

[steckerbrett]

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.

[detaro]

It builds the page using javascript from a copy of this file: https://github.com/MadRabbit/nikolay.rocks/blob/master/pages...

[MadRabbit]

all the content is open-sourced and available on github as markdown all nice and readable without any engine at all! https://github.com/MadRabbit/nikolay.rocks/blob/master/pages...

[nkantar]

> 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).

[spc476]

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.

[1] https://github.com/spc476/mod_blog

[unimpressive]

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.

[MadRabbit]

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 just write stuff and git push it to heroku

[djokkataja]

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.

[NKCSS]

Then why not add a delay to showing the spinner? that way, if it ever takes longer than, say, your 500ms, you'll have an indicator...

[MadRabbit]

fair point. thanks!

[elmin]

Why not use gulp to build static html pages, and serve those with S3/CloudFront. Simpler, more reliable, and no need to run a node service.

[MadRabbit]

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

[neoCrimeLabs]

All I see is a blank page with a spinner. Using elinks all I see is "Loading..." When I look at the source code there is no content!

Not very search engine friendly.

[MadRabbit]

all search engines are javascript enabled those days. google indexes nikolay.rocks perfectly. i have analytics running and everything on it

[csense]

Nikola, Pelican, and Jekyll are frameworks built around a similar philosophy.

[tarr11]

It would be nice if everyone standardized the folder and data formats on jekyll. Then, I could consider switching to a new engine without much work.

[MadRabbit]

that's true, but you need a ruby environment and some hooks to build Jekyll

I didn't want to build a new _generator_. I wanted a self-containing thing that doesn't need a runtime environment

[Touche]

Text shouldn't have a loading spinner. React can do server side rendering so I'd take advantage of that.

[MadRabbit]

there is no server side

[klekticist]

I like this. Very cool :)

[MadRabbit]

thanks! :)

[yuez]

Great! I'm searching for more open sourced blogs like yours.