Building a website with C++ (CppCMS)(kukuruku.co)
kukuruku.co
Building a website with C++ (CppCMS)
http://kukuruku.co/hub/cpp/building-a-website-with-c-cppcms-part-1
6 comments
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)
Ran an example where i find the pupil of an eye: http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html
Ran an example where i find the pupil of an eye: http://users.ece.cmu.edu/~jsmereka/eye/imgtst2/index.html
Surely, in 2014 we can do better than CppCMS...
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?
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?
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.
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.
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.
> C++ is crying out for a bit of 'hip'
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.
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.
That's very interesting, thanks for linking to it. I've never heard of it but it can come handy.
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 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++).
Why Go and not Haskell?
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.
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.
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.
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.
This is the sort of improvement you'd see if your program was fully IO bound.
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..).
This could benefit from a template engine like Smarty because graphic design items have an order that is hard to describe in a programming language.
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