Websites - server side coding - why not languages like Java, c++, etc?

Question

Is there any real reason why no one makes there dynamic webpages in say c++ rather than interpreted languages like php that are many times slower?

I can see several reasons why I wouldn't mind my entire site being just one dll, with each page being represented by a function or something.

• Varibles can be shared between page requests, and even across multiple different pages, eg a list of all the users currently logged in
• Multithreading would be easier. Eg allowing multiple pages to be requested at once, since everything is running in the same program, varibles can be shared easily (eg lock handles) (does php even support doing this at all?).
• Resources can be pooled far more easily, eg db connections which under php are oftern created for every page request

And if there isn't a real reason why not, then how could I go about doing it?

Answer 1

You surely can make web pages using Java, C# (.NET), C++, Delphi etc. For more classical languages, there are CGI, ISAPI/NSAPI. Also frameworks and some web servers (IIS6 for example) allow dynamic deployment of compiled modules.

Answer 2

Google uses both C++ and Java in addition to Python, so it certainly is possible

Answer 3

Web pages are usually I/O bound, not CPU bound. There's no reason to use a compiled language -- and even when there is, you can write a small ~1Kloc module in C and get all the benefits without having to worry about buffer overflows in form processing or whatever.

Variables can be shared and pooled in dynamic languages also. That's just an implementation detail, and not related to languages.

Multithreading is much, much harder than separate shared-nothing processes because database drivers are often single-threaded. Again, this is independent of language -- and writing in C would make it even harder because it doesn't have nice memory management like Python or Ruby.

Answer 4

The program that handles serving all of your php is probably written in C/C++. The nuts and bolts of a webserver are written in some high-performance language; for actual page rendering, it is much nicer to write your pages in a language meant for it (php) than in a language where it is a royal pain (C++).

If you actually have to, nothing is stopping you.

Answer 5

@eed3si9n & Jeremy Banks

So ok but how? I'm not seeing a way to drop a dll onto a server and have apache or ISS load it and call functions when pages are requested without modding stuff. eg for index.(whatever it would be???) have it call (c++) "void PageIndex(std::ostream &Out, StringMap &Get, StringMap &Post)"

Answer 6

Just to correct the topic, Java does have an amount of different ways to present websites, and the existence of server applications such as Apache Tomcat, IBM WebSphere and JBOSS might be of an indication.

Actually, there are many notable sites that use JSP or other Java technologies, Nokia springs to mind.

I, however, don't know why C/C++ aren't used as much for this. Or maybe they are, but not publicly so at least.

Answer 7

The single biggest reason for using interpreted languages for web development on the server side is ease of use. Web development tends to be very fast-paced and frequently updated. In such an environment, it's dramatically easier to use an interpreted language and scripts that can be updated without recompilation. Initial development pace is also much faster than what can be expected in writing in C. Similarly, it's generally easier to maintain scripts in high level languages than it is to maintain C++ or even Java code.

That being said, many of the same benefits can be achieved using a templating system such as Clearsilver which is written in C and well known for being fast and light. Some large sites use C/C++ code for the most performance critical applications, like Yahoo & Google groups. Java is also extremely common in "enterprise" web application software, which is why products like Tomcat and WebSphere exist, to provide a Java-friendly application server.

The bottom line with writing server side (or any other) software is right tool for the job. You have to decide what your critical features are. If the most important thing is performance then C or C++ might be the right tool for the job. If the most important thing is speed of development, Python might be for you. If availability of frameworks and libraries for web projects is key, PHP might be the right choice.

Answer 8

If you really want to use C++, you could write FastCGI apps for lighttpd. The speed advantage usually isn't worth it however, because it is insignificant in comparison to network lag -- maybe you can generate your page in 2ms instead of 5ms, but does it matter if 200ms is lost to network delay?

Also consider that most time is typically spent doing database queries, and MySQL is already written in C / C++. One case in which it personally did make sense to use C/C++ was the need to generate images dynamically in a situation where ImageMagick/GD wasn't fast enough.

If there is data that is accessed a lot and needs to be in shared memory, perhaps you can use memcached for that.

Answer 9

you'll have to do more work with C++ because there's no 'loader' for compiled binaries as there is for the scripting languages.

Check the ISAPI extensions for working with IIS and C++, or the ATLServer COM features. For Apache you'll want to build your program as a CGI app.

Answer 10

If you really feel so inclined, you can use the Cgicc library for your C++ CGI webpages. Although as others noted, the memory management issues, along with the other nastier parts of C++, don't justify the relatively small performance payoff here. Plus, C++ is a very delicate language, meaning that it's harder to rapidly deploy applications as quickly as with web-based scripting languages such as PHP, Ruby, Perl, etc.

If you're writing a web application where CPU power does become the bottleneck, you'd be better off writing a C++ backend system and wrapping it with a PHP/Ruby/whatever frontend. At least that way you get the best of both worlds, and leave all of the client I/O stuff to a more pleasant scripting language.

Answer 11

My whole website here http://www.scale18.com/ is coded fully in C. The whole website runs on one compiled exe that I wrote myself. It has a bunch of template html pages with my own special tags for "insert special thing here" in them.

Answer 12

Java is one of the most popular server side languages. There are a very large number of Java frameworks that support this like Tomcat, JBoss, WebSphere, WebLogic, JRun, Spring, etc. In enterprise application circles Java is often the primary contender on the server side.

The advantages which C/C++ bring to system programming and non-web applications are often lost in web serving situations. The type of processing typically seen on a web server, even when it is CPU intensive (which is rare) rarely needs the type of low level tuning for which C is so well suited. Because of this, large libraries and complex frameworks often bring the best advantage to the situation. The cost of coding in C/C++ vs. Java, Ruby, PHP, etc. is seldom worth any potential performance trade off if there even is one (Java, for example, compares very favorably to C/C++ in web server applications.)

Also, text processing is a major function of any web framework and this is an area where C is notoriously laborious in comparison with Perl, Python, Ruby, etc.

Answer 13

The problem with C++ is that it sucks at string handling, which is pretty much the only thing you do when working with web pages.

Then there is the fussiness of HTML and JavaScript. You can't just hit compile and have a good idea it is going to work, you have to keep tweaking the same page over and over again until it works on all browsers. Throwing in a lengthy compile cycle makes this all the more painful.

One of the reasons ASP.NET hasn't been completed crushed yet is that they learned from ASP, PHP, etc. and offer an interpreted mode.

Answer 14

Using C++ for non performance-critical websites is just like using a fork-lifter to drive in nails or taking an aircraft carrier for a fishing trip. It's completely overblown for the task although it's theoretically possible. The points you mention are all right and for larger projects, this could actually form an argument.

However, for most sites, even of medium size, this is completely irrelevant because there are more important concerns that are poorly addressed by C++. Apart from the fact that languages like C++ simply necessitate a lot of boilerplate code that make you write easily five to ten times the amount of code (!) for the same functionality and the overhead of build time (compilation, linking, depolyment, maintenance), C++ also lacks the appropriate libraries for web development. Languages like Python, Perl, PHP or Ruby are lightweight, easily deployed and offer great libraries for web development.

Answer 15

I have used three C++ web servers that, in different ways, allow you to write a C++ program that you can point a web browser at and see a web site generated by the program.

1. Wt This is a complex implementation which requires you know the Qt GUI coding system, but it seems complete.

2. Webio This allows you to build you website in HTML, then wrap it up inside your compiled program. The snag is it is based on a home-brewed web server which I find limited.

3. Webem This emphasizes simplicity and is based on boost::asio. I am the author of this project, so I will say no more here.

Answer 16

The primary things that a server-side web app does are:

• string handling
• string handling
• string handling.

That is:

• string handling: taking HTML templates and inserting data. C's functions for doing this suck. You're going to have to make a metalanguage inside C just to make this easy, or use a library. (You do know Java and Perl and nearly every other VM out there are all written in C and/or C++, right? Think about them as a convenient library for doing string manipulation.)

• string handling: taking user input, sanitising it, validating it, and using it to query data. Ever hear about injection attacks, XSS, or just stupid users? By taking the complex C code that you normally have to fret about and abstracting it utterly away, you can focus on security. Binding variables to your SQL queries will be easy, instead of a headache. Throwing input through regular expressions to sanitise it will be as easy as a few lines of code, instead of a couple dozen. And you won't need to worry about free()'ing it afterward.

• string handling: passing the inputs to the outputs usually isn't just a strcpy. There is usually a lot of manipulation - a lot of places to lose track of memory, and have a leak. VM's take care of this for you to allow you to really focus on the value you're providing your users instead of dickering around with slow memory leaks that require reboots of your daemon every day or three.

That's not to mention the sheer volume of CGI-handling modules / classes that already exist in these languages where they don't need to worry about memory or other arcane string handling.

All that this means is that C/C++ is not the ideal language for it. That doesn't mean you can't do it. It just means it'll be more work than a language that has taken care of some of the harder aspects.

Also, from my perspective, Java is just fine. It's a bit verbose for me, but it abstracts away memory and string-handling issues enough to be perfectly viable. And, if you check the market, you'll notice that it is more than viable - it's fairly popular.

As for speed - most of the heavy lifting is done in C anyway: my data is in DB2, I ask for it via SQL, which means DB2 does everything anyway. The overhead of perl (as that's my favourite implementation language at the moment) is minimal in this case.

EDIT: I should point out that you may be suffering from "premature optimisation syndrome." Have you benchmarked your non-C solution to see if performance really is that bad?

Answer 17

The BBCs Hitchhikers Guide to The Galaxy better known as h2g2, is written in C++.

The software named "DNA", after Douglas Adams who commisioned the first version, has been running for several years now and is quite sophisticated. So much so that most pages are written in a special markup language "GuideML" which is really an interpreted language anyway.

Why not stick with apache/php and concentrate on the site design? Shaving a few microseconds of each page request will never compensate for authoring a new page in minutes rather than days.