16 comments

[ 0.76 ms ] story [ 48.1 ms ] thread
I looked at this the other day. Nice one.
Seems neat and I'd love to give it a try. I'm not a blog engine expert by any means, but it seems to be the the killer feature missing from this and other "this is not wordpress" blog engines is the ability to accept/read wordpress themes. Almost everything on woothemes and themeforest are available as wordpress themes, so why not? Is there a license issue with this?

Edit: I get the php issue here. It's not really an issue I don't know why everyone jumps to assuming you need. Php interpreter. Anything running node.js can run php. Im just saying that there are a ton of wordpress themes out there and Id be much more willing to try something new if I was able to reuse a theme. At least reuse parts or most of it.

WordPress themes can and do embed arbitrary PHP, so wouldn't you have to basically build in a PHP interpreter in order to read them?
I don't think anyone is going to write a PHP parser for a couple of shitty themes
I updated my comment. I wouldn't approach it from the idea of a php parser. Also, don't assume that its a couple of "shitty themes". I hate to tell you this, but wordpress wouldn't be where it it today without these "shitty themes". Writing a blog engine in node.js is a great start, but to gain traction you need to appeal to the masses.
If you're shelling out to PHP to execute the themes (which is likely to take up the bulk of processing time outside of talking to the database), why write the rest of the CMS in a language other than PHP?
Considering WordPress uses PHP for its templates (like "<?php the_title(); ?>"), it would be more sane to just rewrite the themes to use the templating engine Calipso uses.
> It's not really an issue I don't know why everyone jumps to assuming you need. Php interpreter.

Yes, you do need a php interpreter to run wordpress themes as many wordpress php functions need to be customized in order to change the css.

> Anything running node.js can run php.

That doesn't make any sense. Anything that can run node.js can also run erlang, so let's use some erlang code inside node.js, right?

"That doesn't make any sense. Anything that can run node.js can also run erlang, so let's use some erlang code inside node.js, right?"

Sounds right from a Turing perspective, but probably not from a pratical point of view. There are tons of services that provide PHP hosting, but you probably need a root server for Erlang. All services that run Node.js (except Node.Js specific services like Joyent) are probably root serves and so can run PHP.

I'm sure they can run php, but that won't help running wordpress themes coded in php run in a node.js app.
(Speaking about the "Speedy Foundations" section)

Is there some kind of magic in Node.JS and MongoDB that makes application logic fast and scalable?

Am I just a curmudgeon? Am I barking into the wind?

Language choice never implies speed or scalability. Map/Reduce doesn't imply scalability or speed either. Am I wrong about this?

I started thinking about why this kind of FUD bothers me so much (BTW, it bothers me a lot.) It's because it's an apparent willful ignorance of empirical evidence. It hits the same annoyance center of my brain that rapture predictors do.

No you are right. The modems fanaticism is mostly nonsense. Erlang is better for that approach to concurrency in general, amongst other things.
Node js got corrected to modems. Sigh.
I think the idea is that the asynchronous nature of node helps it scale well. Even if it isn't really faster or more scalable I like that these frameworks are giving developers more options for backend js.
People need to read Zed Shaws "poll, epoll, science, and superpoll" on this, and no longer repeat the "scale well" mantra.

"Another way to put this is if your server or protocol is the type that transmits a ton of data and can't tolerate idle resources, then poll will win. [...] But, if your server is the kind with lots of idle connections just hanging out, then epoll wins not poll."

http://sheddingbikes.com/posts/1280829388.html

Initial observations:

1) The user experience could use some work. The initial message that shows the login/pass info is volatile, and is gone after a page refresh. Not only that, but it's flat out wrong. (the username is 'admin')

2) Apparently theres no password hashing? Seriously?

3) I guess it wouldn't be a CMS unless it stored it's configuration and settings in the database. This just looks like a pain in the neck for making changes to a dev/test/production environment. (I'm guessing the target user isn't that serious about development?)