PHP will die. What do you think is the following?

It's time for the end of PHP. That's what I'm going to say when my stubborn php molecule is about to convert an existing Ruby on Rails code base into PHP.

History is repeating itself.

I think PHP will die because I've seen it before. About 10 years ago, PHP destroyed Perl. Of course, it's not very thorough; it's still in some environments, it has a sizable number of diehard fans, and the legacy apps need to be maintained for decades. But this language for a new generation of people, especially web developers, it began to perish in 1999, almost completely dead by 2005 years or so.

As a new web developer at that time, things are clear and ripe: Perl is no longer fit for the new application development environment. In Perl, pages require lengthy, formulaic CGI implementations that can be implemented in PHP in BASIC, default programming ways. The Perl language is full of old-age features-references, inconvenient data structures, and many other small, quirky grammatical semantics-that make web development tedious, unstable, and inconvenient. No wonder no good web apps are written in Perl, but you can do it fast and easy with PHP, even though PHP has a flaw that was obvious at the time.

There are a lot of arguments to support Perl against PHP in 1999: Perl is much faster, with more library and driver support, and CPAN is a magical place where written code can save up to 80% of your work. Now it looks a little ridiculous, but "PHP lacks scalability" is a real drawback. But in short, PHP won, because these are not the language inherent in these issues. PHP interpreters can be faster, libraries can be developed, Pera and PECL are now quite large, and this does not include an informal library of vendors who want people to use their APIs.

Time Goes by

Ten years later, I can feel the tide of history is repeating itself. Developers ' expectations of language are moving forward. If what Perl lacks most is the surprisingly flexible "associative array" (or smart hash table) in PHP, what PHP lacks now is the lambdas and method chaining. While PHP is often used to write a Web page in just 20 lines of code, it is now considered not to be doing the right thing if you don't use an MVC framework. The formulaic code shows the problem: the language needs a framework to do these things for people.

Back in the past, I think the stubborn people who use Perl for web development are silly. Now, after 10 years of PHP development, I am in the same position. I can use PHP in one hours to knock out a good site, in a two days to develop a good site. PHP is known for its performance and I can extend it indefinitely. Every developer I've hired will have it, and every system I've integrated has a packaged code base written in it. I'm stuck in the ease of PHP, although it's not the right language for my task.

Turn to Ruby on Rails

The most obvious potential power to succeed PHP is Ruby on Rails. Ruby is a new, clean language with modern language features, loose, elegant syntax (much like Python). Rails eliminates our common tasks, eliminating the formulaic approach of integrating Web applications, and turning the idioms of three or four of lines in PHP into first-class language constructs. It looks very much like the PHP alternatives I need to get the development work to speed up again.

Seven months later, I can't assert that rails is the right choice, and it's hard to say why, I use rails every day to modify a rails application written by an experienced rails expert who loves this framework and language. The purpose of my article is to try to explain the reason.

My main complaint, which must be mentioned, is performance. I have said before that this problem should not be regarded as a fatal flaw in language, but a temporary problem in the realization of language. So I can't think of this as a real problem, even though it's one of the main reasons I'm porting my application to PHP today. I can get rails to run as fast as PHP, but that requires 2 to 4 times times the hardware requirements. I reckon it will be like this in five years, and I may not have to migrate the program to PHP in five years. But now, it does not meet my requirements.

Second, I hate active record. An Active record is a pattern that is not inherent in Ruby and is optional in the latest version of Rails, but its use and the pattern has gone deep into rails ' DNA. I've explained before why I think ORM on this database is not a good idea, so I'm not going to explain it again, but one thing I need to summarize is that you save your hand-writing crud more than the activerecord you lose by doing stupid things, taking the time to figure out how it works, Conform to the framework principle and prevent it from doing such a thing.

Third, I do not trust the code automatically generated. Tools can help you generate template-style code, but your program has a ton of useless code to do that, which is bad. Code generation prefers "magical reasoning" because the generator is not sure whether some of the particularly useful features of the code are specifically written out or that the locale is inherently self-contained. Magical reasoning is dangerous.

Code generation reminds me of a potentially fundamental problem with Ruby on Rails, which is that it's not a language. Ruby is a language. But Ruby, which solves some of the fundamental problems in PHP, does not address the core problem, which is that modern Web applications require a series of improvements: such as Routing,model/view classification, drop-in functionality, etc. are common features. Rails, but it's just a bandage tied to the MVC framework of PHP zend,symfony and Code igniter.

So what's missing?

The language that can replace PHP must be excellent in PHP, just as PHP is good for Perl. It has to assume the primary implementation of Web applications, like PHP, where the main function of your code is to output pages-a somewhat radical requirement that is not suitable for other things, such as the Shell scripting language. I want to have a language that can take on all the tasks I have to develop an MVC Web application, all of which are built into the core and not just a single package.

The problem is that there is no such language. For a while, server-side JavaScript appears to be the next most important language, unifying the front-end and back-end programming languages of Web applications. But the great ideas on JavaScript are always hovering over irrelevant behavior, such as Nodejs: The event-driven model is very aggressive and powerful, allowing you to develop high-performance applications that maximize new hardware, but this is a way to develop server-side applications, not web pages. And you still need to write a whole bunch of scary web pages. Other COMMONJS results such as ejscript are beginning to try to replace PHP, but there is still no solution to the framework problem.

is still waiting

I have to conclude that the substitution of PHP does not exist yet. Ruby on Rails is good, but not much better than a similar MVC framework on PHP, not to mention the double whammy of Ruby's own inefficiency and ActiveRecord's ORM spoof. Python does not seem to be interested in the next-generation Web language, and JavaScript's server-side solution is just the beginning.

I am waiting for the next big goal to appear. I want to be able to move from PHP, really. I don't want to be a Perl antique. But in any case, the language does not seem to exist yet. Do I have a wrong judgment?