web2py vs others. Status of 2014

[António Ramos]

what is the status of the evolution of web2py compared with other, mainly rails /or django ?

which of these including web2py has gain more improvements over the last year?

Does anybody knows?

Is still web2py over the others?

From the beginning Massimo used the phrase

"Ideas we had , ideas we stole"

I would like to know if Massimo  is stealing more ideas from others.

Also what new "Killer" ideas are we expecting for near future?

Regards

António

[Massimo Di Pierro]

Good questions.

Web2py has changed less in the last year than in the year before and most of the changes have been small improvements and strengthening security. In my view web2py is a very mature project and users do not want big changes at this point. We have some todo items including a more flexible grid, better CSS customization. I personally did not find much to learn from Django and Rails in the last few years instead I am much more interested in the async capabilities of Python 3.4, and in some javascript libraries like Angular, Ember, and Ractive (my favorite), by hypermedia APIs, and by Semantic-UI.

I think the future is a lighter web2py with a similar IDE but more client-side logic out of the box and more automatic. For example I have ported the web2py helper system (DIV, SPAN, etc.) to JS. I would like to move form generation also clients-side. I would like move away from the MVC and to a mini-MVC patter where an action is responsible for a single component (for example validation) and not for an entire page. Wherever we are going the DAL is staying! 

Massimo

[黄祥]

On Tuesday, June 10, 2014 9:14:03 AM UTC+7, Massimo Di Pierro wrote:

Good questions.

Web2py has changed less in the last year than in the year before and most of the changes have been small improvements and strengthening security. In my view web2py is a very mature project and users do not want big changes at this point. We have some todo items including a more flexible grid, better CSS customization. I personally did not find much to learn from Django and Rails in the last few years instead I am much more interested in the async capabilities of Python 3.4

is that mean, the web2py developers is make web2py work under python 3.x? or perhaps create the other project same like web2py that work under python 3.x
 

and in some javascript libraries like Angular, Ember, and Ractive (my favorite), by hypermedia APIs, and by Semantic-UI.

I think the future is a lighter web2py with a similar IDE but more client-side logic out of the box and more automatic. For example I have ported the web2py helper system (DIV, SPAN, etc.) to JS. I would like to move form generation also clients-side. I would like move away from the MVC and to a mini-MVC patter where an action is responsible for a single component (for example validation) and not for an entire page.

with the movement you've mention, is it still keep the backward compatiblity for the future version of web2py?
when the newer version of web2py will be released?

best regards,
stifan

[Tim Richardson]

THanks for this update Massimo. That sounds great, and it sounds like a platform with lots of potential. I just hope there is a way to incrementally feed in the improvements.

[Derek]

I'd love to see a DAL-only Python 3.4 release, I could use that in my web framework. I think it would be good to steal an idea from Pyramid, make your framework piecemeal. Dal, Forms (with built-in protections and validations), routing (hopefully simpler than it is now). ,  In any case, I love the project as it is now, it's easy to understand, well documented, and has a great community.

[Anthony]

On Tuesday, June 10, 2014 1:47:55 PM UTC-4, Derek wrote:

I'd love to see a DAL-only Python 3.4 release, I could use that in my web framework. I think it would be good to steal an idea from Pyramid, make your framework piecemeal. Dal, Forms (with built-in protections and validations), routing (hopefully simpler than it is now). ,  In any case, I love the project as it is now, it's easy to understand, well documented, and has a great community.

See https://github.com/mdipierro/gluino.

[António Ramos]

I would love to see DAL as an independent persistence API

just like socket.io we could have a DAL.io

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arnon Marcus]

Massimo is right - the future is a fatter client and thinner server (Hell, it's already "the present", or even "the past"...)

I like exactly the technologies Massimo mentioned, with some additions.
I opened a few google-groups for integration of Ember, Angular and the like, but then life happened and I had other things to do...
Plus, from gauging future trends, it seems even Angular and Ember are about to go "obsolete", or at the very least undergo such a massive fundamental change, that it would be difficult (at least for me) to justify learning them as they are today...

There are 2 "main" reasons for that (there are actually more then 2...):
1. Web Components : An umbrella-term referring to a set of emerging-standards that allow for OOP-style declarative HTML (Encapsulation, Inheritance, etc.), with built-in support for 2-way-databinding, templating, and ultimately "Extending the HTML language with custom features" (most everything Angular, and to some degree Ember, are doing today) - but all in a stardard-way, supported by all browsers (which means, cross-framework component-sharing, performance improvements to these features, etc.). To me, this may change web-development so fundamentally, that it should be named HTML6 or something...

2. ECMAScript 6 [The next version of JavaScript] : Too much to mention here about it, but this is also a very fundamental shift of design-architecture of client-side frameworks, which is GOING to change MANY framework's APIs.

Angular has already declared support for these two technologies in the future iteration of it (2.x) in many occasions, and stated that it will be very different (think braking-changes to the API) - They are actually cooperating with the standards-bodies and iterating on the specs of web-components.

Ember has also stated similar statements, with braking-changes to the API of the 2.x release, and is also deeply involved with the standards-bodies (Yehuda Katz, one of the 2 main founders of the framework, actually has a seat at some relevant standards-body, and is actively contributing to the spec).
Another relevant-project to mention here is HTMLBars, which is a replacement templating-engine for Handlebars for Ember (sorta...), which mimics a lot of what's in both Angular and Web-components in terms of syntax (It can actually be used outside of Ember...).

This means that the ground is shifting beneath such framework's feet - which means, it's not a good time to make any long-term investment in them (in my view).
This is one of the major-reasons I stopped-short of investing in integrating them with web2py...

2 other notable technologies are the actual web-protocols: Web-Sockets and HTTP2.

The direction the whole web-stack is moving towards, is a combination of HTTP for "initial" loading of "pages" and/or "components", with MVC on the client, and then Web-Sockets for all data-interchange (between client and server) after that.
This offers the best performance AND usability for users and developers.

And even without Python 3.4's async features, that last point is already achieved with technologies like G-event and Socket.io, and can easily leverage, and be used in conjunction with,  web2py's amazing DAL (speaking from personal-experience).

To conclude, I think that if web2py is to have any future at all, this is the direction it should be aiming at - having a dual-server arrangement, with an HTTP(1.1/2.0) server for initial loading, and component-setup via ajax, and then a WebSocket server for all data-intensive interchange - all using common APIs, but in a shared-nothing arrangement of 2 types of server-processes (IPC may be introduced at some point after that).

[lyn2py]

Hi Massimo, probably a dumb question, but can you explain more why you would want to move the helper system and form generation to clients side? Thanks.

When do you foresee that Python 3 will takeover the world by storm and leave Python 2 permanently behind? And when will web3py be ready… hehehe...

I actually like the idea that for one time, web2py will break backward compatibility to create a better, lighter web2py. Probably won't happen until web3py, but I'm just dreaming :)

Love it that DAL is staying no matter what :)

[Massimo Di Pierro]

On Thursday, 17 July 2014 04:50:16 UTC-5, lyn2py wrote:

Hi Massimo, probably a dumb question, but can you explain more why you would want to move the helper system and form generation to clients side? Thanks.

I think it would be nice to have a framework where the server only needs to data (ajax web services) and the forms are generated by JS code based on information provided by those services.

 

When do you foresee that Python 3 will takeover the world by storm and leave Python 2 permanently behind? And when will web3py be ready… hehehe...

Not soon ;-)

[lyn2py]

Ok, thank you for the response. :)

[lyn2py]

Hi Massimo, I have been reading up a bit on the direction of JS and wondering if this porting of helper system and form generation -- will it be for web2py or it will be a new feature for web3py?

Will it be dependent on any particular JS libraries?

[António Ramos]

@Massimo,

You could have a dal.js generated automaticaly for the client to access the databases.

This is how deployd does it! (they autogenerate dpd.js for the client)

http://docs.deployd.com/docs/collections/accessing-collections.md

http://docs.deployd.com/docs/collections/reference/dpd-js.md

I bet i cannot do it ! :)

--

[Joe Barnhart]

I look forward to Massimo's improvements.

One of the continuing thorns in my side is that a significant number of my users are still on XP and IE8 -- about 15% -- and my users are in California.  I can only imagine the ratio would be higher in middle America where the tall corn grows.  I could choose to ignore these users, but they have money to spend and I want to get it.

As we move to more client-heavy designs, it means more javascript and more chances that it won't run in antique computers.  I can't leave 15% of my revenue on the table.  

On the other hand, more and more of my users are on mobile platforms, which fits perfectly with the heavy client approach.

Arrrrgh!

-- Joe

[Cliff Kachinske]

Modernizr?

Do you think that tall corn interferes with the purchase of new equipment? Whiskey Tango Foxtrot?

[Massimo Di Pierro]

Very true.

[Dave S]

On Wednesday, August 6, 2014 8:35:06 AM UTC-7, Cliff Kachinske wrote:

Modernizr?

Do you think that tall corn interferes with the purchase of new equipment? Whiskey Tango Foxtrot?

Tall corn is often grown by people who don't jump on the bleeding edge.  Some of them don't even jump on the bandwagon.

"it ain't broke 'til you run out of baling wire."

/dps

 

[Willoughby]

Actually, modern agri-business is one of the most connected there is.

What is the name of your web site so I can tell my neighbors to avoid it?

[Jim S]

Speaking as an employee of a modern agri-business company, using web2py, from the midwest, with windows xp a distant memory, I can tell you that your stereotypes are pretty far off.  Seems to me there is a lot of tall corn right down in Illinois near where Massimo started web2py.

-Jim

[Derek]

Well, according to a few searches I've done, they make specialized equipment for a very specific market. You'd probably not be one of their customers.

[Dave S]

On Thursday, August 7, 2014 7:43:57 AM UTC-7, Jim S wrote:

Speaking as an employee of a modern agri-business company, using web2py, from the midwest, with windows xp a distant memory, I can tell you that your stereotypes are pretty far off.  Seems to me there is a lot of tall corn right down in Illinois near where Massimo started web2py.

-Jim

Well, if they are running Centos or RedHat, then they are a good step back from the bleeding edge.  But I'm not really in a position to toss pebbles; I only retired my Ice Cream Sandwich phone this spring, my laptop is a 3 year-old i5, and I use a Fedora 16 system as a key workstation.  And since I'm no good at maintaining heavy machinery, I use duct tape rather than baling wire.  No XP, though, and I have at least used W8.1 in the lab.

(Not sure how edgy AIX/AS400 users are ... but I do remember the commercials IBM put out a couple of Olympics ago.)

/dps


 

[LightDot]

Bleeding edge in terms of enterprise means something completely different then on a personal device. If they are running CentOS or Red Hat or Scientific Linux then they are a good step towards running a solid enterprise IT system, so good for them. In their case, beeing bleeding edge means testing available alpha and beta releases of those OSes as they emerge, instead of adopting a couple of years after a stable release.

On the other hand, for a personal device, being bleeding edge and keeping one's sanity at the same time means running Arch on a laptop. If the sanity requirement is omitted, one can go with Slackware. The danger is, one's head might overload with GNU/linux knowledge enough to spin and explode. Well... in any case, Fedora is for sissies. :)

Anyway, seriously, Fedora isn't bleeding edge for more than a pre-alha to alpha period. Then it gets boringly stable. Which is a good thing if you need to have some actual work done.

Being sane and bleeding edge at the same time is also running web2py from the trunk. I usually look at the last commits and sometimes skip an update or two, but most of the time I don't use anything else than trunk everywhere. Which probably means web2py's public releases could be a lot more frequent.

Regards