[Interest] Bringing Qt, C++ To The Web

Jason H scorp1us at yahoo.com
Fri Jan 18 14:33:05 CET 2013


Except of course in Wt, where you can mark C++ functions for export to JavaScript. Which might seem trivial but It gives you a built-in abstraction layer if MS decides to be insolent and only support JScript or F# or something.





________________________________
 From: Nikos Chantziaras <realnc at gmail.com>
To: interest at qt-project.org 
Sent: Thursday, January 17, 2013 11:29 PM
Subject: Re: [Interest] Bringing Qt, C++ To The Web
 
On 17/01/13 22:50, Jason H wrote:
> What is the "web" you speak of? LOL

It's this one:

   http://en.wikipedia.org/wiki/WWW

;-)


> Anyway, that [zero-install] is definitely a legitimate issue. However I
> have to puke and kick a puppy when it comes to overall web development.
> We were approaching something really good with Java and .NET, but these
> got sidelined by a handful of easy-to-implement standards that now
> requires you to know a minimum of 3 technologies, but more like 6: HTML,
> JS, CSS, MIME, SQL, .NET or Java or PHP, not to mention Linux/IIS server
> administration.
>[...]
> Wt on the other hand, is C++ and takes care of all of that for you. You
> can provide a CSS, but you don't have to. It doesn't matter if tomorrow
> the web ditches HTML for XML or pure javascript, or ditches MIME headers
> for JSON ones. The toolkit will take care of it for you. Don't recode,
> just recompile. And let the toolkit take care of browser sniffing.
> Everything made hard by traditional web development is made obsolete by Wt.
>
> And yes, I would love it if Qt and Wt merged.

I did try Wt and do find it awesome for server-side development.  But 
the thing when being server-side is that you can always come up with 
your own solutions.  After all, you can run native code on the server. 
If Wt didn't exist, you could always write your own abstraction layer 
for your C++ code.  They key is, you *can* run your C++ code.

When being client-side there's no such freedom.  Your C++ codebase is 
completely useless as you can't run it on the client.  Which is why 
Emscripten is such an amazing technology.  I expect it to get faster 
with time, especially as JS itself evolves, eliminating more 
bottlenecks.  And do not forget that Emscripten is not "just" a C++ to 
JS compiler.  It's an LLVM bitcode to JS compiler.  So it can 
potentially allow deployment of code written in any language.




> ------------------------------------------------------------------------
> *From:* Nikos Chantziaras <realnc at gmail.com>
> *To:* interest at qt-project.org
> *Sent:* Thursday, January 17, 2013 11:00 AM
> *Subject:* Re: [Interest] Bringing Qt, C++ To The Web
>
> On 17/01/13 17:51, Konstantin Tokarev wrote:
>  >
>  >
>  > 17.01.2013, 19:38, "Nikos Chantziaras" <realnc at gmail.com
> <mailto:realnc at gmail.com>>:
>  >> On 17/01/13 17:31, Pau Garcia i Quiles wrote:
>  >>
>  >>>  On Thu, Jan 17, 2013 at 4:28 PM, Nikos Chantziaras
> <realnc at gmail.com <mailto:realnc at gmail.com>
>  >>>  <mailto:realnc at gmail.com <mailto:realnc at gmail.com>>> wrote:
>  >>>
>  >>>      I'm thinking more of ScummVM, DOSBox, Snes9x, etc.  Would you
> run those
>  >>>      on the server?  Sure you can do it.  But running on the client
> instead
>  >>>      has enormous benefits.  Having to download 10MB of JS is a
> small price
>  >>>     to pay.  If that really was such a concern, YouTube wouldn't
> bee that
>  >>>      popular.
>  >>>
>  >>>  And here we are finally, back to the thin client vs fat client debate
>  >>>  :-) It always happens when webapps are involved.
>  >>
>  >> Not when you don't have a server, just dump web-space ;-)
>  >>
>  >> Google had the right idea with NaCL, but since other browsers don't plan
>  >> to support it, we're stuck with JS.
>  >
>  > 'Stuck' is keyword here, because JS from Emcscripten is not going to
> run as fast
>  > as NaCl or even close to it. However, anyone can implement NaCl for
> Firefox
>  > and other browser via NPAPI plugin.
>
> If the browsers don't come with it out of the box, then people will have
> to download that plugin.  But if they have to download the plugin, then
> they might as well download the native executable application instead.
> The point it to be able to give a URL and have it just work without
> users having to manually download anything.  Pretty much what web
> deployment is about.


_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130118/56bef8fa/attachment.html>


More information about the Interest mailing list