Network/multi-user program

Lele Gaifax lele at
Tue Jul 22 10:50:44 CEST 2014

Monte Milanuk <memilanuk at> writes:

> On 2014-07-22, Lele Gaifax <lele at> wrote:
>> On the other hand, it has good and extensive examples, so the learning
>> curve is not so steep (I'm clearly biased here, but I introduced several
>> young developers to that environment and that's what they said too).
> Any experience with angular js?  Browsing the web showed a few mentions
> of it vs. ext js.  Mostly I'm still at the curious stage on this...
> either one is completely foreign to anything I've done before.

Very, very little. I evaluated it quickly, but then my boss at the time
"dictated" the Pyjamas route...

>> Anyway, don't be scared: start on the Python side, laying down the
>> foundations of the application, the database model, the main business
>> logic, unit and functional tests, and so on. Any kind of frontend, be it
>> a traditional desktop application or a web based one will build on that.
> Well... thats part of where my lack of experience with js or complex
> projects using anything other than just python is going to show:
> initially I thought javascript was just for buttons/effects in the
> client browser as thats all the trivial examples I looked at years ago
> did.  The bits n pieces I'm seeing of these 'modern' javascript MVC
> frameworks like sencha, angular, etc. is making me think that a lot of
> the 'work' is moving from the server to the client via the javascript...
> which just blurs the heck out of things and confuses me as to what
> should be in the browser and what should be on the 'server'?  And where
> the testing goes?

Yes, that is effectively the fuzzy dichotomy you'll have to deal with.

>From my point of view, I tend to see the JS frontend as the GUI library
that I use to "draw" the application, and I try to keep it separate from
the "logic" as much as I can. It does not matter if the GUI is written
in JS, GTK+, curses, NeXTstep or Delphi: it has been *always* a
nightmare to implement serious automatic tests on that side of all my
apps, and that's the main reason I keep complicated things on the
backend side. And you know, with Python even complicated things are

> If more of the 'heavy lifting' is being done on the
> client, is there a need for a full-service python framework like django
> or would something lightweight like flask be more appropriate?  Again, I
> know almost nothing about pyramid and where it falls into the mix.  I
> can read the propaganda on their respective web sites, but that is
> necessarily skewed. :/

Even if I used some Django apps, I never developed anything with it: it
does not seem a good choice for the kind of applications I happen to
write. Its main selling point is the somewhat automatic CRUD view
generation, something I'm always going to implement in other ways
anyway. Its main "no thank you" point is the hassle with its "son of a
minor god" ORM.

I started using Flask for a couple of applications that at first
appeared to be "very simple", but actually most of the time any
application seems "simple enough" at first but very quickly become
"complicated enough" to warrant a better infrastructure: after a few
weeks I retargeted them to Pyramid, which I find robust, well documented
and versatile.

ciao, lele.
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele at  |                 -- Fortunato Depero, 1929.

More information about the Python-list mailing list