6 ms·

I'd say the necessity of this post is why PHP is as popular as it is. With PHP, there are no package managers I have to install; there is no template language t

by Xuzz 14y ago

I'd say the necessity of this post is why PHP is as popular as it is. With PHP, there are no package managers I have to install; there is no template language to learn; there is often no version control; there is no "framework"; etc. You just drop in a .php file and, most likely, it will just run. If I need a quick dynamic page on my server, it's much easier to do this in PHP than in Python or Ruby. Until Python or Ruby have that kind of simplicity, they can't overtake PHP. While it might not be the kind of design that leads to well-designed web apps or even good code, it is the kind of design that leads to more — especially less technical, or, like me, lazy — users. It's up to the developers of those languages if this is even a market they want. There may need to be something new to do the same job as PHP, but better, without the innumerable warts.

eevee 14y ago
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/ 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.)
- lloeki 14y ago
  Also, http://pow.cx/ 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.
  - jeltz 14y ago
    Indeed, I would say setting up PHP and Apache is usually more work than setting up Ruby or Python behind nginx.
- conradev 14y ago
  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.
  - conradev 14y ago
    In fact, I felt impassioned about it enough to create a blog and write about it: http://kramerapps.com/blog/post/22551999777/flask-uwsgi-nginx-ubuntu http://kramerapps.com/blog/post/22551999777/flask-uwsgi-ngin...
sparknlaunch12 14y ago
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.
- ashconnor 14y ago
  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.
  - deleted 14y ago
    [deleted]
christiangenco 14y ago
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?
- thatjoshguy 14y ago
  You just described python cgi scripts
  - christiangenco 14y ago
    Ahh! So I was: http://wiki.dreamhost.com/ERB 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.
- grey-area 14y ago
  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.
  - jamesbritt 14y ago
    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.
grey-area 14y ago
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.
- chernevik 14y ago
  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.
zokier 14y ago
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.
- eli 14y ago
  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.
  - drsintoma 14y ago
    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.
- raverbashing 14y ago
  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.
  - zokier 14y ago
    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.
mmaunder 14y ago
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.
- evilduck 14y ago
  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).
  - jiggy2011 14y ago
    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).
    - Silhouette 14y ago
      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.
jiggy2011 14y ago
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.
- bkj123 14y ago
  Regarding your last point... are you talking 'turnkey' as in something like 37 Signal's Basecamp?
  - jiggy2011 14y ago
    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.
FuzzyDunlop 14y ago
> "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.

by Xuzz 14y ago

eevee 14y ago

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/ 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.)

lloeki 14y ago
Also, http://pow.cx/ 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.
- jeltz 14y ago
  Indeed, I would say setting up PHP and Apache is usually more work than setting up Ruby or Python behind nginx.
conradev 14y ago
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.
- conradev 14y ago
  In fact, I felt impassioned about it enough to create a blog and write about it: http://kramerapps.com/blog/post/22551999777/flask-uwsgi-nginx-ubuntu http://kramerapps.com/blog/post/22551999777/flask-uwsgi-ngin...

sparknlaunch12 14y ago

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.

ashconnor 14y ago
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.
- deleted 14y ago
  [deleted]

christiangenco 14y ago

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?

thatjoshguy 14y ago
You just described python cgi scripts
- christiangenco 14y ago
  Ahh! So I was: http://wiki.dreamhost.com/ERB 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.
grey-area 14y ago
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.
- jamesbritt 14y ago
  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.

grey-area 14y ago

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.

chernevik 14y ago
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.

zokier 14y ago

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.

eli 14y ago
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.
- drsintoma 14y ago
  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.
raverbashing 14y ago
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.
- zokier 14y ago
  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.

mmaunder 14y ago

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.

evilduck 14y ago
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).
- jiggy2011 14y ago
  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).
  - Silhouette 14y ago
    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.

jiggy2011 14y ago

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.

bkj123 14y ago
Regarding your last point... are you talking 'turnkey' as in something like 37 Signal's Basecamp?
- jiggy2011 14y ago
  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.

FuzzyDunlop 14y ago

> "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.