Hi Petr
I don't think it needs to be split - that's what the generator is for, to
assemble just the bits that are needed by your app. There is a fairly
large core of classes which are always needed, and maybe something could be
done to reduce those dependencies, but any such optimisation would only
affect small applications.
If anything, it is debatable whether there should be a distinction between
Desktop/Server/Mobile because the generator can put together just what your
app needs.
Qooxdoo is not particularly light weight; AIUI that's what the "website"
version was created to do, not that I've used it. However Qooxdoo is suited
to building large apps (one of my apps is 146,000 lines of unminified JS)
and that's a different use case.
I don't think there is an inherent issue with wrapping existing, well
written libraries in a Qooxdoo-compatible class (e.g. a rich text editor,
jqPlot, etc), but there is little motivation in making a contrib of anything
if there isn't anyone to use it.
That's a circular argument of course: shrinking user base == less users want
to contrib == product gets dated == less users want to start using it == etc
etc.
John
From: Petr Kobalíček <kobalicek.p...@gmail.com>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Wednesday, 28 May 2014 14:40
To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] New contrib website
Guys,
>From my perspective - I think that what is becoming a problem as well is its
monolithic architecture. Qooxdoo is not modular, every time I use it I feel
like working 15 years back on some C++ project. JS is a very dynamic
language and I think it should be used that way also in Qooxdoo (split the
core, components, make it modular and just minify).
Second problem is that a lot of contributions are wrapping third party code
into a "qooxdoo way". This is ridiculous - if there is a good third party
library one should be able to use it even without rewriting the whole API
into qooxdoo style.
There are another things as well, look at Angular for example how easy
databinding can be.
My 2 cents;)
Petr
On Wed, May 28, 2014 at 10:50 AM, panyasan <i...@bibliograph.org> wrote:
> This is an interesting and important discussion!
>
> Because of the points you raised, I think the contrib infrastructure is so
> critically important. I know that since qooxdoo has a corporate sponsor, the
> dev team is not totally free to chose its priorities, but the value of a
> library depends on its ecosystem, and the growth of the ecosystem depends on
> how easy it is to contribute (see npm).
>
>
>
>
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/New-contrib-website-tp7585740p7585750.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download <http://www.restlet.com/download>
> http://p.sf.net/sfu/restlet
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
----------------------------------------------------------------------------
-- Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet_______________________________________________
qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
