Hacker News Reader

Comment by malandrew | Hacker News Reader

Why PHP and MySQL?

JavaScript, since it is the only thing that runs in the browser, is a much better choice since the barrier to building and maintaining a site isn't too far from the reach of a novice because only one Turing complete language is required.

With respect to MySQL. Given what WordPress does today and all the other options out there, is WordPress still the best tool for the job?

Why not Postgres or MariaDB? Or how about NoSQL options? Is there an option which would permit development to be just as easy, but that avoids the security complexity of a database exposed to code injections because it execute arbitrary code snippets?

View on HN

Because almost all web hosts have php and mysql already installed. They would not necessarily be my first choice for any application, but for a widely disseminated CMS, I still think those are the best choices. I'm open to being shown I'm wrong, though.

There's a NoSql db on every host as well, the filesystem, and it works great for documented oriented sites like blogs.

Yeah, but doesn't the default number of open file descriptors limit how scalable such a solution is as a default to rely on?

Only if your number of pages exceeds the limit (assuming that you're serializing access to the files) ;)

I highly doubt that's an issue you'll ever run into on a blog.

True, but it's not hard to roll an entire self-contained bundle for which you can find a host.

Back in the 1990s, LAMP was the most widely available stack and finding reliable alternatives for which you had enough information to make an informed decision was hard. However, we are now far beyond that monoculture and there is enough information asymmetry that you don't need to choose a stack based soley on what is common and available. There is enough variety out there and the tools for deploying without having to rely on your hosting company's stack are good enough that we can have something besides LAMP become popular enough for hosting businesses and OS creators decide to include the the necessary dependencies as default.

Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS.

MongoDB is definitely not a no-brainer - what actual benefit is there to being able to 'arbitrarily add fields to a page'? The whole application layer has to support an arbitrary schema anyways, which is bound to be a security and config nightmare.

Look at the mysql schema of a Drupal system. Either you support arbitrary fields at the database level, or you write a ton of extra code (which will have bugs) and piles of support tables on top of your relational database. It's a waste of time and effort and adds unnecessary complexity.

I still don't think the correct solution is to just give up on the relational model and store a bunch of denormalized documents. Just because Drupal has technical debt (which is not surprising to me) doesn't mean it's impossible to model a CMS in a relational way. Can you point me to a particular part of Drupal which is well suited to the Mongo document model over relational, versus simply 'well it's relational now and they cocked it up'?

Drupal has been moving towards Mongo, IIRC.

> Exactly, a new CMS should drop sequel and move to mongo or a similar document store.

Presumably, you are referring to SQL when you write "sequel"?

> Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS.

You can do that using SQL-based databases, so its not really "enabled by mongo". With most SQL-based DBs, you may have to use a data model other than "one page is one row of one base table" to do it, but that's simple enough to do. (With Postgres, there's several ways to do it while still using a "one page is one row of one base table" model, as well, leveraging the XML, JSON, or Array types to hold the "flexible" fields.)

Reply on news.ycombinator.com