CppCMS – High Performance C++ Web Framework(cppcms.com) |
CppCMS – High Performance C++ Web Framework(cppcms.com) |
Who gives a flying fuck if this tool is the right one for whatever is your individual definition of web development? The fact is that someone had a need for a particular solution and they were kind enough to build it, document it, and show it off here for free. Turning your nose up at this based on language choice just makes you a close-minded fool.
Applications for this do in fact exist, and I'm quite pleased that the author was kind enough to post this.
On a past project I've had to write my own asynchronous web framework in C based on the wonderful libmicrohttpd. I decided on C because this was a resource limited device on which I was already using every available CPU cycle on a realtime computer vision algorithm and it all was just barely performing within acceptable limits. I needed as tiny a footprint as I could get.
I'm in the early stages of a different project which will probably face a similar situation, except on this massive concurrency will be key. I will absolutely be looking into CppCMS when the time comes.
I'm a fan of native code, and I use C++ at work and C and C++ on my personal projects. In my last job I was doing web work, writing PHP for Drupal sites. My reaction to CppCMS is just to note that it wouldn't necessarily be easy to create a faster CMS using C++ versus PHP. Drupal sites can be slow as dogs, but the reason has nothing to do with PHP per se. The Drupal codebase is extremely bloated and fairly inefficient in its design, but even worse are the modules that get piled on, and there can easily be well over 100 modules on a site. I've watched the database queries that come out from a real site and it was stunning and appalling to see the volume and the redundancy that occurs on a single page. I was also amazed by the sheer quantity of PHP that gets loaded and parsed (if you're not caching) on a single page. So that tells me that PHP is pretty fast to be able to support that enormous edifice of code. It's not a guarantee that C++ would make you faster than an interpreted language, because the work that goes into generating a webpage plays to the strengths of interpreted languages and away from C++: you'd have to be careful and think through how to handle lots of strings and memory management. A good garbage collector is said to be faster than malloc/new when churning through lots of memory, because it can amortize the work and run on a background thread. I think lots of little strings could especially become a problem unless you planned out a strategy for handling them efficiently. Also, as others have pointed out, a lot of the issues with making a website fast aren't about executing code on the cpu. It wouldn't necessarily be easy to beat something like node.js at handling requests asynchronously, for instance. That stuff can be hard to write. So, I think it would be a good idea to do even a very high performance site in an interpreted web language first, then decide cautiously if there's a way to make it faster by replacing some or all of it with hand-written C++.
But how common are those use-cases really? And why on earth would you want to worry about buffer overflows and memory leaks when you're already worrying about XSS and CSRF attacks?
As fast as modern Java is, it just seems unnecessary.
Have you written a line of code in modern C++? Know what RAII is? If you use C arrays and char*s in C++, that's your problem - the language provides idioms that are "as safe as" Java.
C++ gives you plenty of ways to go harm yourself, but unlike C they are pretty easy to work around. And the nice thing is that for the most part wrong code looks wrong.
If possible, try to make Go work. It's concurrency model is great for massive concurrency.
So why C/C++? When it comes to language choice I have a very simple rule: use whatever I think I can be most successful with.
Go prescribes a particular concurrency model. C and C++ do not. I have many years of experience wielding C to write very small, very fast programs that do very big things. I have zero years of experience with Go. Go would be interesting if I was writing something more general purpose or something that needed lots of extensibility, or something on which I plan to collaborate with people who don't have a lot of concurrent programming experience. None of those cases apply.
1) DB is often a bottleneck for web apps. Not always. But often. Very often. Optimizing pages rendering will improve the performance for pages that are already rendered pretty fast. It will do nothing for pages that are loaded slow due to DB access. A better/smarter cache will give you much bigger bang for the buck.
2) For the annual salary of a good C++ programmer (i.e. one who can write safe and readable code with STL and Boost), I can run 50 large AWS instances for a year.
3) Writing safe C++ code is hard. Even with STL and Boost you still have to understand the little details of objects ownership (see boost::shared_from_this<> as an example).
Overall, I would invest in distributed system with smart and efficient caching instead of trying to optimize single server performance. At the end, you will run out of the single box solution (if you are successful). Going from 1 server to 2 servers is really hard. Going from 10 to 100 is not too bad.
This is a belief that many C++ programmers have, and having spent much of my life in the past few years finding ways to break a C++-like memory model (Rust) I cannot emphasize enough how dangerously wrong it is. Safer than C, sure. As safe as a memory-safe language like Java, absolutely not.
The safety you mentioned comes from only two things: type safety and runtime array boundary checks.
There is no problem in implementing runtime boundary check in C++.
What else in C++ is less safe than in Java? Is there some kind of magic?
People relying too much on inteepreted or bytecode languages end up making abstraction on what happens on the metal, forget the basics of good enough performance, and bam, even the fastest server looks like a piece of garbage.
I'll always be conservative regarding language choices, because if a language makes things easier, it should also be taken with a grain of salt.
CppDB on the other hand is MIT or Boost. It is the best DB library I found so far for C++.
Actually LGPL is as 'free' as it gets with the GPL license family. If I wanted to be 'company unfriendly' I'd choose the AGPL.
But the thing is: Arguing about licenses is nonsense. The developer has an agenda and chooses the right license for it.
For me if I release open source I almost always license it under GPL3/AGPL because I don't want someone to take my code, stuff it into a closed system and make money of it. If I decide to contribute to the open source community I don't want leeches to profit from it.
If you want to use my code commercially: pay me.
2. It is long and complex license, not yet tested in court. Sometimes what constitutes a "derivative work" is not that clear.
3. Section 6 says all these can be changed anytime, potentially making it more restrictive (see GPL v3).
So from the business viewpoint it is better to find an alternative now than to potentially lose all the investment later.
And even if the company chose to open their source and distribute it, using dynamic linking allows them to choose any GPL-compatible license they like.
I don't see how it's "not company friendly."
[1]: See the end of the credit from SC2 HoTS
This is so dumb. Why it is called CppCMS then?
Quote from that page:
The original idea was: "Write your own CMS in C++".
The lead developer asked in 2008 for a better name but didn't get any suggestions, so the name stuck.
It was decided later to keep this name as it was already well known name and all the software around used cppcms as the namespace.
Something more web frameworks should do.
C/C++/etc are good for job intensive stuff that doesn't need fast maintenance cycle.
Dynamic language are good as web server because of their flexibility and their fast response time (In term of maintenance)
I wouldn't run an OS on Javascript and I wouldn't use C++ as a Javascript replacement in the browser.
Edited to add that they mention that this won't satisfy every use case, and also what use cases they think it does satisfy. http://cppcms.com/wikipp/en/page/when_to_use_cppcms
I'm pretty sure you just have wrong impression of C++, or to put it simply, you don't know C++.
In what way does C++ have worse response time in terms of maintenance? What do you mean exactly?
In general, statically typed compiled languages are better at refactoring than dynamically typed interpreted ones. Changing programs in the latter without fair test coverage means teetering on the brink of a catastrophe. Just recently I have seen an article on HN claiming unmaintainability of dynamic languages.
The truth is that every general purpose language is general purpose, and the claim about language suitability is a commonplace and an overgeneralization. You can do 3D games in JavaScript and client web apps in C++. Different languages have different drawbacks and that may limit their applications, but C++ is not targeted for OS development, and JavaScript is not targeted for web development, both are just general purpose languages.
Speaking of "low-levelness" of C++, with all the modern features and libraries it is as high level as other languages, and in some aspects is even more high level, e.g. JavaScript or Python have no corresponding means as the template metaprogramming which is the high high level. C++ just allows you to do low-level manipulations, you are not required to.
There are many myths and prejudices against C++ caused by ignorance and frustration of those who have not cracked it at a time.
I agree with your overall point — C++ may not be a good fit for web development, and there’s a lot to be said for being able to scale across multiple servers (and choice of platform will determine how quickly you have to solve that problem).
That said, my experience is that for most projects the performance bottleneck is the framework, not the DB. On big PHP projects, loading lots of code on every page load takes a huge amount of time, and many frameworks do things like parse multiple XML files on every request.
Similarly, Rails is slow… just take a look at how much time is spent outside of the database for a typical request. It’s crazy how long it takes, considering that most requests boil down to a DB query and then some string concatenation.
Another angle on his is the common pattern of having a bunch of app servers and just a few DB servers. That implies that the DB is not the main bottleneck.
Again, I agree with your overall thesis, I just have to disagree with the common wisdom that is point 1.
And the reason why you don't see a lot of DB servers is that it is HARD to scale DB by just adding servers (I am ignoring for a second non-SQL servers w/o joins as well as high-end Oracle and new MySQL-Galera solutions). An ACID compliant SQL DB is a single-server affair unless you invest heavily into the DB itself since it is really hard to run DB cluster even from pure operational standpoint.
Have you evaluated Code Synthesis's ODB?
https://github.com/allan-simon/tatowiki/
I've made a complete wiki engine (with also search engine integrated), which is easily skinable etc. (it's still at an early stage) , you can find an instance here http://en.baike.jisuanjiwenti.com/
You can check the line of code and the architecture of it, to have also developed with some PHP framework, I didn't find anything "weird" or to far from my old habit (and I do prefer compile-time check and possibility to run my server in gdb)
In order to help me create faster application with cppcms, I've started to create a framework upon cppcms here https://github.com/allan-simon/cppcms-skeleton
Even when using JRuby, for example, it's still running on a JVM that's very likely implemented using one or both of C and C++.
Don't forget that the major web servers and web browsers are all implemented in C and/or C++, or in one of the many scripting language or other runtime implementations implemented using C and/or C++.
And that's ignoring all of the other infrastructure, like server operating systems, router software, and so forth that's implemented using C, or C++, or both.
Every line of code executing in your non-C or non-C++ web development language of choice likely depends on many thousands of lines of C and C++ code, even as you malign them here.
I'm not arguing whether or not C++ is actually suitable for web development, I just don't think your line of argumentation makes sense.
It did a fine job at the time!
When you have load/concurrency that needs you to move to C++ there's no doubt C++ is right.
When you reach that level though, you will usually have the resource to build infrastructure specifically designed to your need, dismissing any "general" purpose C++ framework.
All the example mentioned here are using in-house products for the most part.
I agree completely with using whatever I can be most successful with line of thinking. This is why I try to learn as many languages as I can, so I have a good notion of what is the best tool for the job.
Whenever I think "loads of concurrency" I immidietly think about Erlang, Clojure or Go, as they have great concurrency models. Then again, you'll always be more productive in the language in which you have most experience, so to each his own I guess :)
CppDB uses MIT or BSD license (you pick), ODB is under LGPL or commercial license.
You could create a channel library that is "as good as" other libraries you'd see, except that they'd use C++ constructors/destructors and you might want a family of channel types depending on ownership semantics -- such as a single-producer single-consumer channel, versus a (less performant) channel with more shared ownership.
The state of existing actors or channels libraries is probably dismal. A channels library would need to be rolled together with a specific green threads system, and that's one of the advantages Go or other languages with a canonical green threads implementation has.
I just wanted to point out that I'm aware that it's a little funny to see fringe frameworks compared head-to-head with mainstreamers. But the charts are but one data point to consider in evaluating options. :)
Although it can be mitigated with specially written collections (incompatible with the standard collections) and strict coding guidelines, I have to agree with you that the C++ memory model itself is insanely dangerous.
It's absurd to claim that C and C++ aren't suitable for web development when a huge part of basically every web app today is written in one or both of them. They aren't just suitable for web development; they are critical for it.
In any non-trivial (jobs/money are on the line), web development != web programming. C/C++ is suitable for web programming, sure, but web DEVELOPMENT is an entirely different matter and is highly dependent on the availability of support, both community and professional, staff, and the competency threshold (or "learning curve") which is the knowledge you need to contribute meaningfully. The latter is one of the most important, especially since the vast majority of C/C++ programmers are not web developers, and doing something wrong in C++ is a lot easier than in memory managed, interpreted languages.
Most criticisms of C++ rely on outdated prejudices. Some people still think that modern C++ code is rife with pointers to void and reinterpret_casts.
It was a general statement aimed at a general framework. I said in some other place here that C++ is relevant but when it is, it's usually done via in-house library that are specific to your need.
All the example of company here using C++ use their own solution and most use C++/C/etc as a VM or code interpreter and uses another language for the logic.
Don't be offended because C++ doesn't do everything. For all I care, you code your server in C++. I'll code it in whatever I want and I'll sleep like a baby.
Static linking is fairly uncommon; it's more common to distribute the versions of DLLs you require on Windows, or use a package dependency on specific versions (or provide your own copies) of the system-provided libraries on Linux.
3. Section 6 says all these can be changed anytime, potentially making it more restrictive (see GPL v3).
Section 6 of LGPL3 does not say that; it says that you have the option of choosing a later version. Any code released under "GPLv2 or later" can still be used under GPL2.
These kinds of licenses are put in place so people can't create proprietary extensions/patches and fracture a community. Now, I'm not saying this is better than MIT, but at least deters people from that.
1. will only matter if you are distributing binaries to clients/customers, which generally isn't the case with a SaaS product.
GitHub started out as SaaS and now offers Enterprise product https://enterprise.github.com/
https://developers.facebook.com/blog/post/2010/02/02/hiphop-...
https://github.com/facebook/hiphop-php/wiki
https://www.facebook.com/notes/facebook-engineering/folly-th...
Edit: From the 1st link
"[...] I started my first piece of code transforming PHP into C++. The languages are fairly similar syntactically and C++ drastically outperforms PHP when it comes to both CPU and memory usage."
Also note that I referred to "the most widely used" implementations of those languages. Yes, we know that PyPy exists, but CPython is still used far, far more often. Yes, we know about Common Lisp implementations like those you listed, but the reality is that they basically aren't used in practice. PyPy, CMUCL and SBCL are essentially irrelevant when considering the big picture. C and C++ are involved in one way or another in pretty much every other case.
If you refer to the original post in this thread, you will see that it was about the supposed unsuitability of C++ for web development. When we look at the entire picture, however, we do see that such sentiment is quite wrong. C and C++ play an absolutely huge role in modern web development and web applications, regardless of what some people may think.
C++ is large and hard to master, but I don't think UB is the best reason to choose C over it.
I especially like the fact that you can specify which variables are captured by the closure: http://www.cprogramming.com/c++11/c++11-lambda-closures.html
I use both C++ and Scala on daily basis and there are just a few things I wish C++ had from Scala. On the other hand it is a huge time saver not having to worry about the JVM GC freeze.
(Edit: it is also worth pointing out that the motivation for this tool is to avoid having to write C++ code)
C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job.
While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.
Java doesn't have Undefined Behaviour, buffer overflows, or memory leaks (not completely true, I'm not counting space leaks here but I hear it's possible to introduce a memory leak by writing a faulty class loader).
While C++ does provide idioms for writing safe code, C++ can't remove them, which means you will always have to worry about it. Sometimes the problem isn't actually your code, but the library you're using, which is the case at my job, which again made me miss a safer language :(
How do other languages solve this problem?
> or memory leaks when you need an object to live beyond the current scope.
Have you ever heard about smart pointers? They take most pain from dealing with pointers. Managing circular references remains a bit complex though.
Reading or writing past the allocated parts of a buffer is treated as a runtime error, wheras in C/C++ you just end up with corrupted memory.
> Have you ever heard about smart pointers?
Ahh, completely forgot about these. You're right, they're great.
Sadly it's not that cut and dried. I've written a mail-client in C++, with an embedded Lua intepreter for the scripting. Guess what the Lua API wants to use?
There are many many situations where you need to integrate with libraries that only present C-bindings, and that gives you a lot of constraints.
(Though I admit I was pleased with the C++ API of libmimetic, the MIME-library.)
C arrays and pointers can still be used on the stack, and are sometimes simply the right tool for the job.
While RAII greatly reduces memory leaks and enhances resource-management, it doesn't save you in all cases, which means there still is an overhead and you will still have to worry about it.
No one asked you to. I don't like Eclipse that much personally, but I did not go to their page and say "Hey, you know what, I hate Java so your product sucks!". (I have deep respect for Java and the Java community, BTW). But frankly, as someone who has not written a line of code in C++ - however bad it may be - you're not really qualified enough to preach the world about its utility.
> I'll buy your "modern C++ is safe" argument if you buy my "modern Java is fast" argument.
Yes, the JVM is an engineering marvel - we all know that! What we also know is that it is adept at hogging all resources you might have(unless you learn how to use those bazillion -X<options>) - so no, thanks. I prefer compiling to native code and having total control, and in cases I don't want all that, I might just stick to Go or Python.
I'm kind of skeptical, to be honest. I suspect a simple, unoptimized C++ application wouldn't have a lot of problems keeping up with a highly optimized PHP framework. Interpreters do so much extra work.
Not that I would use C++ for web stuff- that's 99% string munging, and string munging in C++ is how you wind up with your desperate last words mockingly quoted on seclists.org.
Even counting that, the comparison is also not necessarily correct. In some cases, perhaps the C++ code would have taken 0.1s, where the ruby code takes 5s. In fact, 50x is about the slowdown you used to see for ruby in the programming languages shootout, and it is still pretty bad. [1]
[1] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
Most queries in most projects are cheap.
On the other hand, frameworks that have ORMs and other DB abstraction layers often make trade a little bit of DB time (and developer time) for a lot of framework time.
And as you say, scaling the DB is a lot harder than scaling the app servers (typically) — the implication being that trading framework performance for developer time makes a lot of sense.
As with any technology, ORM is just a tool. Used wisely it works great. Used it w/o understanding of what you are doing - you get a recipe for disaster.
"Most queries in most projects are cheap" is the true assumption for small projects. When you cross certain threshold, none of the non-cached queries are cheap (by non-caching I mean caching in all layers including the DB itself).
And I strongly disagree with "trading framework performance for developer time makes a lot of sense". In 99% of cases you DON'T care about performance. Yet, a "bad" framework adds penalty in 100% of cases. I strongly prefer to have a good-enough performance from the framework and then focus on this 1% of cases when it matters (and in majority of cases, it's the DB, not the app code).
On the other hand I try to avoid GPL/LGPL for components.
Here is a scenario:
1. Invest in developing your app based on CppCMS
2. It takes off, great - buy commercial license.
3. The next version of LGPL gets more restrictive, you're stuck with commercial license.
4. Artyom gets hired by Google/Apple, no time for CppCMS anymore; only the LGPL fork gets fixes from now on.
5. Throw away your investment (time and money), start learning something else - how cool is that?
The LGPL only requires that binary distributions of the derivative work have source reasonably available and that the library can be switched for another version by an end-user.
OK but so what? It is also years ahead of BF.
C++11 has a few nice features, but it is really dragged down by low level issues. You talk about garbage collection like it is a problem, but C++ still does not even offer good garbage collection (not even optional garbage collection) for those situations where it makes sense. At least with Java you do not need to manually break cyclic references to prevent memory leaks.
As for closures, why would I want to specify which variables are captured? If I reference a variable from the enclosing environment, I capture it. If I mask the variable, I do not capture it. What point is there in explicitly declaring this? Frankly, the entire C++11 approach to closures is insane. Why add the extra syntax to explicitly declare how variables are captured, when capture by value covers all cases?
I stand by what I said. C++ is an awful language.
BTW, Normally you should avoid "new" and "delete", only very special use cases need it.
Specifying the closure variables is optional and it is both for performance and encapsulation. You can specify "nothing", "everything by reference", "everything with copy", just some by copy or reference - mix & match. If this is too much to start with then just copy everything with [=] and clean it up later if it turns out to be a bottleneck. The point is: you can save on cycles if you want to/have to.
If you think C++ is not a match for you, that's OK, there are plenty other languages. You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...
This is kind of like saying, "x86 has CALL, PUSH, and POP operations, so there is no need for a language with subroutines! Just use inline assembly!" Garbage collectors are not strictly needed in any imperative language. The point of garbage collection is to enable programmers to think at a high level, without having to divert their attention to low-level issues.
"Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect."
Move semantics are a solution to an artificial problem. Sensible defaults like allocating objects on the heap and using references everywhere would have solved this problem and many others. Yes, I know that the C++ approach to programming is supposed to give programmers the power to do things for themselves, but that does not mean that the default semantics have to be brain-damaged. If code like this:
std::vector<int> vec;
"Specifying the closure variables is optional and it is both for performance and encapsulation"
I am not seeing how it makes sense for either. Specifying anything about how variables are captured is a pointless exercise. Variables should just be captured if they are not shadowed, and they should always be captured as copies. When programmers need to capture by reference, they should just create a reference and capture that. Introducing another syntax just to declare how variables should be captured, and then making another nonsensical default behavior (no capture at all), is just silly.
"You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server"
You know, it is not a very strong argument when the top result (in C++) is only marginally faster than the next best (in Java). The fact that another C++ framework happens to be much further down, below systems written in Java, Scala, PHP, and Lua, is also not helping you. If anything, that test shows that the cost of using a high level language is not so bad; fantastic performance can be achieved without having to fumble around at a low level, and low level languages like C++ are not a guarantee of good performance.
Bad engineers blame their tools.
C#: http://conversations.nokia.com/2012/06/01/interview-with-mat...
Ruby: https://blog.twitter.com/2011/building-faster-ruby-garbage-c... (It was not good enough, they dumped Ruby)
Accepted answer? "Manual tracking of objects" http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...
Google has 14 million web pages about Garbage Collector issues...
See section 9 http://www.joelonsoftware.com/articles/fog0000000043.html
Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?
I guess you also roll your own crypto and implement stuff in assembler “for performance”?
"We find that in regards to performance, C++ wins out by a large margin. [...] Scala concise notation and powerful language features allowed for the best optimization of code complexity."
https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...
Sometimes you need performance or there are other constraints, in which case your choice of language is very limited.
Automated memory management works, but not all the time. And how about other resources? How you make sure your mutex gets released? Add a comment "please don't forget to release this one"? How about file handle, temporary file, serial port, DMA, GPU, network port and other limited resources?
BTW, I think most of the brightest minds you mention use C or C++ on daily basis. :)
[citation needed]
"BTW, I think most of the brightest minds you mention use C or C++ on daily basis"
I doubt it. Most of the brightest minds I have met, at least in academia, use high-level languages: Python, OCaml, Lisp, Haskell, etc. They have more important things to worry about than whether or not it is safe to deallocate objects.
Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?
All the operating systems (Linux, Windows, Mac, iOS, Android), most of the desktop apps (Office, Photoshop), programming languages (PHP, Ruby, JavaScript, Python, both Sun and IBM JVMs), browsers (IE, Chrome, Firefox), web servers (Apache, nginx), database (Oracle, MS SQL, mySQL, Postgres, Redis, MongoDB), Google's search engine, eBay, Bing, Facebook, most of the games, embedded medical devices etc.
Yeah, and we are plagued by the bugs and security problems made possible by those languages. Imagine how much more we could be doing if programmers were not spending hours trying to figure out where a dangling pointer was created.
Really, the popularity of C, C++, and related languages has little to do with the languages themselves. C became popular because of Unix, not because of its technical features, and Unix became popular because of its licensing. C++ became popular because of Windows, not because of its technical features; Windows became popular because of the Unix Wars and because of MS Office. If Unix had been written in Lisp or ML, we would be talking about how popular Lisp or ML are. For what it's worth, entire operating systems were written in Lisp at one time; their failure had nothing to do with their technical merits and everything to do with terrible marketing and bad predictions.
If you want to talk about how fantastic C or C++ is, try pointing to an overwhelming success story that could not have happened without the language. Altran Praxis has the lowest bug rate in the industry; they credit the SPARK programming language, which is well-suited to the formal verification techniques they rely on. The military planning system DART paid both its own development costs and several decades of research that led up to it; it was thrown together in a few weeks using Lisp. I have yet to hear that kind of success story from C++ programmers; the only thing I ever seem to hear about are squeezing a few extra clock cycles out.
If this were a popularity contest, we would still be hand-rolling assembly language. The same reasons that led programmers to use compiled languages apply to switching away from low-level languages like C and C++. Sure, people are still writing assembly language, but it is a niche. That is where C and C++ should be: a niche, mostly just for maintaining legacy code that is too expensive to rewrite in a better language.
So there are some anecdotal stuff nobody actually seen, but it will change the word anytime now.
Don't hold your breath: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...