Bring it on! You C++ web developers are cut from raw brass, and you have more guts than I. Nevertheless, I would love to see Wt added to our project [1]. Any follow-up on that?
Whats with the recent slew of c++ based web app libs? could it be that in round 6 of the techempower benchmarks, cpp basically won every in category raising interest in it for web stuff?
I suspected the same thing. People found that their favorite popular language was at the bottom of the list, and naturally they're curious about frameworks for the faster languages. Exploration is healthy, but realize C/C++ does not have the friendly, extensive and reliable web developer ecosystem that Ruby/JavaScript/Python/PHP has. If you want an in-between, check out Lua/OpenResty/Lapis.
It looked as if a sort of a snowball effect occurred on the HN "new" page this afternoon. I laughed when I saw the third show up (see comment below).
I personally could never stomach doing web development on C or C++. The C++ source code to the CPoll-cppsp test [1] makes me cringe in fear (no offense, xaxaxa!) But if there are those willing to give it an honest go, I'm not going to criticize them. Caution them, as you have, that it may be a frustrating exercise? Sure.
That said, I think modern Java, Go, Scala, Erlang, Haskell, and Lua are all worth considering.
Some people like C++. I think it probably has a connection to the techempower benchmarks but I've gone looking around at different C++ frameworks for use in my yet-to-be-made home page. I work day in and day out these days in Perl, C#, JS, and Objective C. Sometimes it's nice to take a step back to my C++ roots.
It is great as a hobby project to try and right a C++ web framework but the reality is that in 2013 it would be laughable at best and outright fireable at worst to write web apps in C++. You might have legacy reasons or have some portions of the code that are very performance sensitive and you can augment your non-C++ app with C++ code for those reasons - that would be understandable. But a full fledged C++ web app - tsk tsk. Let's see -
1) Programmer availability and economics. Ton of RoR/PHP/Java and hopefully soon Go programmers, but good C++ programmers - good luck finding and retaining one.
2) Security - However competent YOU are - it just isn't possible to write a complex web facing system that is also secure. I was part of a failed project to write an IdM system in C++. It was a huge pain when we hired a external org to do Penetration Testing. After they were done we were left with lot of damage. Part of this is language, part is a lack of lot of great framework/best practices/expertise.
3) You reinvent the wheel a lot. Want to talk to LDAP - write your own load balancing and failover aware C++ classes or maintain somebody's unsupported OSS one. Equally headachy. Or pay for RogueWave - a ton of money per platform plus annual support contracts.
4) Cross Platform Pain - Enough said. Take the myriad of compilers, linkers, versioned libraries and try to ship a product that supports plugin based extendibility. Tough job convincing the customers to use the same compiler/linker/libraries to build their plugins.
5) Performance monitoring, debugging and profiling tools. See how well those compare against Java's JMX, HPROF, Heap dumps with OQL, MAT, YourKit etc. Just no match unless you are extremely competent and can manage debugging complex production systems without these tools.
6) Lack of something like a widely used Application Server ala Weblogic, JBoss. The value these provide in terms of ready clustering, db access, thread pooling - that's just not easily doable in C++. Add the lack of various 3rd party frameworks (ORM, Rules engines etc.) and you are ready to give up on C++.
Now I am sure somebody will go clever and come up with solutions for each of the above but the point is when you pull all of them together - it's not hard to realize it won't be worth it.
Did you actualy even look at the framework, or just immediately drew conclusions and wrote this as soon as you saw the combination "C++" and "Web Toolkit"?
I actually downloaded, installed and ran an example app - but from the other C++ Web toolkit that was on front page - CppCms. I was meaning to add this comment to that post but in between multiple open tabs, I ended up adding it on this one instead!
But which one of my points are not applicable to this particular toolkit? Sure it seems to provide XSS protection and such but the fundamental issues with secure coding in C++ still remain. So do the points about cross platform pain, compiler/library versioning issues, reinventing the wheel, availability of debugging/performance monitoring/profiling tools.
Oh, I wasn't trying to refute your points - it's outside of my area of expertise and they may very well be correct - but your style of writing gave a strong impression you were criticising the framework without even taking a closer look at it, which I wouldn't consider a proper way to criticise something or start a discussion.
Did you try the example app on Firefox ?
I tried some of the examples, on Chrome, Opera and Firefox,
on http://127.0.0.1:8080/ , the 2 first browsers works fine but on Firefox all I see is a blank page.
it turns out that there are some perfectly reasonable use cases for a c++ web framework.
The fact you didn't take the time to find out what they might be, before expressing an opinion about the framework, is unfortunate.
Come on, if we are having this conversation and you've already taken the pains to add a contrary comment - I was fully expecting you will elaborate on those use cases :) Are you thinking embedded web servers may be? What else?
I was hoping to leave discovery as an exercise for the reader :)
but yup, low memory/cpu/ram situations are one clear place where a c++ web app makes a heap of sense.
Also things like routers, where there is an environment that doesn't change frequently (..or often at all for years..).
There is also a bunch of use cases where the fact that installing/replacing/updating the web app is as simple as replacing a single binary is a real win.
There just are a bunch of places where it makes perfect sense to use a c++ web app, and none at all to use frameworks like RoR.
Its not a big deal, there are entire worlds of requirements and use cases that look and sound nothing like 'public facing web application', where the ability to provide an HTML interface is a win, and the ability to lower resource requirements from something like RoR is a win.
The only reason I posted is that it just makes me sad when people are so utterly oblivious to the worlds that they dont know, and - because of that - are tracked into making definitive statements about things, when they should probably preface their comments with "to my knowledge..." or "Im not aware of" or even preface it with a genuine question "why is something like this useful?, I dont understand.."
There is nothing wrong with admitting you do not understand something and asking for clarification :)
>There is nothing wrong with admitting you do not understand something and asking for clarification
To be frank, that's not something I don't understand. It's just a resource constrained environment use case that anyone can understand. What I don't understand is how common those use cases are today given my home router runs with 32Mb RAM and can use PHP instead of C++, never mind the fact that it doesn't need a full fledged C++ Web Framework to begin with!
its not just resource constrained environments, but use cases where the advantages of a c++ web app outweigh the disadvantages.
C++ web apps are fast. They are low memory usage (especially compared to solutions like java/RoR or PHP). They tend to use little cpu.
Ultimately, once a little ground work is done, you are still designing the interface in html, javascript and css, and have all the advantages and speed of development of that delivery method.
For some definition of the word, I believe that Facebook is effectively deploying a c++ web app as part of its solution at this point.
There are many use cases for which RoR or PHP is the better solution, but it turns out it is imply true that there are others for which a c++ web app is the better solution.
Since any web-framework should be mostly IO-driven, the actual speed of the code matters very little as it will in most cases always be nothing compared to the actual IO-operation itself :/ In case you need certain code to run very fast, most people will write that in C/C++ and patch it into their solution, that's what we did in the Django-workshop I used to work in.
I thought Facebook mostly used C++ for their PHP VM? Facebook itself is alot of PHP, they also use Cassandra (Java DB) for inbox messages I believe.
No -- Facebook's PHP code is translated to C++ by HipHop and compiled into a monolithic binary, and Cassandra has largely been deprecated in favor of HBase.
"Facebook uses hphpi (and now hhvm) for day-to-day software development, but uses the HipHop compiler (hphpc) to create optimized binaries that serve the Facebook website. hphpc is in essence a traditional static compiler that converts PHP→AST→C++→x64."
So if that's how you feel, you use JWt ( http://www.webtoolkit.eu/jwt/ ) instead of Wt. Same thing, different language. JWt is a native port of Wt to Java, not a set of jni bindings.
I know of someone who switched to cpp with wt because the java code he first developped to generate a pdf out of a big database ran out of memory after minutes of work. The cpp code generates the pdf in a second. Not everyone‘s situation, but this is an example, on a server, where efficient resource utilisation is important.
Also, did you see wt is widget oriented and has a java version, which you can use with jruby if you want?
Just sounds like a mis-use of Java. Java is slower than C++, but it's a fairly small difference, ie. between 1x and 3x the speed. So if the cpp code did the work in a second, the Java version should have taken at most 3 seconds.
The real reason for the difference is that the rewrite into C++ used all of the domain knowledge he had acquired in writing the Java version. If he has made a Ruby version next, it would likely have been similarly efficient (maybe 5 secs? Who knows).
It's a key problem in these kind of anecdotes: a rewrite will nearly always be more efficient as it has more knowledge to work with during the architecture phase of the project.
From what i know the code was quite simple and even trivial, using existing java libraries as much as possible. The fact is that using corresponding cpp libraries let him get what he needed with much less fuss. I do not know why the java version was so inefficient and used all memory,it might be due to one ofnthe librariez, but this is illustrating an example where cpp was relevant , which was the point of my comment.
And if he now rewrote the code in Scala using even better domain knowledge and it ran in 0.1 seconds, would this be proof to you that C++ isn't relevant after all?
The point of my comment is that your basis is flawed. The apples to chimpanzees reasoning you are using is not valid.
If you run out of memory you're just not doing it right. C++ uses less memory than Java, this is true. But if using the same algorithm in C++ with a larger database, generating a bigger PDF perhaps, you will still fail. Could also be that just increasing the managed heap will help, but I guess this is a case about keeping to much in memory.
I understand the intent. However, out of memory exceptions usually mean wrongful use of libraries, or poor quality of said libraries. It doesn't make C++ more or less usefull than Java for a particular task, as the exact same code in C++ would lead to the same result, altough it would take longer for C++ to get there.
We agree. The fact is that the java libs blew, and not the cpp libs. Making the decision to develop the solution in cpp the right one, contradicting the top comment of this thread.
No we still disagree. A poor library, or poor use of said library, is not a reason to use an entirely diffrent language. It's a reason to use a diffrent library or fix your code.
I am a C++ programmer that agrees with most of what you say except:
5) Performance monitoring, debugging and profiling tools. See how well those compare against Java's JMX, HPROF, Heap dumps with OQL, MAT, YourKit etc. Just no match unless you are extremely competent and can manage debugging complex production systems without these tools.
I find the C++ tools much better than the Java ones. I was recently tracking down memory use with a C++ client and a Java server (with help from a Java programmer).
I found VisualVM kind of pretty but mostly useless for finding the source of memory use but with C++/valgrind/massif I got the guilty data structure and the calling function on the client side in a few minutes.
Haven't used valgrind, but wouldn't you say this is mostly related to Java/JVM-languages being garbage collected? Since analyzing heavy memory use requires you to look at a lot of garbage as well. Forcing a gc does help, but not enough in my oppinion
I bet you can't use Valgrind on Production C++ Server though. You are also limited to the platforms Valgrind runs on. There have been plenty of times I used Xeprof (HPUX) on Java server to profile CPU usage, GC logging parsed by JMeter, on demand heap dumps (MAT) - all in Production to successfully resolve issues. (Browsing the heap dump will tell you exactly where your memory is - duplicated String Buffers, leaked objects etc.)
The point is JVM tooling has matured enough that you have plenty of choices - you'll find something that works well even for production uses.
I think it looks really neat. It abstracts away all that DOM/JS/HTML crap so you can write a web app like a program instead of the weird hybrid "document with programatic elements" model that seems to have evolved on the web as an accident of history.
The use of C++ is a little questionable, but the nice thing about C++ is that you can create bindings to other languages reasonably easily. I would have preferred to see it in pure C to make it easier to write bindings for, but I can see why they chose C++.
So, you're number one is about the availability of mediocre programmers, is that you're argument, just so I understand it properly? I think that's the direct implication here, that you have an enormous pool of less technical people to perform some sort of Mythical Man-Month body shopping program with ... That's fine but that's not an argument against doing web programming with C++. That's sort of a whiny "I can't find monkeys to code at $9/hr on C++ so I'm not using it," which is not very interesting. Some people prefer competent programmers, whether the development is done in PHP, RoR, or whatever; I know I would find it pretty boring to work with people scared of C++.
As well, most of the other arguments are a bit hard to take seriously .. In #1 you talk about RoR and PHP but now in #6 you want me to pay Oracle or RedHat for these EE application containers and imply that without such containers we have big problems ... I mean, which one is it? As for connecting to LDAP and all these myriad of other things which you seem to being mistakenly thinking are unconnectable from C++, leave alone the fact that most of these services you aspire to integrate with were, themselves written in C or C++, do you really think that you connect to these things with PHP and not C++? I find that to be pretty interesting ... maybe even worthy of a "citation needed]."
For #4, so is everyone on here that does Web development, shipping products in binary form? Really, is the Web portal that you work on for ConAgra foods or whatever a product you shipping and selling? So, what you're saying is JBoss and all these others you want perform swimmingly well in a "cross platform" environment ... really, is that really you're argument? I think that's a fantasy. I think you're lobbing a lot of inconsistent criticisms all over the place against native programming.
By the way, people build, deploy, and manage complex native applications all over the world without Java or the JVM. It's a real thing, I promise.
Not everyone is making employee portals for the DMV or whatever projects your talking about ...
That licensing (GPLv2 & commercial) is pretty permissive. It's open-source. They didn't even pick the AGPL, so you probably don't even have to share your source code if you're feeling selfish and running your / your business's own web app. (But seriously, share. Being open source boosts your reputation even if you don't actually care about paying it forward.)
50 comments
[ 3.0 ms ] story [ 71.1 ms ] thread[1] http://www.marshut.com/kvuyp/is-someone-interested-in-cppcms...
I personally could never stomach doing web development on C or C++. The C++ source code to the CPoll-cppsp test [1] makes me cringe in fear (no offense, xaxaxa!) But if there are those willing to give it an honest go, I'm not going to criticize them. Caution them, as you have, that it may be a frustrating exercise? Sure.
That said, I think modern Java, Go, Scala, Erlang, Haskell, and Lua are all worth considering.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
Still, C++ is not my particular cup of tea. That doesn't diminish my desire to see Wt and CppCMS added to our benchmark suite, though.
1) Programmer availability and economics. Ton of RoR/PHP/Java and hopefully soon Go programmers, but good C++ programmers - good luck finding and retaining one.
2) Security - However competent YOU are - it just isn't possible to write a complex web facing system that is also secure. I was part of a failed project to write an IdM system in C++. It was a huge pain when we hired a external org to do Penetration Testing. After they were done we were left with lot of damage. Part of this is language, part is a lack of lot of great framework/best practices/expertise.
3) You reinvent the wheel a lot. Want to talk to LDAP - write your own load balancing and failover aware C++ classes or maintain somebody's unsupported OSS one. Equally headachy. Or pay for RogueWave - a ton of money per platform plus annual support contracts.
4) Cross Platform Pain - Enough said. Take the myriad of compilers, linkers, versioned libraries and try to ship a product that supports plugin based extendibility. Tough job convincing the customers to use the same compiler/linker/libraries to build their plugins.
5) Performance monitoring, debugging and profiling tools. See how well those compare against Java's JMX, HPROF, Heap dumps with OQL, MAT, YourKit etc. Just no match unless you are extremely competent and can manage debugging complex production systems without these tools.
6) Lack of something like a widely used Application Server ala Weblogic, JBoss. The value these provide in terms of ready clustering, db access, thread pooling - that's just not easily doable in C++. Add the lack of various 3rd party frameworks (ORM, Rules engines etc.) and you are ready to give up on C++.
Now I am sure somebody will go clever and come up with solutions for each of the above but the point is when you pull all of them together - it's not hard to realize it won't be worth it.
But which one of my points are not applicable to this particular toolkit? Sure it seems to provide XSS protection and such but the fundamental issues with secure coding in C++ still remain. So do the points about cross platform pain, compiler/library versioning issues, reinventing the wheel, availability of debugging/performance monitoring/profiling tools.
I don't have anything material; he's spot on.
but yup, low memory/cpu/ram situations are one clear place where a c++ web app makes a heap of sense.
Also things like routers, where there is an environment that doesn't change frequently (..or often at all for years..).
There is also a bunch of use cases where the fact that installing/replacing/updating the web app is as simple as replacing a single binary is a real win.
There just are a bunch of places where it makes perfect sense to use a c++ web app, and none at all to use frameworks like RoR.
Its not a big deal, there are entire worlds of requirements and use cases that look and sound nothing like 'public facing web application', where the ability to provide an HTML interface is a win, and the ability to lower resource requirements from something like RoR is a win.
The only reason I posted is that it just makes me sad when people are so utterly oblivious to the worlds that they dont know, and - because of that - are tracked into making definitive statements about things, when they should probably preface their comments with "to my knowledge..." or "Im not aware of" or even preface it with a genuine question "why is something like this useful?, I dont understand.."
There is nothing wrong with admitting you do not understand something and asking for clarification :)
To be frank, that's not something I don't understand. It's just a resource constrained environment use case that anyone can understand. What I don't understand is how common those use cases are today given my home router runs with 32Mb RAM and can use PHP instead of C++, never mind the fact that it doesn't need a full fledged C++ Web Framework to begin with!
For some definition of the word, I believe that Facebook is effectively deploying a c++ web app as part of its solution at this point.
There are many use cases for which RoR or PHP is the better solution, but it turns out it is imply true that there are others for which a c++ web app is the better solution.
Go figure :)
I thought Facebook mostly used C++ for their PHP VM? Facebook itself is alot of PHP, they also use Cassandra (Java DB) for inbox messages I believe.
Didn't know they switched to HBase, it's still Java though.
"Facebook uses hphpi (and now hhvm) for day-to-day software development, but uses the HipHop compiler (hphpc) to create optimized binaries that serve the Facebook website. hphpc is in essence a traditional static compiler that converts PHP→AST→C++→x64."
According to wikipedia: http://en.wikipedia.org/wiki/HipHop_for_PHP
"in Q1 2013, the production version of facebook.com started running on HHVM, replacing HPHPc."
I wonder how well silverstripe runs on it....
C++ is a tool just like any other language. It is not the answer for every question, but it is pretty good.
Some companies use it heavily and they are pretty successful: Google, Microsoft, Oracle, Facebook, OKCupid etc. So C++ is useful, even for Web.
BTW, it is used to implement PHP, Java Virtual Machine, Ruby, Windows and so on - that went reasonably well too.
Also, did you see wt is widget oriented and has a java version, which you can use with jruby if you want?
The real reason for the difference is that the rewrite into C++ used all of the domain knowledge he had acquired in writing the Java version. If he has made a Ruby version next, it would likely have been similarly efficient (maybe 5 secs? Who knows).
It's a key problem in these kind of anecdotes: a rewrite will nearly always be more efficient as it has more knowledge to work with during the architecture phase of the project.
The point of my comment is that your basis is flawed. The apples to chimpanzees reasoning you are using is not valid.
5) Performance monitoring, debugging and profiling tools. See how well those compare against Java's JMX, HPROF, Heap dumps with OQL, MAT, YourKit etc. Just no match unless you are extremely competent and can manage debugging complex production systems without these tools.
I find the C++ tools much better than the Java ones. I was recently tracking down memory use with a C++ client and a Java server (with help from a Java programmer).
I found VisualVM kind of pretty but mostly useless for finding the source of memory use but with C++/valgrind/massif I got the guilty data structure and the calling function on the client side in a few minutes.
The point is JVM tooling has matured enough that you have plenty of choices - you'll find something that works well even for production uses.
The use of C++ is a little questionable, but the nice thing about C++ is that you can create bindings to other languages reasonably easily. I would have preferred to see it in pure C to make it easier to write bindings for, but I can see why they chose C++.
As well, most of the other arguments are a bit hard to take seriously .. In #1 you talk about RoR and PHP but now in #6 you want me to pay Oracle or RedHat for these EE application containers and imply that without such containers we have big problems ... I mean, which one is it? As for connecting to LDAP and all these myriad of other things which you seem to being mistakenly thinking are unconnectable from C++, leave alone the fact that most of these services you aspire to integrate with were, themselves written in C or C++, do you really think that you connect to these things with PHP and not C++? I find that to be pretty interesting ... maybe even worthy of a "citation needed]."
For #4, so is everyone on here that does Web development, shipping products in binary form? Really, is the Web portal that you work on for ConAgra foods or whatever a product you shipping and selling? So, what you're saying is JBoss and all these others you want perform swimmingly well in a "cross platform" environment ... really, is that really you're argument? I think that's a fantasy. I think you're lobbing a lot of inconsistent criticisms all over the place against native programming.
By the way, people build, deploy, and manage complex native applications all over the world without Java or the JVM. It's a real thing, I promise.
Not everyone is making employee portals for the DMV or whatever projects your talking about ...
http://www.webtoolkit.eu/wt/download
(The commercial license doesn't allow private modifications, though it does give a perpetual license. Perhaps it could use some improvement if they want to make more sales. http://www.webtoolkit.eu/wt/license/Wt%20License%20Agreement... )