What is the "web" you speak of? LOL
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.
The reason I puke is the number of standards you have to be famialr with. The
reason I kick the puppy is this cannot be the best paradigm software
development can have. It is an organic evolution of indepenendt technologies
that don't come together to make a race horse, they make some kind of creature
that has an arm, and leg, a hoof, a claw, and am mouth and exit hole. It's very
much like a Swiss army knife - does everything but damn dangerous when you use
all the things at once.
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.
________________________________
From: Nikos Chantziaras <rea...@gmail.com>
To: interest@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" <rea...@gmail.com>:
>> On 17/01/13 17:31, Pau Garcia i Quiles wrote:
>>
>>> On Thu, Jan 17, 2013 at 4:28 PM, Nikos Chantziaras <rea...@gmail.com
>>> <mailto:rea...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
