Slashdot Mirror

No one is seriously going to try to use C for front end web development.

Maybe not C, but how about C++?

Far too mainstream. Use C++.

It can be.

First of all, the fact that the application is for mobile devices it doesn't say anything.
Is the application you are mentioning runnint into the mobile device? Or is it a web application for mobile devices?
In the former case, I think you need to stick with the device architecture constraints, like ObjectiveC for Apple mobile stuff.
In the latter case, the choices is up to the developer team and what they know better.
I would personally choose C++ with Wt. But that's just me.

So, please, explain better your problem.

Bah. Wasteful bloat and unneeded garbage. Plus, not cross-platform. Correct fix is here, or possibly here.

(I'm half joking, half telling you kids to get off my lawn and take your w3 with you.)

I like C++, therefore I use Wt for webapps. Great performance and scalability, great for embedded systems, great for huge systems, great when using third-party libraries (you can use any C or C++ library), etc.

Note: that's a one time cost per platform, not compiled each page load like your "web apps". Native code saves electricity, and is thus more green than web apps.

Native applications are not the same as native code. You can write "web apps" in native code just fine, see e.g. Wt or Go.

Of we assume that OOP is a good paradigm in general, then there should be some way to construct server-side software in OOP, and not worry about the transport in HTTP. And whereas PHP has OOP bolted on later, maybe this language had it from the start?
While Python and Ruby are good, I'd like to talk about a gem i found called Wt

Wt is a spin off of Qt, but rahter than being client app focused, it is web app focused. it is programed in much the same way as Qt, but uses the Boost API proper, not some boost-inspired API.

It supports AJAX and you can even mark C++ functions for export to JS so they run client-side.

The problem is, if you're not used to thinking OOP about websites, and not used to Qt or Boost, the, your learning curve might be a bit longer than you'd like. Also, deployment is not as simple as dropping PHP files into the right spot in a file system.

http://www.webtoolkit.eu/wt

there's stuff like http://www.webtoolkit.eu/wt if you want to write both server and clients in one go.

http://www.webtoolkit.eu/wt

Not to detract from the desire to expand your toolbox, but have you considered http://www.webtoolkit.eu/wt as stepping stone into web application development? It essentially abstracts much of the CSS/DOM/HTML/Javascript hijinks away and allows you to think and develop in C++. It's modeled after the well known Qt framework.

using the Wt C++ Web Toolkit.

Are you sure you are not confusing Wt with something else? Wt works with 2 MB of RAM.

http://redmine.webtoolkit.eu/projects/wt/wiki/Wt_embedded

Wt ("witty") is a C++ toolkit that is modeled after Qt. It uses boost and STL, but you get to use familiar Qt concepts - signals & slots, Model view, etc. Basically think of Qt-based web pages. It fully supports AJAX and can handle the data server-side or on the client. It also has a C++ -> JS converter so you can just make a function for conversion to JS and have it exec on the client. Of course it runs as a module, or it comes with its own server. It fully supports CSS, DOM, etc.

I reall like this approach because my two complaints of PHP:
1. It is unstructured
2. it is ugly (both syntax, and having code embedded in pages)
are alleviated.
1. C++ object orientation encourages a structured approach.
2. The "it's 100% C++" ensures that you focus less on the presentation in PHP and just on the application logic. This helps encourage a model-view-controller approach. While you might have to write CSS, you will never have to write HTML and you won't ever have to mix the two in a CPP file.

Another reason is speed. Everything is compiled and runs natively, or compiled to JS and moved to the client.
Yet another reason is security. Wt has several protections built in. See the features link below.

If you're looking to do web pages entirely differently, this is it.

Additional features list

Wt ("witty") is a C++ toolkit that is modeled after Qt. It uses boost and STL, but you get to use familiar Qt concepts - signals & slots, Model view, etc. Basically think of Qt-based web pages. It fully supports AJAX and can handle the data server-side or on the client. It also has a C++ -> JS converter so you can just make a function for conversion to JS and have it exec on the client. Of course it runs as a module, or it comes with its own server. It fully supports CSS, DOM, etc.

I reall like this approach because my two complaints of PHP:
1. It is unstructured
2. it is ugly (both syntax, and having code embedded in pages)
are alleviated.
1. C++ object orientation encourages a structured approach.
2. The "it's 100% C++" ensures that you focus less on the presentation in PHP and just on the application logic. This helps encourage a model-view-controller approach. While you might have to write CSS, you will never have to write HTML and you won't ever have to mix the two in a CPP file.

Another reason is speed. Everything is compiled and runs natively, or compiled to JS and moved to the client.
Yet another reason is security. Wt has several protections built in. See the features link below.

If you're looking to do web pages entirely differently, this is it.

Additional features list

Wt is the best one I have tried. I use the C++ version, although there is also a Java version (JWt).

What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications. Also, the API is Qt-like (but using Boost).

I gave up on Rails after I used Wt.

Want a virtualization console? Take Wt, libvirt and an HTML5 VNC client and you are done.

Need Active Directory authentication? Wt, Samba (or Windows APIs if you are on Windows), done.

Streaming? Wt, ffmpeg libraries, done.

Forgetting about bindings and being able to use the millions of C/C++ libraries out there was a huge relief.

Also, size: Rails, Django (and even PHP) just do not fit in an embedded environment. Wt does.

Wt is the best one I have tried. I use the C++ version, although there is also a Java version (JWt).

What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications. Also, the API is Qt-like (but using Boost).

I gave up on Rails after I used Wt.

Want a virtualization console? Take Wt, libvirt and an HTML5 VNC client and you are done.

Need Active Directory authentication? Wt, Samba (or Windows APIs if you are on Windows), done.

Streaming? Wt, ffmpeg libraries, done.

Forgetting about bindings and being able to use the millions of C/C++ libraries out there was a huge relief.

Wt is the best one I have tried. I use the C++ version, although there is also a Java version (JWt).

What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications. Also, the API is Qt-like (but using Boost).

I gave up on Rails after I used Wt.

Want a virtualization console? Take Wt, libvirt and an HTML5 VNC client and you are done.

Need Active Directory authentication? Wt, Samba (or Windows APIs if you are on Windows), done.

Streaming? Wt, ffmpeg libraries, done.

Forgetting about bindings and being able to use the millions of C/C++ libraries out there was a huge relief.

Why is a new programming language required to "make web development transparent"?

Opa automatically generates client-side Javascript and handles communication and session control. The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logics, database queries and user interfaces

Wt does exactly the same but in C++. You develop webapps like desktop apps: widgets, ORM, etc. No need to care about Javascript, HTML, etc. Compilers available on all platforms. The result is a single binary which includes an embedded HTTP(S) server.

While I agree with what Opa wants to achieve, inventing a new programming language for that end is unnecessary and, in fact, will become a burden: they will need to maintain both the language and the library. But actually the value lies in the library, which is the one that needs to deal with HTTP, Javascript, AJAX, etc

I can't say I do agree with you, but I don't disagree either. I think that this is one of the premises that only time can tell.

There's a C++ Web framework to test your premise with a high profile web project:

http://www.webtoolkit.eu/wt

I really hope somebody uses it for something facebook-big and we hear about it.

Your C++ info is so 90s. FYI:
A descent C++ web framework: Wt
Memory management is a non-issue with RAII, smart pointers, Boehm garbage collector, and finally Valgrind.
Qt or LiteSQL don't need to be "standard" to do their job.

If you want what looks like a promissing web interface you might try http://www.webtoolkit.eu/wt. Life's beautiful when you can do web stuff in just one language

If you like C++ and the Qt API and you want to develop for the web (true web 2.0 AJAX apps), you should try Wt.

Wt clones the Qt API but using Boost instead of Qt. You can compile your web application to a FastCGI module (which you can deploy with Apache, lighttpd, IIS, etc) or to an executable which includes an embedded HTTP(S) web server.

Oh, and there are Ruby bindings, too (code)

Oh, and best of all: you can link to any C and C++ library (including Qt). No more messing with Ruby/Python/PHP/whatever bindings!

I'm not sure I'm following here. Are you trying to suggest C++ would be a better tool for web development than, say, PHP?

Only if you think faster is better. http://www.webtoolkit.eu/wt

Very cool! I wonder how it would play within a Wt environment.

http://www.webtoolkit.eu/wt/doc/tutorial/wt-sdj.xhtml

You wouldn't write a web app in C++ ...

But we _would_ do it!
See:
http://www.webtoolkit.eu/
http://www.tntnet.org/

Except that it's possible to write web app in C++ And using same ideas as GWT uses - just use Wt http://www.webtoolkit.eu/ FastCGI is required as interface (you can run your test server locally but for test only) JavaScript code is generated by runtime Server-side code itself is created in Qt-way (with signals,etc) Dual licensed And,btw, it can be crawled and it automatically downgrades (if you don't use custom widgets coded with JS-only support or graphics canvases) if client doesn't support AJAX

How this http://www.webtoolkit.eu/wt/hello.C is better than the equivalent Rail application? No thanks, I have better things to do than wrestle with this sort of things

I just can't think how unmaintenable that can become for a real world application.

I've been working a little with Python lately, to experiment with Google App Engine. I found it very verbose (that is: I have to explicitly write many things that Rails gives me for free) but it's still much better than what I saw here.

Anyway, I'm sure that some people with a different background than mine (which however includes C and Java) might find easier to code with Wt than learning Rails or Python.

I used to use Rails until I discovered Wt: C++, Qt-like API, you develop webapps with widgets (as if they were a desktop application, no more "templates" or "pages") and you don't need to write a single line of HTML, CSS or Javascript. You can deploy it as a FastCGI module for Apache, Lighttp, etc, or as a standalone application with its own webserver. It supports very heavy loads, more than Rails or Django will ever be able to deal with. And you can link to a myriad of existing C and C++ libraries.

Do you want to authenticate your users using Active Directory? Use Samba and link to libwinbind if on Unix, or link to the Windows API if on Windows (yes, it's cross-platform!). No more worries about language bindings.

If I were to develop a web-based desktop application, I'd use a web framework which allows me to develop a webapp just like it was a desktop app. The only such framework I know is Wt ( http://www.webtoolkit.eu/ ): C++, Qt-like API. I gave up on Rails after discovering it.

Although sanitizing user input gets the job done, what one should be doing is sanitizing the output .

An XSS attack exists because you are dynamically generating a web page with content you didn't intend: which contains executable script instead of where you intended dumb text (that you got from a database or that was entered earlier on by a (another) user). Sanitizing user input (which is the only factor you don't control) will help but if I enter <script>1+1</script> as some comment on for example a JavaScript forum, I would expect it to appear like that !

The definite solution to getting rid of XSS attacks is to use a modern toolkit that actively prevents this without ANY effort from the programmer. Like Wt for example does.