Victor's Blog about the Web, Security and Life

The web for me is a hobby where standards and best practices are daily bread. Security is a concern that everybody must be aware of its details for IT in general, and the web in particular, to be a safer place. My life, on the other hand, is that of a regular Lebanese citizen where politics and social issues are discussed on a daily basis. I hope you enjoy reading my blog and make sure to drop me a comment about any topic you find interesting.

The Future of Web Programming

Printable Version

victor | 02 September, 2009 20:02

I was having an interesting discussion yesterday about web programming languages with a friend of mine during which we tackled various programming languages (PHP, Java, VB and C#) and their competitive nature for web programming. I found it very useful to place a summary (yet a detailed one) about this topic due to the interestingly arguable nature of this topic...

PHP:Past, Current and Future

I will start with PHP simply because it is still my favourite web scripting language. Back in 1998, when I first tackled PHP, many programmers that I knew used to make fun out of it (same way they used to make fun out of Search Engine Optimization back then as well ;) starting from its recursive name (PHP stands for PHP Hypertext Processor) reaching the naive (yet powerful) nature of the language back then. I always had my bet that one day PHP will have to evolve into an application development language (like Java or C# nowadays). Luckily now, I can safely say that is almost here with the presence of the ZendServer, PHP 5, Zend Framework and PHP-GTK. A good business solution nowadays can easily outbeat other applications in terms of performance, stability and speed of production simply by using the tools listed just above. Although these tools are not yet well-know at the commercial levels, they are being introduced (as far as I know) at many academic levels and will make it (in the very near future) to the commercial setting.

As far as the community is involved, I can safely say that PHP did a huge progress over the past two years. Back in 2003-2004, many programmers (and I was almost going to be one of them) moved into JSP with the J2EE being so powerful back then giving up while waiting for a mature and stable PHP framework to support them. Being stubborn, I insisted back then on sticking to PHP and worked for almost 4 months (full-time) back then to produce my first set of PHP modules to be used for Rapid Application Development (RAD) within websites. Lately, I ported my modules into CakePHP and Zend Framework whose combined power is ultimate for high-traffic websites that can serve hundreds of thousands of requests / hour peaking at thousands of concurrent requests with as low as 10% of CPU usage and 1 GB of RAM.

A very simple, yet convincing example of this are two websites that I developed: www.yellowpages.com.lb and www.al-sharq.com. For commercial confidentiality purposes, I cannot reveal numbers in here. Yet, you can visit these websites to get a glance about the dazzling power behind PHP performance when combined with Linux, MySQL, APC and the Zend Framework.

 

Java: The Enterprise Programming Language

I just love Java! I love its powerful architecture, community and powerful solutions. Yet, one main feature lacks Java to make it into the daily websites that people visit: low resource footprint. Java is well known for its huge resource utilization at the server level. A normal website developed in JSP will require at least 2 GB of RAM to properly cache JSP files. Performance, on the other hand, cannot be surpassed by any other web programming languate that I know about (make sure to add your comment if you know about one). The only thing is that you cannot have 50 websites sharing the same server unless you have at least 8 GB of RAM dedicated for the JSP container.

 

Visual Basic: Bye Bye!

VB is dying. Believe it or not, this language will not make it to the 2015 year. If you don't dump it now, Microsoft will in the few coming years (if not months) to give way for C#. Although it will still be used at the OS level, I don't see any reason why programmers will still be using it (unless they are like some of my friends who insist on using VB simply because they know VB and are too lazy to learn another language :)

 

C#: The Microsoft Bet!

Let us talk some facts here. Microsoft learned a lot from VB and learned a lot from J++ and learned a lot from the various applications / servers / services that were offered back in the recent past. As a result, Microsoft has put all of the experience gained into releasing an object-oriented language that is powerful (like Java), easy to learn (like VB) and with a low footprint (supposedly low) like PHP. I am not claiming in any way that I am a C# expert in here (believe I am not one) but I recently benchmarked a web application developed using C# for one of my clients during a security audit and I was surprised by the various security features that were introduced at the security level (especially exceptions) and at the performance level (the server handled 1024 concurrent requests / second for almost 2 minutes before it crashed). I must mention here that this benchmark is completely related to the way the application was written but it helped me gain a little more experience with how C# handles run-time errors and introduced me to the performance tweaks that IIS can help with if programmers get to know them. This lead me to conclude that Microsoft will be pushing forward with C# for the years to come with the hope to get back the old days of VB programming and move forward from there.

 

Conclusion

Let me make this conclusion short. If you want the details behind it, read the article again.

If you are new to programming and are interested in Website development, learn PHP. This is the key to go.

If you just love Microsoft, learn C#.

If you want to make it into Enterprise programming, learn Java.

Better yet, why not learn them all?

 

 

 

Related Articles:

Comments

Re: Sai

victor | 25/09/2009, 12:32

victor

In this comment, I will answer the questions of Sai.

PHP frameworks are crucial for PHP's ability to evolve into the future. It is true, however, that simple PHP scripts are ultra-fast when compared to the same script written in a PHP framework. Frameworks, however, are very crucial for reliable software and enterprise applications. Think of your first question as follows: if you have a good designer with a good architecture writing PHP code, then this code will be very similar to that of a framework.

As for the second questions, OO was introduced into PHP later just as it happened with C and C++. With the introduction of deprecated functions that recently started taking place in PHP, I can see that in the few coming years, PHP will be evolving into a fully featured OO programming language that is strongly typed. Remember that data typing is somehow now present in PHP (although called type-hinting)

As for the third question, PHP is one of the most secure programming language ever. It is true, thought, that many PHP websites are insecure. This, however, is not related to the language itself but is related to the fact that anybody can learn and write a website using PHP by reading one or two tutorials. Security is usually taught at the advanced PHP level and, thus, all of newbies to PHP write websites way before learning the pitfalls of web programming. The same issue applies to Java, C# and VB. The only difference here is that Java, C# and VB programmers use their respective frameworks when programming for the web while PHP is still being used without a framework in many websites. Whenever a framework is used, security features are normally present throught he framework itself (not through the language).

Regarding the fourth question, Ruby and Python are modern languages (also known as 3rd generation languages). As such, writing code using these languages is much easier and faster than writing PHP. As mentioned in my previous post, though, it will need some very good reasons to have a web developer switch from PHP to these languages as long as PHP is evolving and providing web developers with the tools, features and components needed for their daily life.

As for the fifth and final question, I haven't part of such projects before except at the academic level where the time-to-market was not a factor and commercial competition was also not part of the question. I found, though, that combining more than one language has a significant impact on the time to develop especially when it comes to building up a mix of Intranet / Extranet / Web solutions. A simple example is building an application using Java and having its mini Web interface in PHP. As far as complexity is concerned, I did not find any complexity issues especially that both languages were well separated and were not used within the same context. A major disadvantage was having to rewrite some common code instead of reusing the already written one but this was not a major problem within the projects that I worked on.

Re: The future of the Web

victor | 25/09/2009, 11:45

victor

I am overwhelmed by the quality of comments placed here and I thank you all for sharing your opinions. I would like, though, to highlight a few points related to the original post that were tackled throughout the comments.

In terms of future expansion of web programming, my personal vision is heavily based on the way the past has evolved. We all know that Linux is much more reliable than Windows. Yet, Windows is still dominating the PC market despite the many trials that Linux has made through Mandrake, Ubuntu, etc. The reason why Linux did not break through the PC market yet is simply because it hasn't given enough reasons for existing PC users to dump Windows (which they are already familiar with) and start using Linux (which they know nothing about). This leads us to comprehend that it is not enough to be excellent for you to dominate. Breaking through the existing market requires that the current competition either makes a wrong decision / track or that market requirements change towards the new technology and force people to start learning and using it.

Given this historical fact, I don't see why people who are already using PHP, Java and .NET would decide to dump the existing technology and start learning another one unless they have enough reasons to do so.

In my original post above, I mentioned that, at some point, I was personally going to dump PHP and start learning a newer language. This, however, did not happen simply because the Zend Framework came in and real commercial investments started taking place in the PHP market.

As such, I strongly believe that RoR, Python, Django and many other web development frameworks will surely survive and expand. This, however, does not mean that they will be dominating the future of the web unless the existing dominating frameworks (PHP, Java and .NET) either stop evolving or the market forces users (in one way or another) to move from the current frameworks to alternatives.

Given the fact that PHP, Java and .NET are all still active and are still evolving day after day to better serve web developers, I can safely say that web developers will remain loyal to the framework that they are currently using.

Another main point to highlight in this sense is that, nowadays, the question is not about which language is more powerful or easier to develop with. The market approach is more oriented towards frameworks with large communities simply for being able to take code and use it instead of having to write the code from scratch.

It is not impossible for other frameworks to dominate. It is just getting harder day after day.

you forget the best!!!!

jihad kherfan | 23/09/2009, 16:44

did you heard about Ruby on Rails or django
i think they are very good frameworks for both personal and enterprise websites

Problems with PHP

Scott Scriven | 20/09/2009, 03:54

PHP is a nice language for some tasks. Lots of good software uses it. No other language makes it so convenient to mix code and html, which is great for lone web developers who are also programmers. I've found it pretty useful for running my site, mainly because I can so easily put code in the middle of my content, and keep the overall per-page authoring overhead down. However, from a pure programming or information theory standpoint, it's got some serious problems:
Namespaces don't exist at all. (this is similar to keeping all your files in one directory) There have been discussions about adding namespaces, but the proposed separator is \? because "there isn't any other character left"...
Exceptions didn't exist until PHP5, and aren't implemented in a useful "deep" fashion.
Built-in and library APIs are a disorganized mess.
There are thousands of symbols in the PHP namespace. Cleaner languages only have a few dozen. "Everything is built in" just means it has way too many functions in its core, especially since many are minor variations of each other.
No consistent naming convention is used. Some functions are verb_noun() and others are noun_verb(). Some are underscore_separated, while others are CamelCase or runtogether. Some are prefixed_byModuleName, and others use a module_suffix_scheme. Some use "to" and others use "2". And if you take a random set of ten library functions, chances are half a dozen different conventions will be included.
PHP tends to use a lot of similar functions, instead of just one, powerful one. For example, PHP has sort(), arsort(), asort(), ksort(), natsort(), natcasesort(), rsort(), usort(), array_multisort(), and uksort(). For comparison, Python covers the functionality of all of those with list.sort().
PHP includes lots of cruft or bloat. Do we really need a built-in str_rot13() function? Also, a lot of other built-ins are just trivial combinations of each other. Users don't really need case-insensitive variants of every string function, since there is already a strtolower().
Many parts of PHP either deviate from standards, or otherwise don't do what users would expect.
For example, exec() returns the last line of text output from a program. Why not return the program's return value, like every other language does? And further, when would it ever be useful to get only the last line of output?
Another example: PHP uses non-standard date format characters.
The language was generally thrown together without any coherent design, accreted in a messy and complex fashion.
Functions...
Functions cannot be redefined. If I want a set of includes which all use the same interface, I can only use one of them per page load -- there's no way to include a then call a.display() then include b and execute b.display(). I also cannot transparently wrap existing functions by renaming/replacing them.
Functions cannot be nested. (actually, they can, but it has the same effect as if they were not. All functions are global, period.)
Anonymous functions (lambda) don't exist. create_function() is not the same thing. Given two strings, it compiles them into code, binds the code to a new global function, and returns the new function name as a string.
$foo = create_function('$x', 'echo "hello $x!";');
$bar = "lambda_1";
$bar("bar"); // sometimes prints "hello bar!", sometimes fails
Note that the number after "lambda_" is not predictable. It starts at one and increments each time create_function is called. The number keeps incrementing as long as the web server process is running, and the counter is different in each server process. The memory for these new global functions is not freed, either, so you can easily run out of memory if you try to make lambdas in a loop.
Functions are case insensitive.
No "doc strings". Documentation must either be maintained separately from the code, or by (rather finicky) 3rd-party code-level documentation interpreters.
The documentation...
... is often incorrect or incomplete, and finding relevant information tends to require reading pages and pages of disorganized user-contributed notes (which are incorrect even more often) to find the details the documentation left out. Sometimes really important details are left out, such as "this function is deprecated -- use foo() instead".
... is (as of PHP 5.1.2) not included with the source, nor typically installed along with the binary packages. Downloadable documentation is available, but does not match the docs on PHP.net. Specifically, it leaves out all the user-contributed notes, which are important because of reasons mentioned above.
... is not built in. You can't just point an introspection tool at a PHP module and get usage information from it.
These issues are important because it's not very feasible to use PHP without referring to the documentation frequently. There is very little internal consistency, and even less consistency between modules, so you'll probably spend a lot of time looking through the docs. Simply guessing how things work, based on conventions, usually doesn't work in PHP.
Default to pass-by-value. (php5 now defaults to reference, for objects, though I'm not sure if it's "real" references or reference-by-name)
Default error behavior is to send cryptic messages to the browser, mid-page, instead of logging a traceback for the developer to investigate.
Many errors are silent.
For example, accessing a nonexistent variable simply returns nothing. Whether this is a Bad Thing is debatable (I believe it's bad), but it can nevertheless interact badly with some other aspects of PHP -- such as the inconsistent case sensitivity (variables are sensitive, but functions are not):
function FUNC() { return 3; }
$VAR = 3;
print func(); // produces "3"
print $var; // produces nothing
The combination list/hash "array" type causes problems by oversimplifying, often resulting in unexpected/unintuitive behavior.

For example, PHP's weak type system interferes with hash keys:
Code Result
$a = array("1" => "foo", 1 => "bar");
echo $a[1], " ", $a["1"], "
\n";
print_r($a); bar bar
Array ( [1] => bar )
After a little experimentation, I see that hash keys cannot be functions, classes, floats, or strings which look like integers. There are likely other invalid types as well. The only usable key types I've found so far are integers, and strings that do not parse as integers. (note that the parsing used here is different than the automatic str-to-int coercion used for the "+" operator) For details, see akey.php (source).
Awkward / overlapping names can exist... foo and $foo are completely unrelated.
Magic quotes (and related mis-features) make data input needlessly complex and error-prone. Instead of fixing vulnerabilities (such as malformed SQL query exploits), PHP tries to mangle your data to avoid triggering known flaws.
The server-wide settings in PHP's configuration add a lot of complexity to app code, requiring all sorts of checks and workarounds. Instead of simplifying or shortening code (which the features are supposed to do), they actually make the code longer and more complex, since it must check to make sure each setting has the right value and handle situations when the expected values aren't there.
PHP's database libraries are among the worst in any language. This is partially due to a lack of any consistent API for different databases, but mostly because the database interaction model in PHP is broken. The SQL injection issues in PHP deserve particular attention. This amusing exchange explains a bit better...
by CHR1S (694833) on Wednesday July 19, @07:37AM (#15742484)
(http://www.enragednet.org/)
How can it be that hard for web developers to check data before it is submitted? I wouldn't imagine trusting the data that an anonymous user can enter into my website.. so maybe I'm just trained to check data. Of course, I'm also glad I use MySQL with PHP where a simple mysql_real_escape_string can prevent any popular SQL Injection attempt.

by Goaway (82658) on Wednesday July 19, @07:41AM (#15742507)
(http://wakaba.c3.cx/)
You're glad that you use pretty much the only langauge where this is not done automatically for you, but which instead forces you to use a function with a name like mysql_real_escape_string()? And that actually has a similarly-named function without the "_real_" that doesn't do the job right? Just kidding with that other one, here's the real one!
The performance is crippled for commercial reasons (zend). Free optimizers are available, but aren't default or standard.
Bad recursion support. Browse bug 1901 for an example and some details. BTW, ever heard of tail recursion? They might have mentioned it in the "Intro to Computer Science" course.
Not thread safe.
No unicode support. It's planned for PHP 6 but that could be a long time away.
Vague and unintuitive automatic coercion; "==" is unpredictable, and "===" does not solve all the problems caused by "==". According to the manual, "==" returns true if the operands are equal, and "===" returns true if the operands are equal and of the same type. But that's not entirely true. For example:
Two different strings are equal... sometimes.
"1e1" == "10" => True
"1e1.0" == "10" => False
So, they're "equal and of the same type", right?
"1e1" === "10" => False

Unexpected results:
"1 two 3" == 1 => True
1.0 === 1 => False
"11111111111111111117" == "11111111111111111118" => True

Equality is (apparently) not transitive:
$a = "foo"; $b = 0; $c = "bar";
$a == $b => True
$b == $c => True
$a == $c => False
Further, the coercion rules change depending on what you're doing. The behavior for "==" is not the same as used for "+" or for making hash keys.
"22 cream puffs" == "22 bullfrogs" => False
"12 zombies" + "10 young ladies" + "bourbon" == "22 cream puffs" => True
Even though math asserts that, if A minus B equals zero, then A must equal B, PHP disagrees:
"bourbon" - "scotch" => 0
"bourbon" == "scotch" => False
Variable scoping is strange, inconsistent, and inconvenient -- particularly the notably unusual "global" scope which gave rise to kludges like "superglobal" or "autoglobal" as workarounds.

Further, variables cannot be scoped beyond global or function-local.
The mixture of PHP code with HTML markup tends to make code difficult to read. Readability is important.
Various "features" cause very unusual behavior and add complexity. This tends to cause bugs for programmers who expect it to behave like other languages.
For example, this will fail sporadically: Open a file. Write to it. Close it. Open it. Read from the file. To make this actually work, the programmer must A) know it will fail, B) have some clue why it fails, and C) call the correct function (clearstatcache()) before re-opening the file. Note that the online docs aren't much help -- searching for "cache" takes the viewer to the docs for cosh(), but returns nothing at all related to files or caches.
It provides no way to log errors verbosely, but only display critical errors to the user. Further, some of the most critical errors (such as running out of memory) give absolutely no response to the user -- not even a blank page.
Poor security, and poor response to security issues. This is a large and detailed topic, but regardless of whether it's caused by inexperienced programmers or by PHP itself, the amount of PHP-related exploits is rather high. And according to a PHP security insider, the effort is futile.
Its object model is (still) very lacking, compared to other systems.
Most of the development since v3 seems to be devoted to damage control, and dealing with earlier mistakes... not a good sign.
In general, has a tendency to create more problems than it solves.
I would not recommend using PHP, except as a template language for HTML. It's very good at that, so long as you keep the complexity of related code down. It's more powerful and (IMHO) more convenient than strict template languages like TAL, but cannot compete with "normal" scripting languages like Python, Perl, Ruby, and Lisp. PHP is a language optimized for a purpose, at the expense of all other uses. It's very good at what it was originally designed for, but has become stretched way too far since then.

This is waxing philosophical, but in my experience, PHP has an uncomfortably low ceiling. Programming isn't just about putting one instruction after another; it's about building abstractions to better represent and solve problems. The more complex the problem, the higher the level of abstraction needed to solve it cleanly. With PHP, I often hit my head on its low ceiling of abstraction, and it seems to require a great deal more effort and discipline (than in other languages) to avoid ducking down into the details of implementation when I should be focusing on the upper-level design.

Re: The Future of Web Programming

Prabir | 05/09/2009, 07:22

C# : simplicity of VB + power of java & c++ + quite a speed of c++

great post...

and about the memory consumption of java web-apps, it tat really a fact. if so then its really horrible to ever write programs in java.

Re: The Future of Web Programming

Sai | 04/09/2009, 06:13

Read and marked. Feeling a bit weird about the VB section, as Microsoft (apparently) is working hard to keep VB.NET alive and working.

Anyway, I've got a few short questions on PHP (doing a short survey for some purposes), and am wondering whether Victor would be interested in looking at them and answer them (as you se?

1. PHP frameworks became popular after the rise of RoR. Yet many programmer still believes that the fast PHP doesn't need frameworks. They think that frameworks are not necessary when there is a good designer with a good architecture. What's your opinion on the value of PHP frameworks?

2. The OO in PHP is not well designed. Many that works well in Java would take tons of efforts to work in PHP. What do you think on the OO in PHP?

3. PHP sites have been insecure at large. Do you think this has much to do with the language itself (rather than the way PHP programmer write it)?

4. About agile programming and Ruby: does PHP have any advantages in agile programming agains languages such as Ruby (or Python)?

5. Now in some large projects, PHP is used as scripts only, while the more complex tasks are dealed with stronger languages such as Java. How do you think this impact on the complexity of the project, speed of development and the cost of development?

If you could email me back that would be great. Cheers! :)

Re: The Future of Web Programming

Mustang | 04/09/2009, 00:43

I'd say Asp.NET MVC framework is gaining traction fast and poses to be a nice flexible complement for developing web-apps in an agile environment. C# is probably gonna be restricted to enterprise development(web services and such) and desktop apps.

Java is also driving to the same direction where groovy and grails are representing asp.net and asp.net MVC.

Victor, care to comment on the Ruby, Python and maybe Scala and Groovy and their roles in Past, Present and Future?

The "Past" of Web Programming more like

CR | 03/09/2009, 22:53

The only thing I read here about the future is that VB is going to die, which actually has little to do with the direction of web dev. Most of this is a historical perspective on how we got to where we are (which I do agree with for the most part, btw).

But I was hoping to get someone's take on the future. Like where does Ruby fit in? Will the web be run by JavaScript and JSON? Is server-side code dying like VB?

And from a Microsoft standpoint, I see MS going to MVC and away from Web Forms. Agree? Maybe discuss .NET 4.0's impact on web programming, and not specifically C# or VB as the languages being used.

Sorry, not trying to harsh your vibe, but I like the title and wish the article delivered.

Add comment
 
Accessible and Valid XHTML 1.0 Strict and CSS