Let's Define Big/Enterprise vs. small to mid

I see this ongoing debate alot in the PHP vs JSP threads.

"Use PHP for small and mid sized sites, but use JSP for big sites and complex sites because it scales better."

The problem I have with these discussions is that "big, mid, small, complex, and enterprise" are all relative terms.

So how does one define "big" versus "small?"

In my mind, a "big" site usually has multiple developers or gets alot of traffic. What if the site is relatively simple but gets slammed with traffic? Is it still considered in the "big" category? Conversley, what if the site is overly complex, but doesn't get that much traffic, now is that considered, "small"?

Corporate websites such as Microsoft and Sun, General Motors, those are obviously "big sites"

Your personal homepage is obviously a "small" site.

Would Sorceforge be considered a "mid" or "big" site? Now in my mind they must be huge if they have to migrate off of Postgres and over to DB2. Others might still consider them "mid."

Britney uses PHP, and while the site isn't complex, I'm guessing it gets an insane amount of traffic, although most of that originates from jpenn and SepodatiCreations.

http://www.britneyspears.com/home/index.php

So how do you define "big, complex" versus "small, mid"?

Do I need to read some kind of software development lifecycle book to figure out the answers to these questions?

Well, I really don't know about scalability, at least as far as traffic load is concerned. I've never heard about php buckling on a server, but I really don't hear all that much

As for a complexity goes, though, it's easier to maintain (not design, maintain), an OO application. I think java has the advantage there, since it is the stronger OO language. So as the complexity builds and the bug reports and feature requests start pouring in, jsp should mean less work for the maintainer. In that since, ya, java is more scalable (more complexity, easier).

I'm still wondering though exactly what features jsp's have that php lacks. The biggest difference that I see are related to the Application Server the jsp is run on. And most of those are things that could be achieved with Apache if someone took the time to configure it.

Bottomline, I think it's easier to deal with complexity in java, but not impossible in php.

Well that is a tough question to answer, but I think it depends on how much traffic a client expects to get, as to what tools you might need to build the site and what the users will be doing. The large-scale sites we worked out have heaps of business logic (in the database) and were required to handle 10,000 hits a day. In this system, with business in the database, the java middle layer is a large system bottle neck (i.e slow), and the presentation layer (using JSP) is not well designed (we just did the database ).

In terms of the old java versus php argument, previously php didn't have the ability to to persist variables outside the page scope, except for session variables. However enter SRM (www.vl-srm.net) which is an Application Server for PHP and allows this extra functionality. Now this is comparing PHP with the "application layer" side of java: beans/servlets. Comparing PHP with JSP (java presentation layer) is interesting. I know JSP allows you to define custom tags which I think is much similar to php templates. Personally I do a lot of work simplifying the presentation layer, by writing application type functions to generate web components (menus, javascript UIs, even flash UIs) and I haven't seen this done in jsp (combined with beans/servlets). I think the use of functions (non-oo) and PHP's powerful array manipulation are things that java doesn't have

Of course more likely these differences depend more on the developer than the technology .....

Anyway I though a lot about PHP scalability in this thread, and I've come to the conclusion (with a lot of help from a lot of great posters) that PHP is definately an enterprise solution

Z.

Just to add, I've used Java and PHP and the only OO type function PHP doesn't have that I wanted is overloading of constructors, which is really easy to fudge. In terms of code maintainability I argue that this is up to the developer, and not dependent on the technology.

For me having the ability *not* to use OO is certain situations is a big advantage. Being forced into one style of programming for all situations, is like the old saying when you have got a hammer, everything looks like a nail.

Z.

Thanks for the responses guys, this gives me a couple of different angles to look at this.

I'm a sys admin so I'm new to development. PHP was a natural fit since it has that shell scripting feel to it.

But the current app I'm working on has alot of redundancy, and I'm seeing that I'm wasting alot of time repeating things, it would be nice for me to have good mental framework to build around, in order to minimize duplicate work. I find myself cutting and pasting too much.

The idea of JSP appealed to me because, as I understand it, the coding structure has to be really strict, so it would be easier for someone who isn't familiar with my app to be able to come in and know how it flows.

I have a couple of scripts that are soooo long and so messy, it would take ME a while to decode them.

I've checked out some of the PHP template systems but I haven't quite figured out how they operate.

Oh well, I guess this is a part of the learning process.

Will be nice to see PHP 5 and how that works...

Ted,

I tend to think of "Enterprise" applications not so much in the volume of traffic they will deal with, but with the complexity and critical nature of the work being accomplished. For example, one of my most serious web applications does not even have a hundred users, yet the constraints and business logic that went into this program have made it a very difficult and critical project. (Actually, I have just heard that a much larger company might be interested in using this application, which means I will have to help roll it out to thousands of users). Anyone can create a database-backed website that will serve to millions of visitors a day. But an enterprise application is one in which you are toast if the data disappears, or if the logic is wrong, etc... Meaning, bad software can shut down a company.

You are on the right track in your questions, though. Architecture and programming framework are ultimately much more important than whether you use PHP or Java. I ranted on this subject in this thread and this one.

However, there is a dark side to the non-strict approach of PHP, compared to Java's straight jacket. Unfortunately, since PHP programmers generally start as non-programmers, there is a *lot* of messy, unstructured PHP code out there. (And I am not totally free from blame, have done my share in the past :P).

I used to think it was wonderful that PHP ease of use encourages so many people to publish free scripts, giving us a treasure trove of examples, utilities, etc... to pick from. Now, I am not so sure. After really spending some time thinking and learning about architecture, I usually cringe when checking out some popular script I might want to use. Generally, when I look inside, I have to restrain myself from rewriting the whole thing.

Point is, there are definitely some ideas that can be borrowed from the world of "serious" programming. There is also a difference between frameworks and architectures. An architecture is a much looser thing, simply defining overall approaches to code. A framework is a very structured thing, with libraries of routines, allowing you to quickly build the many standardized, repeatable things you will want to do in web applications. (for example, Model-View-Controller is an architecture, while Fusebox or BinaryCloud are frameworks, with very narrowly defined ways of doing things.)

Generally, I consider a well-though-out architecture a must, while standardizing on an external framework is somewhat more a matter of choice+need. Every programmer should at least have his/her own framework, or any team that works together should have a framework. Whether you feel the need to conform to one of the existing framework libraries depends on such things as interoperability needs, etc... Since I have done many projects and have come up with my own opinions on how to do things, I generally build my own framework, but occasionally I check out the other frameworks for ideas.

I personally think model-view-controller is a great way to work, and PHP+templates is one good way to do this. You might also want to check up on the concept of "design patterns", which helps you come up with strategies to create good reusable code libraries.

rycamor thanks once again for an excellent reply. I spent a few hours going through those links and reading your post. What is interesting is the disctinction you make between architecture and framework.

Awesome calls here Rycamor Can I add development strategy to the list, when it comes to Enterprise Development?

Rycamor is right, Enterprise Applications definately require an architecture. The standard approach is as mentioned Model-View-Controller, or n-tier, with separated Presentation, Application and Persistance Layers. You can mix this up by moving business logic into the database Working in combination with your architecture is your development strategy, most likely a development lifecycle involving a standard series of steps. These steps also tie into how you price your project, as well as how you QA and project manage your project. A standard approach goes something like:

Engage - Collect Requirements formalise in document for sign-off (Terms of Reference)

Specify - Develop solution architecture (top-level design), project plan etc..

Develop - involves three steps:
Design - low level technical design (including framework)
Implement/Build - but not until design is signed off on
Test - oh yeah this is important and if you have done good design, you can draw up your tests (unit) from your design, (rather than the code)

Deploy
User Acceptance Testing (UAT) - users in front of your app
Production - release live to the world

Following this you have a maintenance lifecycle. In an enterprise project following these steps is so important, because otherwise you gets bugs in production. For a more agile approach to the lifecycle check out www.extremeprogramming.org This is a more dynamic approach to development, although it does have its own associated risks.


In my experience it is your documentation, and coding structures (comments etc) that make your code easy to understand. A good approach to take is by having Application Programming Interfaces between the layers. This just means you have a standard way of interacting between the layers, a protocol if you like. This way your applications developers don't need to understand the database, they just need to understand how to use the API Same goes with your presentation coders, and if you use a PHP template system (try smarty) you'll find it already gives you a presentation-application API

If you have followed your lifecycle you'll at least have a clear set of design documents, and hopefully you have followed it through with a standard framework. Strategy, Framework and Architecture are therefore more important than your technology.

Having said that, my preference is certainly PHP because of the flexibility it gives me in development, as well as add-on tools so I don't need to buy Websphere or some other hugely expensive java application server, I have VL-SRM (www.vl-srm.net) to handle this, along with template systems, XML parsing, XSLT translation, ability to call COM and Java, ..... Combine this with real support, and I have all I need

Awesome and good luck,
Z.

Wow, so much info to digest, thanks for the reply Zitan.

I've been monitoring Vulcan for some time. Zitan are you using it on alot of apps? How difficult is it to setup and maintain? Do you run Vulcan on its own server? I noticed that the Vulcan app server can be configured to use UNIX sockets if you run it on the same server as the web server, and that the performance increases in that case are extraordinary.

So far, the Fusebox method has been the most intriguing of all those mentioned. I found this commerical tool out there that now supports PHP and PHP-Fusebox. Now, sometimes tools like this seem to generate more work than they save, but I'm going to at least check out the demo and see what's going on there. Overall though, from at least my initial overview, Fusebox seems to be a well polished system.

Apparently Washington Mutual uses this as their standard web development tool:

http://www.synthis.com/products/adalon/overview.jsp

Hi Ted,



We've had SRM installed with apache, php on freebsd. I've been playing with it and joined the mailing list. However unfortunately there have been a couple of things that have come up (damn RFI) that have stopped me developing a serious app with it yet, but I have plans to do this before the year is up

As far as installing it, this wasn't too bad, check out http://www.vl-srm.net/doc/articles/idiot-guide.php. Also note the mailing list, while not super active, supported all questions we asked very quickly Good bunch of guys. No need to mess with it so far, and maintaining it seems easy with a script that hits CSV. We're running it all on one development server, but you could run it on a separate *application* server if you wanted. Check out http://www.vl-srm.net/doc/design.graphic.php, this gives a good overview of the architecture, the SRM daemon runs outside of php/apache and communicates through SAPI with PHP.

I check with our sys admin about using UNIX sockets, but I haven't done any speed or loading testing as of yet.

I haven't checked out fusebox for a framework yet, I've been more interested in smarty. Especially since you can manage caching and how often you hit the database, very We also have our own internal framework that works quite well, especially since we want to do as much as we can in the database, this requires something more custom I think. Still you never know until you've tried something, so fusebox will go on my list of 'things to try'.

Awesome,

Z.

Very cool information all around.

To my shame, I have not gotten around to installing SRM on my FreeBSD dev server. Hopefully, I will get the chance to do that soon, if/when my career stabilizes. (been doing freelance work, waiting for my company to finalize some deals that will bring back the team, and then some.)



Again, Smarty is not a framework, but a tool that helps you work in the model/view/controller architecture. Actually you can use templates, and MVC inside Fusebox.

I have a certain amount of respect for the Fusebox system, having done a little bit of development with it, but in the end I found it too... circuitous. (little joke there for Fusebox people ). I think Fusebox is great for dynamic webpages, news sites, directories like Yahoo, dmoz.org, about.com, etc... Also, the framework makes it easy to migrate between Coldfusion and PHP (I don't know if that is a benefit or drawback yet...). I can see the benefit when working with a large team, where everyone gets his/her piece of "page space".

But, I found it a little byzantine and constricting for the business-like apps I tend to develop. It forces you to spend too much time on the framework itself (which uses a metaphor of physical fusebox circuits), rather than on the logic you want to develop. Thus, I will have to give it some negative points for lack of transparency.

PHProjekt uses a framework that is similar to Fusebox, but a little less fussy. (this is not to say I totally approve of the coding standards in PHProjekt, but it is fairly easy to add modules to it -- working on a couple right now)

I like the freedom that templating engines give you, but I think that most of the engines, Smarty included, tend to provide too much functionality. Templating should be templating, no more. There is no need for it to also include tons of functionality that are already found in a programming language itself. L. Smith and I got into a discussion about this on the Zend forums.

I am currently working on what I consider to be a very high-performance templating system that will behave somewhat like QuickTemplate , but will be stripped-down in logic, and which I believe will function almost as fast as a templating system done in native C. (I have some tricks up my sleeve-- hopefully coming soon)

Being new to the development side of things, I still just don't "get" templates, how to use them, what the advantages are, etc. I hear ideas like caching being used, and speed of time to market, but the templates themselves seem so cryptic to me I am unsure of any sort of productivity gains would be achieved versus the time spent learning the template engines themselves.

After spending about 10 minutes with the Fusebox documentation, I really get it. I REALLY liked its style,
it's very similar to what I have been intuitively moving
towards as I get better and better.

Now, I'd love to hear some of you experienced guys' opinions of templates, are these worth it to a novice/intermediate like myself to learn, or is this more of a tool for the advanced programmer?

Maybe I should do more diligence on the templates...

Hey Ted,

If fusebox works for you, then go for it. One great thing about it is that it is a standardized approach, and you will be able to find many developers using it. Also, since Fusebox allows you to choose your output mechanics, it does give you the freedom to add templates, and even a Model-View-Controller architecture, if you want.

Templates are not about caching (that is simply an optimization to offset the performance hit of a templating system)

The real concept of a template is to take the HTML completely out of PHP, allowing you to concentrate on your code logic, and even allowing designers to modify the HTML to their heart's content without messing up your PHP. This is a perfect fit for the the MVC architecture, in which templates are the "view" part.

The basic idea is, you make your HTML "front end" separately from your PHP logic, but PHP "pulls" the template in, parses it, and replaces the "markers" with the dynamic values. This makes it very easy to use a WYSIWYG tool such as Dreamweaver to design your pages, without interfering with your PHP code. All you do is regular HTML, with the dynamic values marked off by braces or a custom tag. Something like <tr><td>{MY_VARIABLE}</tr></td>. Your template can even define a certain table row this way, and then PHP can parse that table row in loops, nested inside the main template, to output database rows. So the designer would see one row, with markers, but the application would output as many rows as needed from that template. Try Smarty or Quicktemplate, and you will see.

I'm not saying this is the only approach for any project, but I do think that HTML inside PHP is very messy. The other direction, which I sometimes take, is to put all your HTML inside some sort of "widge