The short answer(s)

Because almost all websites need the same basic components in order to be great.

Because it's insane to do any kind of software development without a good library.

The long answer

This is best told as the evolution of a hobby site.

You want to build your own website. You'd like to start by posting some of your pithy commentary and build out from there. Polls, reviews, who knows?

There are a lot of kits out there to help you out, but they all kind of do the same thing: help you make a blog. Well, what if you want a bit more? What if you want to mix and match features — even build a whole new type of website? You may still need all the standard equipment these kits provide, but using them might seriously handcuff your creativity.

What you need is an honest-to-goodness website-building library. Period.

You need something that's designed from the get-go to be extendible, customizable and that doesn't make unalterable assumptions about what you want. On the other hand, it's got to provide all of the stuff you might need.

Tricky.

Building your site (the old-fashioned way)

Let's walk through building your website without a library.

Stage 1: Basic blogging

Maybe you want to be able to post a bunch of links on a page, or, better yet, write up stories or journal entries, blog-style. Ok, that shouldn't be too hard. Just pop the text in there and you're up and running.

• Static web pages aren't really too maintainable, so you get yourself a database and start storing your stories there.
• Maybe you should know when you posted each story. Add a field for that.
• Maybe you've got a friend who's posting stories too. You'd like to know who posted what. Add a field for that.

Stage 2: Security rears its ugly head

You can't both update the same page at the same time; that's just asking for trouble. So, you need a place where you can add stories with a web form. You've got to make a form and make it validate the content.

• Who gets access to the form?
• Just you and your buddy right? What about future editors?
• How do you protect that page? Apache or system users and/or groups?

So your site's getting users and they're noticing some typos. They're sending you emails, but would like to comment on the story directly. Now you've got to extend your form to support editing existing stories. You've also got to build in something that lets users make comments (but not create or edit stories).

• Who gets to edit what?
• Can your buddy edit your stories?
• Who's allowed to make comments?
• Can you ban unruly users?
• What is a user? Do people just enter a name when the make a comment?

Stage 3: Formatting and layout

You're getting fancier stories and you'd like to put in lists and images and other fancy formatting. No problem; you're entering your stories in raw HTML anyway. So are your users when they make comments.

• How do you stop someone from posting malicious JavaScript to your site?
• It would be nice to have paragraphs and basic formatting just show up automatically.
• Which tags are allowed and which aren't?

You want to link in an image you made. You've got to attach it to the system somehow. Just FTP it up and dump it in a folder, then reference it. Easy. Don't forget to make a thumbnail.

• How do you upload files? How do users upload files? (They probably shouldn't have FTP access.)
• What if you or a user forgets the thumbnail?
• What if they don't know how to make one? Or put it in the wrong spot? Or name it wrong?

Stage 4: Bells and whistles

Users think it would be cool to get notifications when a new story is posted. They don't think HTML emails are cool (too much junk and too many viruses).

• You can't realistically keep HTML and plain-text versions of your stories around.
• You'll have to parse the hell out of your HTML format just to look OK as plain text.

Users think skinning the site is cool too; they're getting bored of your same old theme and layout. You want to get fancy with CSS, but you need to first figure out which browser you're targeting.

• Time to redesign your pages to share common styles (maybe you already did that).
• Time to hack together a browser-detector to degrade gracefully (for IE).

Stage 5: Searchability/usability

Your stories are getting bigger, but you don't always have time to write it and post it. You're saving stuff on your desktop in text files before posting.

• Wouldn't it be cool if you could store unfinished stuff in a hidden area on your site?

You've got quite a few stories now and it's getting harder to find stuff. You'd like to be able to find all the stories you've created. In the last month. Of a certain topic. It would be nice to split stories into different sections, so users can more easily find what they want.

• Users want to be able to subscribe to specific sections.
• They also want to save their searches because they're sick of making them again and again.
• Saved searches are pretty cool. Can I print this list? Can I show it on my user home page?
• Do I have a user-specific home page? What can I customize?

Stage 6: Security rears its ugly head II

The site's humming along and you want to make a registered-user only area. There are also some private areas for editors and premium users/subscribers. You'll need to make some sort of user groups just to keep it manageable. You need to define who gets to do what.

• Security's getting to be a nightmare, what with public/private areas, hidden files and all that.

Stage 7: PostGreSQL sounds cool

MySQL seemed like a good choice at first, but its full-text search isn't doing it for you. You'd like to flip to a different database and see how that works.

• Too bad your SQL is all over your site and some of it's pretty MySQL-specific.

And, finally, the killer...

Stage 8: Reuse

Now you think you'd like to open up a site for game reviews. You can't just start simple, can you? You've got to have all of the same features as your story site, right up front. Too bad the code for your story site just kind of grew and isn't all that refactorable.

Time to start copy/pasting...

Spare yourself the grief

Focus on your own application's features, not a web application's features.

When you think about making a website, you know exactly what you want. You want everything, but you don't have the time (and maybe not the skills) to do it. So you skip it all and put up something fast. It works for a while, but you have to spend way too much time on details instead of adding more application-specific functionality.

When you start with an earthli WebCore application, you've already got an enormous base of software on which to build. You can focus on things that make your application special instead of rushing to catch up with all of the features that make your application great.

A general solution

Don't let the limited reusability of other products define your application.

You may have noticed that the product we built above exists already. It's called SlashCode or PHPNuke or Mambo. Bulletin boards like PHPBB, vBulletin and other do those things too. They also have a lot of other bells and whistles, but most of these products are really domain-specific. What if you want to make a photo-album manager (just off the top of my head)?

• Could you use one of these to do that without some pretty heavy modification?
• Is there a clear-cut interface between the core functionality and application-specific functionality?

Probably not.

That's what the earthli WebCore offers: you get to reuse code for similar tasks in vastly different applications. What's more, with a clean separation between application and library code, if a new, advanced feature like moderation is added (a la Slashdot), it can be written generically and made available for any WebCore application that wants to use it.

Finished products

It's not just theory — it really works.

This application/library separation isn't just a theory. It already exists and there are, to date, four applications built on top of the WebCore: Albums, News, Projects and Recipes.

Two of them, News and Recipes, are relatively thin layers: they don't add to the base functionality of the WebCore very much at all. Looking at the code, you see that these applications mostly focus laser-like on defining the UI for the application. The core logic is already in place, so you're free to define properties and decide how the app's going to look.

Albums and Projects are larger applications, adding a lot of properties and utilizing multiple object types within one application, journals and pictures in Albums and changes, jobs, components, branches and releases in Projects. At each point, the application only contains code to define features specific to its problem domain. Projects doesn't need to implement threaded commenting. The WebCore's already got that covered.

On the other hand, the WebCore is fully object-oriented (as far as PHP 4.x allows), so it's not a big deal to create a customized comment object for an application and link that in instead. If you need more properties, you just define them in a descendent class and tell your application to use that class instead when creating/editing/storing comments. Find out more in customization.

Conclusion

Websites are software. Writing HTML may not be programming, but making a good website today sure is. While PHP is free, fast and pretty easy to use, it doesn't deliver the tools you really need to make a great website. If you use only PHP to build your site, you've got a long hard slog ahead of you.

Do yourself a favor and try out the earthli WebCore. You'll be glad you did.

Still not convinced? Read more about earthli WebCore's extensive features.