Open-sourcing my new blogging engine implementation | Hacker News Reader

Open-sourcing my new blogging engine implementation

nikolay.rocks

43 pointsMadRabbit44 comments

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

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

That's reasonable, of course, but it makes the title of this story rather inaccurate.

Even so, kudos -- your blog is lightning fast and a pleasure to use.

I did try it on my low-end Android phone w/Chrome, and it's plenty fast, and the menu works well, but the header and text overflow the view port.

thanks! i don't have a small android, but i'll see if i can fix it with some google chrome emulator on desktop

My apologies -- I updated Chrome and it works fine. That or you fixed something. Either way, nice job.

no problem. i didn't touch anything yet. but i did optimize it for iphone5 at some point, so that might be it.

but, thank you for letting me know about it either way! :)

But I can't modify the engine...

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

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.

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

Oh I get it now!

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

I could care less as long as my browser loads it. I don't surf the internet with cURL though, so it doesn't really effect me.

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

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

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

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

A C-based Apache httpd blogging engine using email to create the blog entries... Sweet.

Reading the source and discovering:

  WTF?  This isn't a WTF.  This is a debugging technique.

Hard core! :-)

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.

fair point. thanks!

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

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.

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

You're doing that with the atom.xml already anyway.

Your approach right now doesn't seem to work with search engines very well:

https://encrypted.google.com/search?hl=en&q=site%3Ahttp%3A%2...

https://duckduckgo.com/?t=lm&q=site%3Ahttp%3A%2F%2Fnikolay.r...

https://yandex.ru/search/?lr=114311&text=site%3Ahttp%3A%2F%2...

http://www.bing.com/search?q=site%3Ahttp%3A%2F%2Fnikolay.roc...

https://se.search.yahoo.com/search?p=site%3Ahttp%3A%2F%2Fnik...

looks like it works perfectly

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

When I remove "sites:" from the query then they all find this page on GitHub: https://github.com/MadRabbit/nikolay.rocks/commit/58a90810f1...

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.

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.

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

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

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

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.

Could you elaborate on what you mean by standardising folder and data formats?

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

there is no server side

> there is no server side

According to the blog:

  There is a small #nodejs server that basically
  does mode-rewrite and sends index.html file for
  any HTTP request.

Sounds like a "server side" to me.

It's served over http so I disagree.

I like this. Very cool :)

thanks! :)

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

Reply on news.ycombinator.com