5 ms·

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 sit

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?

rquantz 13y ago
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.
- gnaritas 13y ago
  There's a NoSql db on every host as well, the filesystem, and it works great for documented oriented sites like blogs.
  - malandrew 13y ago
    Yeah, but doesn't the default number of open file descriptors limit how scalable such a solution is as a default to rely on?
    - skyebook 13y ago
      Only if your number of pages exceeds the limit (assuming that you're serializing access to the files) ;)
    - gnaritas 13y ago
      I highly doubt that's an issue you'll ever run into on a blog.
- malandrew 13y ago
  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.
te_chris 13y ago
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.
- alanctgardner2 13y ago
  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.
  - Torgo 13y ago
    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.
    - alanctgardner2 13y ago
      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'?
- steveklabnik 13y ago
  Drupal has been moving towards Mongo, IIRC.
- dragonwriter 13y ago
  > 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.)

rquantz 13y ago

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.

gnaritas 13y ago
There's a NoSql db on every host as well, the filesystem, and it works great for documented oriented sites like blogs.
- malandrew 13y ago
  Yeah, but doesn't the default number of open file descriptors limit how scalable such a solution is as a default to rely on?
  - skyebook 13y ago
    Only if your number of pages exceeds the limit (assuming that you're serializing access to the files) ;)
  - gnaritas 13y ago
    I highly doubt that's an issue you'll ever run into on a blog.
malandrew 13y ago
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.

te_chris 13y ago

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.

alanctgardner2 13y ago
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.
- Torgo 13y ago
  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.
  - alanctgardner2 13y ago
    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'?
steveklabnik 13y ago
Drupal has been moving towards Mongo, IIRC.
dragonwriter 13y ago
> 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.)