not quite the same thing, but a few years ago i built a library that would print test results to a web framework (can dynamically add graphs, tests, analytics, etc)
Not doing us any favours there, at all. C++ is crying out for a bit of 'hip' and there's really no reason, with C++11 now pretty ubiquitous, we can't have some Sinatra-inspired frameworks.
What is it that really holds C++ back from being a solid choice for web frameworks?
What is it that really holds C++ back from being a solid choice for web frameworks?
Its verbosity. I'll wager that it'll be a long time before a C++ web developer will be able to write faster code than an equally competent Python, Ruby, Haskell, or Clojure web developer.
The CppCMS blog implementation, according to CLOC, is about 3,200 lines. It supports comments, markdown, multiple database backends, LaTeX formulae, CAPTCHAs, caching, RSS feeds, and has an admin interface. That's a pretty dense result for an MVC framework without any magic.
And how do you account for PHP? Oodles of documentation, fast iteration, and swaths of libraries out of the box seem to have trumped basically every other concern, including its absurd verbosity.
Backend languages don't and shouldn't matter, especially when most webdev backend is no more sophisticated than your average CLI and you're probably going to end up spending most of your time dicking with CSS and HTML anyway. You could probably count equivalent productivity lost in tens of thousands of lines of C++, just scanning the dizzying array of loonybin.js frameworks for frontend work.
I'd gleefully do any backend job in C++ if it meant someone else handing me the database schema and the frontend ready to go.
It seems (to me) like if statically typed, compiled languages are your bag, and you want to create web applications, Go is the right choice.
I recently finished the MVP for a weekend side project in Go, and I had a lot of fun (coming from a Node.js/Ruby background). I finally understood the draw of static typing (the compiler saved me a ton of time), but I didn't feel limited by the type system, nor encumbered by the syntax. The performance boost was also quite nice (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison). It's hard to imagine needing even more performance, since the Node version still would have been "good enough", and needing it so badly that it'd be worth muddling through C++ to get it (especially given the stark contrast of managing concurrency in Go vs C++).
I don't know much about Haskell but I suppose it would work as well. I just took an example of a statically typed, compiled language with which I'm familiar and which seems to have a decent amount of momentum.
> (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison)
You're probably not doing it right. You should see a factor 10 or more difference, without optimization. Why ? Because any variable lookup in a dynamic language is always at least O(log N), and the mere fact that it needs looking up at all costs you a lot. So every single statement and expression of a compiled language is going to blow the socks off any interpreted language.
I'm not a fan of dynamic typing, nor am I a compiler expert, but I'm pretty sure this is wrong for (at least) JS engines, which are JIT-compiled down to static machine code and which use automatic type deduction. Only when types on existing variables change all the time it would be a performance problem. If JS code is 10x slower then it's native equivalent it's probably because some slow-path is hit (too many objects created and destroyed, burdening the garbage collector, or too "dynamic code" which causes many recompiles at runtime, or code not to be compiled at all but running through the interpreter..).
Are you saying I should have seen more of a difference than I actually did? Maybe I was doing it wrong, but I said it makes Node's performance look "mediocre" rather than "bad" because Node is still pretty damn fast compared to the rest of the field (also, I like Node.js a lot and use it daily).
Also, this was by no means a scientific benchmark - it wasn't a comparison of raw ops/sec, or anything like that: just the requests/sec on a few different routes (pretty close as far as implementation logic). I'm sure the chosen frameworks played into the results as well, but I'd consider that a more pragmatic benchmark anyways.
A friend of mine is recently writing C++ web framework similar to Python Flask.
It has many interesting features like compile-time routing URL parameter checking, easy and fast (probably fastest among C++ json libs) json implementation by taking full advantage of C++11.
If interested, take look of following code and repository:
18 comments
[ 4.2 ms ] story [ 37.0 ms ] threadRan an example where i find the pupil of an eye: http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html
srv.applications_pool().mount(cppcms::applications_factory<WebSite>());
Not doing us any favours there, at all. C++ is crying out for a bit of 'hip' and there's really no reason, with C++11 now pretty ubiquitous, we can't have some Sinatra-inspired frameworks.
What is it that really holds C++ back from being a solid choice for web frameworks?
It is?
> What is it that really holds C++ back from being a solid choice for web frameworks?
Language wise? Not much. It's more of a library and culture "problem". There's no inherent reason why C++ can't be used for web frameworks.
But that'll never happen.
Its verbosity. I'll wager that it'll be a long time before a C++ web developer will be able to write faster code than an equally competent Python, Ruby, Haskell, or Clojure web developer.
And how do you account for PHP? Oodles of documentation, fast iteration, and swaths of libraries out of the box seem to have trumped basically every other concern, including its absurd verbosity.
Backend languages don't and shouldn't matter, especially when most webdev backend is no more sophisticated than your average CLI and you're probably going to end up spending most of your time dicking with CSS and HTML anyway. You could probably count equivalent productivity lost in tens of thousands of lines of C++, just scanning the dizzying array of loonybin.js frameworks for frontend work.
I'd gleefully do any backend job in C++ if it meant someone else handing me the database schema and the frontend ready to go.
I recently finished the MVP for a weekend side project in Go, and I had a lot of fun (coming from a Node.js/Ruby background). I finally understood the draw of static typing (the compiler saved me a ton of time), but I didn't feel limited by the type system, nor encumbered by the syntax. The performance boost was also quite nice (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison). It's hard to imagine needing even more performance, since the Node version still would have been "good enough", and needing it so badly that it'd be worth muddling through C++ to get it (especially given the stark contrast of managing concurrency in Go vs C++).
You're probably not doing it right. You should see a factor 10 or more difference, without optimization. Why ? Because any variable lookup in a dynamic language is always at least O(log N), and the mere fact that it needs looking up at all costs you a lot. So every single statement and expression of a compiled language is going to blow the socks off any interpreted language.
Also, this was by no means a scientific benchmark - it wasn't a comparison of raw ops/sec, or anything like that: just the requests/sec on a few different routes (pretty close as far as implementation logic). I'm sure the chosen frameworks played into the results as well, but I'd consider that a more pragmatic benchmark anyways.
It has many interesting features like compile-time routing URL parameter checking, easy and fast (probably fastest among C++ json libs) json implementation by taking full advantage of C++11. If interested, take look of following code and repository:
https://github.com/ipkn/crow/blob/master/example.cpp