Coming from Sencha (ExtJs)...

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Coming from Sencha (ExtJs)...

Reggaeny
This post has NOT been accepted by the mailing list yet.
Hi everyone,

I'am an absolute newcomer to qooxdoo. Supposedly I wouldn't be here if the owner and maintainer of the Javascript-Framework I'am actually using - Sencha and ExtJs - had another licensing policy. But as the Sencha guys are screwing off their single developer community by not selling single developer licences any more (you have to buy a 5 developer license which is more than 3.000 $ a year), I was forced to find an alternative and came up against qooxdoo which was absolutely unknown to me. I was extremely positively impressed....!

There are but two major aspects that I'm missing (and would have to develop individually if I used qooxdoo)

1. Grids (you call them tables) with the functionality of ExtJs-Grids (e. g. rowediting).
2. WebSockets

So it would help me a lot if I did know if there are plans or roadmaps existing, giving me an idea in which direction qooxdoo is evolving concerning those two aspects.
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

bobmanc
I am in the same situation and agree that the table functionality is a bit behind ExtJS. I am blogging my experience of transitioning to Qooxdoo from ExtJS at https://ext2qooxdoo.wordpress.com. Please check it out and possibly leave some comments on your experience.
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Reggaeny
I certainly will. May be we could pool our efforts to get some "tricks" into qooxdoo which we learned to love when using ExtJs.
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Loren Schlomer-2
The absolute biggest win for Qooxdoo is its type system*, which makes
large projects absolutely designable and maintainable.  If you've ever
made desktop applications with GTK or Qt, Qooxdoo just simply rocks.  
This alone makes up for their lacking fancy/modern controls. (That said,
those missing controls can be added [relatively] easy, if one has the
time and desire.)

ExtJS's type system has improved with later versions, but is still
lacking; making for not-so-fun development cycles.  And, as you
mentioned, their licensing model is just an absolute shame.  You either
need very deep pockets, or risk exposing your entire application code
stack through **GPLv3.  It doesn't matter how pretty or amazing their
widget set gets, I'm not touching Sencha with a 10-foot pole.


If you've never heard of SmartClient
(http://smartclient.com/product/smartclient.jsp) it might be worth a
look.  Its widget set is pretty complete - at least on par with ExtJS,
if not more so.  My biggest issue with SmartClient is its type system.  
It's pretty apparent their widget library is geared for code generation
to be used with their GWT libraries.  It's possible to do entire
applications using just the javascript portion of their library, but it
is far from what I would call 'enjoyable'.  Two major flaws, widget
composition and events --  Seriously, who does this:

isc.IButton.create({
     title: "Click Me",
     icon: "my_icon.gif",
     click: function () { [...] } // Why is this a good idea, instead of
firing off an event?!
});

Their open source license is at least LGPL, so you don't have to worry
about having to release your entire application **stack, but their
documentation is just absolute crap; Yes, maybe better than NO
documentation, but you'll still quickly find yourself pulling out hair,
trying to find what you're looking for.


So, quick run-down on pros/cons for each:

ExtJS
Pros:
   1) Complete set of modern, nice looking, useful widgets
   2) I'll include their improving type system* as a pro, as they at
least seem mindful of project organization/maintainability.

Cons:
   1) Cost of commercial license and absolute non-starter on their open
source license

SmartClient
Pros:
   1) Complete set of modern, nice looking, useful widgets
   2) The LGPL is acceptable
Cons:
   1) Horrid type system
   2) Documentation is a complete and utter waste.  Might be more useful
if utilizing GWT, but I have absolutely zero interest in doing GWT.


Qooxdoo
Pros:
   1) By far (we're talking miles and miles [or kilometers and
kilometers... :)] the best type system of *any* javascript framework
   2) Project organization and maintenance
   3) Quite possibly the best documentation of any javascript framework
   4) Once you *get it*, it is an absolute joy to develop in.  It really
is like working with GTK or Qt.
   5) Perfectly acceptable license to be used with internal corporate
applications.
Cons:
   1) Its widget set is lacking (but thus far has been suitable for
everything I have needed, with the ability to bolt on anything else
easily.)
   2) Much smaller community, with the illusion of the community
shrinking (This has been debated at various times.)



I too originally stumbled across Qooxdoo, looking for something other
than ExtJS (but that's been a number of years ago already,) and
absolutely fell in love with it, so I may be slightly biased.  The
community may be small, but those in it are always happy and eager to
help.  The core developers are easily approachable and open to
suggestions.  It's been a long time since I've interacted with the ExtJS
community, so I cannot comment there, but I have had a pretty poor
experience with the SmartClient community.  Posting in their forums
yielded very poor and unacceptable results. (At the time, a
non-technical salesmen was moderating the forums, attempting to answer
technical questions, always pointing folk to their poor documentation
and making posters feel generally stupid for not R[eading]-TFM.  It may
have improved since, but not likely. (I am not a fan.)

I do not [nor cannot] fault ExtJS and SmartClient for wanting to earn
some money from their hard work.  Both have created very nice looking
and useful tools.  Their chosen revenue model IS their framework.  
Qooxdoo on the other hand (through 1&1) has chosen a different revenue
model, through web hosting and other online services, thus, their
framework lacks some polish, and slower progress.


*What I mean by 'type system' is the class hierarchies, class definition
and inheritance models, namespaces, and all other OO features.  All
these make reusable component and widget compositions just so
fantastically wonderful.

**Yes, it has been argued the GPLv3 libraries can be used for internal
applications without releasing your code base, but its definition is so
vague that a company like Sencha COULD possibly take you to court if you
didn't release your underlying PHP/Java/[...] code along with your
client code.  This is absolutely not worth the risk or the headache.



TL;DR: Qooxdoo ftw. :)













On 2014-11-07 07:09, Reggaeny wrote:

> I certainly will. May be we could pool our efforts to get some "tricks"
> into
> qooxdoo which we learned to love when using ExtJs.
>
>
>
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/Coming-from-Sencha-ExtJs-tp7586356p7586361.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Reggaeny
Wow...!
What an eloquent and complete answer.

I'm just analyzing several Javascript Frameworks in order to examine the feasibility of developing a commercially used/sold technology platform consisting of a java backend and a javascript/HTML5 framework as a frontend.

The type-system of qooxdoo, you mentioned, is a very strong argument as it perfectly fits to the strong typing of Java making it easier to maintain a concise and comparable programming philosophy for both the front- and the backend.

There is but one question left. You say that the qooxdoo license is OK for corporate applications. As far as I can see the LPGL/EPL License obliges me to publish the applications developed with qooxdoo under the same license. As most of the business logic and the components deserving protection are part of the server and the middleware (message-broker) I'm just developing, I suppose the LPGL/EPL license would be OK for me.
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Loren Schlomer-2

The LGPL only obliges you to release derived works under a compatible
license.  The issue really hinges on what is really considered a derived
work.  With executables, if you link your application against LGPL code
statically, it is considered derived, but if you link it dynamically, it
is not.  If you make changes to the library, it is very obviously
derived and must also be released under a compatible license.  This is
pretty clear cut and dry.

With javascript development, things get a little murkier.

Let's use jQuery as an example (I know it's MIT and not LGPL, but for
the sake of discussion...)  If you pull in jQuery, your code can still
be separated from jQuery and would not need to be released.  If you used
some tool to concatenate and minimize all your code with the jQuery
code, your code cannot be separated from the jQuery code and would need
to be released with a compatible license.  Dynamic linking vs static --
essentially the same concept.

With qooxdoo and its necessary build process, you are essentially always
static linking.  With careful planning and use of the Parts Loader
(http://demo.qooxdoo.org/current/apiviewer/#qx.io.PartLoader) you can
effectively separate your code, and only release the linking code. (Just
the code that does the loading.)

HOWEVER:

"As an exception to the Sections above, you may also combine or link a
"work that uses the Library" with the Library to produce a work
containing portions of the Library, and distribute that work under terms
of your choice, provided that the terms permit modification of the work
for the customer's own use and **reverse engineering** for debugging
such modifications."  -- emphasis mine

http://www.gnu.org/licenses/lgpl-2.1.html   <-- See section 6

It *could* be argued that even concatenated and minimized javascript
code can be reverse engineered (no matter now tedious,) so a "statically
linked" javascript application is also excluded as a non-derived work.

This gets a little hairy, no??


Of course, there is the caveat that I'm not a lawyer, and others may
interpret the LGPL differently.  Since I'm not doing anything
externally, not selling or distributing anything outside of this
organization (with the exception of a number of non-employee users
accessing our applications,) the LGPL is perfectly acceptable in our
use-case.  The GPL is not.  We are most definitely not releasing our
server side stuff!  :)  At the end of the day, if our non-employee users
really *want* to see our client side code, we have no major reservations
against it -- it's never been an issue regardless...








On 2014-11-07 14:58, Reggaeny wrote:

> Wow...!
> What an eloquent and complete answer.
>
> I'm just analyzing several Javascript Frameworks in order to examine
> the
> feasibility of developing a commercially used/sold technology platform
> consisting of a java backend and a javascript/HTML5 framework as a
> frontend.
>
> The type-system of qooxdoo, you mentioned, is a very strong argument as
> it
> perfectly fits to the strong typing of Java making it easier to
> maintain a
> concise and comparable programming philosophy for both the front- and
> the
> backend.
>
> There is but one question left. You say that the qooxdoo license is OK
> for
> corporate applications. As far as I can see the LPGL/EPL License
> obliges me
> to publish the applications developed with qooxdoo under the same
> license.
> As most of the business logic and the components deserving protection
> are
> part of the server and the middleware (message-broker) I'm just
> developing,
> I suppose the LPGL/EPL license would be OK for me.
>
>
>
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/Coming-from-Sencha-ExtJs-tp7586356p7586363.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Petr Kobalíček
In reply to this post by Reggaeny
I would definitely like to have an answer to this, because LGPL and minification CAN be a violation, and the way Qooxdoo works, basically forcing you to use generator and to distribute your own code with qooxdoo's, is a licence violation of "That it is dynamically linked in to your application in such a way that the user can replace it with their own version if they want.".

I used this stackoverflow question:


It seems that LGPL is simply an inappropriate license for JS, I don't know much about EPL.

So the question for the team, what we are obliged to do to distribute our minified app, is there any list?

Best,
Petr

On Fri, Nov 7, 2014 at 11:58 PM, Reggaeny <[hidden email]> wrote:
Wow...!
What an eloquent and complete answer.

I'm just analyzing several Javascript Frameworks in order to examine the
feasibility of developing a commercially used/sold technology platform
consisting of a java backend and a javascript/HTML5 framework as a frontend.

The type-system of qooxdoo, you mentioned, is a very strong argument as it
perfectly fits to the strong typing of Java making it easier to maintain a
concise and comparable programming philosophy for both the front- and the
backend.

There is but one question left. You say that the qooxdoo license is OK for
corporate applications. As far as I can see the LPGL/EPL License obliges me
to publish the applications developed with qooxdoo under the same license.
As most of the business logic and the components deserving protection are
part of the server and the middleware (message-broker) I'm just developing,
I suppose the LPGL/EPL license would be OK for me.



--
View this message in context: http://qooxdoo.678.n2.nabble.com/Coming-from-Sencha-ExtJs-tp7586356p7586363.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Tom Saddul
In reply to this post by Reggaeny
For websocket, there are already existing proven libraries out there ready to be used like SignalR or Socket.IO. I'm been using SignalR with a .NET server for a few years.  You can try this https://www.npmjs.org/package/signalr-client to connect SignalR with Node.JS.
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Reggaeny
In reply to this post by Loren Schlomer-2
May be, I'm a bit dim-witted. So I will try to put my question a bit more precise.

We (that's the start-up I'm working for) are going to develop a software platform roughly consisting of three components - a server,  a middleware and a client - whereas the client should have a desktop, a browser and a mobile shape. The platform is to be used in an enterprise / business environment.

The actual candidates for the client development are ExtJs (unfortunately very expensive and limited concerning their licensing policy), Dojo and qooxdoo.

We won't have any problem if the client component would be absolutely open-source in a way that our customers - and qooxdoo - would have unlimited access to the sources of the client component. The other two components - means everything that runs on a server - should have to be completely separated concerning the licensing - means that our customers will have to buy the server and client components separately - whereas the server-components could be open-source as well -.

Is that target strategy limited by the LPGL/EPL licensing or not?
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

oetiker
hi regine,

IANL! But my interpretation is this.

1. client, server and middle war are separate things, to be considered separately

2. if you implement the client, using the qooxdoo SDK, you are free to pick any license you want for the client, BUT if you make changes to the qooxdoo class files, these changes have to be made available TO YOUR CUSTOMERS under the LGPL.

3 if you run the server as a service, so the customer does not get to run his own copy, the  you do not have to publish any source even if the server employs GPL components. The only case you would have to license things to you customers would be if you used components licensed under the Avero GPL or Avero LGP

hth
tobi

Tobias Oetiker
[hidden email]
062 775 9902

> On 08.11.2014, at 03:21, Reggaeny <[hidden email]> wrote:
>
> May be, I'm a bit dim-witted. So I will try to put my question a bit more
> precise.
>
> We (that's the start-up I'm working for) are going to develop a software
> platform roughly consisting of three components - a server,  a middleware
> and a client - whereas the client should have a desktop, a browser and a
> mobile shape. The platform is to be used in an enterprise / business
> environment.
>
> The actual candidates for the client development are ExtJs (unfortunately
> very expensive and limited concerning their licensing policy), Dojo and
> qooxdoo.
>
> We won't have any problem if the client component would be absolutely
> open-source in a way that our customers - and qooxdoo - would have unlimited
> access to the sources of the client component. The other two components -
> means everything that runs on a server - should have to be completely
> separated concerning the licensing - means that our customers will have to
> buy the server and client components separately - whereas the
> server-components could be open-source as well -.
>
> Is that target strategy limited by the LPGL/EPL licensing or not?
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Coming-from-Sencha-ExtJs-tp7586356p7586367.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Coming from Sencha (ExtJs)...

Dietrich Streifert
In reply to this post by Reggaeny
Hi Regine,

Did you try to send your questions as recommended in

     http://qooxdoo.org/license#need_further_assistance

> Need further assistance?
> If you have any questions regarding the rights and obligations that
> come with qooxdoo's license, even after you carefully acquainted
> yourself with the licensing terms, please feel free to contact license
> AT qooxdoo DOT org.

?

Regards
Dietrich

Am 08.11.2014 um 12:21 schrieb Reggaeny:

> May be, I'm a bit dim-witted. So I will try to put my question a bit more
> precise.
>
> We (that's the start-up I'm working for) are going to develop a software
> platform roughly consisting of three components - a server,  a middleware
> and a client - whereas the client should have a desktop, a browser and a
> mobile shape. The platform is to be used in an enterprise / business
> environment.
>
> The actual candidates for the client development are ExtJs (unfortunately
> very expensive and limited concerning their licensing policy), Dojo and
> qooxdoo.
>
> We won't have any problem if the client component would be absolutely
> open-source in a way that our customers - and qooxdoo - would have unlimited
> access to the sources of the client component. The other two components -
> means everything that runs on a server - should have to be completely
> separated concerning the licensing - means that our customers will have to
> buy the server and client components separately - whereas the
> server-components could be open-source as well -.
>
> Is that target strategy limited by the LPGL/EPL licensing or not?
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Coming-from-Sencha-ExtJs-tp7586356p7586367.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel