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). On Tuesday, June 10, 2014 5:14:03 AM UTC+3, 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, 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 Monday, 9 June 2014 07:01:39 UTC-5, Ramos wrote: >> >> 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 >> > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
