CGI scripts have much of PHPs simplicity. You can just drop in a executable file, and depending bit on server configuration, it will just run. With Python a basic hello world would look something like this:

    #!/usr/bin/python
    
    print "Content-type: text/plain"
    print ""
    print "Hello World!"

So 3 lines of "boilerplate", and then you can do anything you want. No extra packages to install or languages to learn. No frameworks necessary.

edit: just as an example of minimal hello world in WSGI:

    def application(environ, start_response):
        start_response('200 OK', [('Content-type', 'text/plain')])
        yield 'Hello World!'

also doesn't need any extra python packages or frameworks. but configuring web server to handle wsgi is bit more involved than cgi.

And therein lies the problem, in WSGI

99% of web sites are hosted in "shared hosting" services

Now compare copying the .php files with configuring WSGI

"No, but WSGI is easy blah blah blah" it doesn't beat copying files And no, settings WSGI is not easy

Also, if you depend on IIS for example, PHP is almost plug'n'play

WSGI on Windows is the definition of "bag of hurt". You can try fastcgi to run on windows, and then you find out flup needs socket.fromfd

The easiest way, if it's your machine, run gunicorn or similar and just make Apache redirect the traffic.

But in shared services it's still way too complicated.

FastCGI works fairly well in my experience on shared Linux servers (that's how I host my personal projects). And for smaller scripts where I don't bother setting up FCGI, I just use plain CGI, which is just copying files.

I think shared hosts have already enabled FastCGI for all php files

Something like this: http://test.fastcgi.com/drupal/node/5?q=node/10

At least the shared hosting I use (bluehost) has warned me they were enabling this. In 2007

Still, for most uses, CGI works fine.

might want to not do that... http://www.php.net/archive/2012.php#id2012-05-03-1

That only affects PHP scripts running as CGI (using a certain specific configuration), not CGI scripts in general.

Let's look at the PHP version:

    Hello World!

One line. I didn't have to worry about Linux/Windows, knowing HTTP headers or the fact that I need two CRLFs after the last header[1]. I just wanted a page that says "Hello World!" and that's what I got.

Don't get me wrong, I would never choose to write a web app in PHP over python. But it is brain dead simple to go from nothing to something in a few keystrokes. Which is precisely what people just learning to write web apps want (right or wrong).

[1] I can't remember how long it took me to figure out that I needed the second CRLF after the "Content-Type: text/html" when I was learning perl (or even the fact that I needed to specify the Content-Type in the first place).

In the context of the parent comment I'd argue that the differences are insignificant. Xuzz argued that PHP is simpler because you don't need to know the ecosystem. Which I countered by showing a basic example of Python which doesn't depend on the ecosystem (like frameworks, package managers or version control).

Besides that, I don't think knowing HTTP headers or understanding significance of trailing newlines is required to write CGI scripts. You only need to know that you need those three 'magic' lines in the front of your scripts. Similarly like you need to know that in php you need <?php ... ?> around your script.

But I never needed to worry about those three lines in PHP, to a new user that is important. To you and I they come naturally.

PHP "is especially suited for Web development and can be embedded into HTML" [1]. Python "lets you work more quickly and integrate your systems more effectively" [2]. They can both do the task of the other, but the upstart time for a developer to handle the task of making a web app is smaller for PHP.

I've never taken the non-framework approach with python for anything significant, but how does it handle cookies, GET and POST fields, sessions, and file uploads? In PHP you'd have $_COOKIE, $_GET, $_POST, $_SESSION, and $_FILES as built-in global variables.

Are these differences still insignificant?

[1] http://php.net/ [2] http://python.org/

Python has a `cgi` module that does most of the superglobal stuff for you.

But, er. Does this really matter? Yes, you can get "hello world" in PHP with one line of not-PHP. You can also get "hello world" in Python + Flask with seven lines, and you'll get half a dozen extremely nice features for free that you can learn about as you go.

Arguing about what stack has the simplest way to build from total scratch is a sad race to the bottom. I'd rather be making the point that rich Web development can be easy, not that cobble-your-own-thing-together-with-duct-tape can be easy.

The first poster in this thread made the statement: "If I need a quick dynamic page on my server, it's much easier to do this in PHP than in Python or Ruby."

So yes, it really does matter in the context of this thread. On the whole I agree with your philosophy that frameworks are there for a reason: you get many features for almost nothing.

But sometimes you just don't need a framework, you need something quick-and-dirty that just works.

But even something quick and dirty is longer than "hello world". I've written a couple pretty dinky things with Flask, and the minuscule overhead of typing `import Flask` was definitely worth having e.g. a solid template language and XSS protection ready to go.

Yeah, PHP is great to start off with, it's simple and everything in the language is obvio- Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

That's only hard to understand if you don't speak Hebrew. Anti-Semite! :)

CGI is easy, yeah, but it has a lot of the same disadvantages as mod_php: no routing, no shared state, slow execution, server misconfiguration can expose your code, possible code execution if you accept uploads, etc.

There are approaches that'll let you dump a WSGI app (with a known interface) anywhere and have the web server still run it. Gosh, someone ought to write about those.

It's a good point that of course python web apps don't have to be complicated. But what you're describing is also not the same as PHP.

plus you can not just mix html and python code, which might not be a good practice, but is incredibly useful for something quick and dirty.

PHP is a template language at heart, so it's a little disingenuous to say that it doesn't force you to learn one, as it does - it's like the erb template language part of rails without the controllers and models. That's fine for what it is, but becomes cumbersome if you want to persist data to the db, handle forms for your models, etc at which point you'd often be better served looking at a framework which does a lot of that work for you. Some are available in PHP, but there are IMHO better options in other languages, and of course, better languages.

Do we need to have one language which scales from 'throw together a web page' to complex web apps? Is it even possible or desirable?

While I think it'd be nice to see Python and Ruby have the number of users that PHP does (though perhaps it wouldn't, with scale comes a worse NSR), it's probably not going to happen, simply because they provide a bit more structure, and many people don't want structure. Those people will be happy with PHP (until they're not, and realise they needed that structure after all), and I don't think Ruby or Python frameworks really have any ambition of catering to them. That's fine and is not a failing on either side. For example no one on the ruby side is going to stop using gems as package management because users starting out might be confused, as they are just too useful. You will find plenty of web frameworks for ruby which are simply one gem to install and off you go though - hardly onerous.

It would certainly be possible to write a better PHP, but all the people who might do that are busy using slightly more complex frameworks which make web development easier.

I am but an egg. But refactoring badly done projects that were started as PHP seems a plausibly common pattern. If Python or Ruby were simpler to start with, there would be more badly done Python / Ruby code, but at least it would refactor in Python / Ruby.

The core Py / Rb community probably wouldn't use simpler quick-and-dirty setups, they have the skills to the same things better and faster already. But making that pathway available would bring more novices to the language, hopefully growing them into Py / Rb. And it would bring more projects into the fold.

There appears to be currently ongoing some sort of shift in web development.

At the top end of the scale , people are creating more sophisticated "app like" websites that use sophisticated platforms like AWS and "serious" programming like Scala/Java/Ruby/Python/jQuery etc. Because once you have decided to invest serious money in your web development you want to use the best tech you can and build a very "bespoke" online experience.

However at the lower end, sites that would have 5 years ago been build using static HTML with a smattering of PHP and be run on low end shared hosting are being devoured by various platforms. For example rather than hire a webdesigner you can have a facebook fan page or wordpress blog for free (possibly paying someone to customise the CSS in a template for you). As another example in my area there are various services aimed at the takeaway business that provide a turnkey website with an online menu, opening hours, maps etc.

To be honest, working in the low end of the web dev market has always been a nightmare as this is where you will get shaky clients who can't articulate what they want and hardly want to pay anything for it.

If I was going to go back into website development for a business I would be far more interested in finding common requirements for a particular market segment and building something turnkey to sell to 1000+ customers at $20-100 per month where they can upload their own logo and change a bit of the CSS.

Regarding your last point... are you talking 'turnkey' as in something like 37 Signal's Basecamp?

To an extent , yes. Although basecamp is something that is intended more as an internal tool that just happens to work over HTTP and is not directed at any specific market niche (other than perhaps general SMB).

Let's think about real estate as an example. I imagine that pretty much every real estate agent will want the following features on their website:

A list of properties (that can be sorted by Price etc)

Search By Postcode/Zipcode.

Then a page for each property with:

Pictures from inside/outside the property.

Asking Price.

Number of bedrooms/bathrooms.

Some blurb about the property.

A form to book a viewing (possibly integrated with calendering at the backend).

Of course they will also want the generic "contact us" pages and pages about how great they are.

You could develop all of this bespoke every time for each estate agent, but then the amount of time you invest and how good you can make it are capped by the amount of money they want to spend on the project. You also have to worry about hoating arrangements for each client.

Alternatively you could just build the best real estate website you can make, host it on your own infrastructure and charge a monthly fee to rent an "instance" of it. Because the website is already built activation can be instant.

As an added benefit (if you get enough users) you now have a huge database of properties which you could potentially use to launch your own property search/comparison website.

You will have customers who will require more custom functionality and will eventually outgrow your "one size fits all" system regardless of how customisable you make it. At this point however they are probably willing to pay a significant amount of money to have a bespoke website developed. Another option at this point would be to license them the sourcecode for your system so that they can take it elsewhere for modification.

Most of the post _isn't_ strictly necessary. You don't need a database to get your feet wet. You don't need to care about XSS for your first throwaway app (though, arguably, you should). I pimp Mako precisely because there's no separate language to learn: the core syntax is just Python.

I tried to describe the _ecosystem_, and I assume any serious PHP application will care about most of the same things.

Here's all you really need: look at http://flask.pocoo.org/ and do that thing it says right there. You don't even need to install a separate web server. (Yeah, yeah, 5.4, I know.)

A "quick dynamic page" is a deployment problem. If you're already running Apache and mod_php, you already have an environment ready to go to serve PHP, so of course it'll be easy for you. I don't run Apache, so PHP doesn't really help me there. (mod_passenger promises to, but I haven't tried it with Python yet.)

Also, http://pow.cx/ (Ruby I know, but it shows such things can be done.)

Also the argument of python/ruby requiring lots of configuration while php would not is just plain bullshit. Making PHP run with Apache (esp. on a windows machine) without stuff like EasyPHP (and this is where you stop comparing apples to oragnes) is by and large tough on the beginner.

Indeed, I would say setting up PHP and Apache is usually more work than setting up Ruby or Python behind nginx.

I am lucky that I found Flask a while ago, because I was sick of PHP. Flask, jinja2, and uWSGI have since been my best friends.

It took a little while to figure out how to setup a proper web server around those, but the guides are not that complex. Install nginx, darmonize uWSGI with upstart, and configure it. It's funny, in some ways it's easier to use than PHP, because when I am working with the website on my local machine, I can run uWSGI in http mode, no configuration necessary.

The only barrier I see going from PHP to Python or Ruby is managed hosting.

In fact, I felt impassioned about it enough to create a blog and write about it:

http://kramerapps.com/blog/post/22551999777/flask-uwsgi-ngin...

I agree on the simplicity of php. The barrier to write php is low. All you need is notepad and browser. This may be a transition from writing html.

Compare this to other languages where you need multiple tools before you can even begin.

This doesn't make php better. It just may explain why less people make the jump.

You also need a server, which I think is one of the crucial components for PHP adoption.

MAMP, XAMPP, WAMP are all really easy to install and you don't need to go into the CL to do anything.

> "With PHP ... there is no template language to learn"

While this might be nice for the beginner getting started, it's also a brilliant way to encourage bad habits in people who want to turn it into a career.

Leaving the "PHP is a templating language" pedantry aside, this 'benefit' encourages the aspiring developer to not bother separating concerns. Just go ahead and throw HTML into PHP and vice-versa; throw all your database logic, SQL, and connection details into those self-same files that are being served; leave XSS vulnerabilities in all your code because you probably weren't told to wrap your output in `htmlspecialchars` or whatever.

Shit like that needs to stop. But as the barrier to entry is so low, the same mistakes will be repeated ad infinitum. I would love to figure out a way to introduce a beginner coder to a language, without scaring them off, but without being lax with security and separation of concerns.

That being said, I do agree about frameworks, but I also think that this is because there is no "one true framework" for PHP (Zend, Symfony and Cake don't fit the bill, I don't think). There's no Rails, or Django, and there's no Sinatra or Flask as a minimal alternative. PHP is dire for framework development, not because of the language, but because so many groups of developers are trying to re-invent the same framework (but with their own idea of what 'the PHP way' should be - Javatastic bloat like Symfony and Zend, or Rails mimicry with no real understanding of PHP not being anything like Ruby), treading the same ground over and over again, when there could be more collaboration to provide the definitive offering.

If that were to change, and for the better, I might extend my argument to say that such a framework may be a great way to learn PHP, just like Rails was a great way for many to learn Ruby.

It took me a while to get used to creating an HTML file and making part of it executable. How utterly obvious and convenient. Templating systems and MVC frameworks now seem like bureaucracy that solve a purely theoretical problem.

Sure, if all you need is a mildly dynamic page the full blown MVC frameworks that are "standard" for other languages probably seem like bureaucracy to you. But they have their uses, and they also exist for PHP for a good reason. MVC makes massively complicated systems easier to maintain, especially if there's more than one contributor.

Example: I'm responsible for maintaining a "classic" ASP project that's evolved over many years ('98 was the oldest code comment I've found). A report has the wrong value for the record on it. Where do I go to find the source of the error?

You'd say "look at the page that edits that value". Well, sure, but there are dozens of pages that edit that database table plus dozens of other processes that could be altering it (stored procedures, print processes, scheduled tasks, people manually writing SQL statements, etc), looking at all of them would be a huge headache. In a MVC system, I would just go look at the model file of that table and debug the methods it uses to manipulate the database (that's simplified, but it's much less work than the spaghetti alternative).

That is of course assuming that the person who wrote the original code actually understood how to use an MVC framework.

It seems to me that most peoples default assumption upon encountering one is to use the Model as a simple abstraction to the DB and stick all of the logic in the controllers (with many controller methods calling methods in other controllers).

It would help if web frameworks that have precious little to do with MVC would stop trying to piggy-back on the term. For example, if your model, view and controller have a control flow that makes them three layers in a stack, with the controller sitting between the model and the view, then your architecture is not really anything like MVC at all.

The common architectural pattern for web apps where you have a request handler that talks to a database and then generates its output by filling in a template is popular and widely applicable. However, I think the way some of these frameworks tried to hijack a well-established term for publicity in the early days has come back to haunt them now they are better known. Today, if someone wants to learn how to use these web frameworks, particularly the common underlying concepts and design skills, and searches for "MVC", they find a whole load of other information that doesn't really make sense in the context of web apps.

Similarly, anyone who really does want to learn MVC in a context where it is more applicable -- including designing larger JS-based applications that run primarily in-browser, for example -- comes up against a lot of material that is in some cases almost the antithesis of MVC, which doesn't help there either.

When the most common reasonably simple architecture beyond PHP's everything-is-a-template starts off at such a disadvantage, it's not really surprising that many people struggle to understand the basics and just stick with PHP's "it just works" instead, despite the other disadvantages they suffer in making that choice.

All we need is to be able to drop an .erb file in a server and have it instantly rendered with the same magic of .php files. How hard would that be?

Anyone here know how to write plugins for Apache?

Install eruby binary (example given is ubuntu/apache):

  sudo apt-get install ruby libapache2-mod-ruby eruby

Set up your web server to serve it:

  AddHandler rubypage .erb .xhtml
  Action rubypage /cgi-bin/eruby

Start writing pages like this:

  The time is <%= Time.now %>.

The first two steps could be completed by your web host, or done by you once. Obviously you might run into performance issues etc (no idea how well this would work on a live server), but that gets you up and running.

I would point out that most examples you can think of as trivial as that above could just be done with js anyway though, without any dynamic language server-side - the main reason to use a server-side language is to talk to a db or store data, at which point you probably want a framework anyway.

It's already a solved problem really, but people at that level are happy enough on PHP, which for the example above would be almost identical, and for anything more complex a framework is actually useful, and so there's no point in starting this way for many web projects.

As I recall a big issue with mod-ruby was that it used a single Ruby process for all scripts.

That meant if script A decides to rewrite, say, Array#include? to only work with symbols (or whatever), script B now has to live with it.

You just described python cgi scripts

Ahh! So I was: http://wiki.dreamhost.com/ERB

Now all we need to do is make this a default .cgi in all apache installations and we're golden.