I agree that it does seem right now, that the current trend in the web-development world, in general, is moving in the direction of transferring more and more tasks to the client, as those become more and more capable.
But I wouldn't bury web2py just yet... (nor any other server-side framework for that matter) As in the WebSockets story, the current temporary "Hype" is exaggerating the perception of the long-term eventual-effect. I think server-side frameworks are here to stay - at least for the foreseeable future - it's not gonna be an "all or nothing" transference in all cases, not even in most. It is still much harder on the client, even with things like Ember - especially considering the whole cross-browser/platform story. The whole "Google" thing about - "everything going to the web"... I don't buy it - not yet. Google-Docs is an amazing idea "in theory" - in practice, it's a buggy mess of crap... (and in Google's own chrome, for f#ck sake...) Most simple applications, websites, etc. are not as complex as, say, an Intranet business applications (such as the one I've been working on for the past 3 years) - which is a market still dominated by desktop applications. But yes, the expectations are changing... Slowly... I think it's going to be a long and "hybrid-ridden" transition. For now, I've seen talks about how to maximize loading time, template-rendering can be done on the server, even for desktop usage - and that's rendering to plain HTML, not a JavaScript Object-Tree - so it can still be done in web2py. Once the static HTML loads, the framework then kicks-in, and starts climbing and crawling over the DOM, attaching itself and building it's JavaScript-Object-Tree and injecting dependencies into the DOM and such... There are frameworks that go that rout - don't know to what degree Angular or Ember are in this category, though... The main incentive here, other than speeding-up loading time, is the whole SEO story... (search-engine-optimization) Search-engine crawlers/spiders need static HTML to search in - if the entire thing is Javascript-generated, it is virtually unsearchable... And no web-site owner wants that... Only Intranet applications don't care about such things... Then there's this thing about resources, RESTfull'ness and ORMs... I think that web2py's models and controllers will remain relevant, as there is a difference between the model of the data in it's view's usage, and the model of the data in the database. Most of what the controllers are doing in web2py, in my experience, apart from querying the DAL, is data-manipulation - translating one data-model into another, to meet the needs of the views for optimal and elegant usage. This role can stay in the server, as in some cases, much less information has to go through the wire this way. Can this be done in the client's controllers? Maybe. But I'm not sure it should - not in all cases. I think it might actually be easier for a client to deal with a data-model that is already structured in a manner that most fits the need at hand - and have that be CRUD'ed in that form. A client's MVC component shouldn't care how the data is actually stored on the database - it can request it's resources in a form that is already pre-transformed and structured especially for it's needs. So what you can do, is have the starting-point server-side portion of the URL of each screen, still be of a web2py controller, which would then either be transferred via a web2py view if it's a full-refresh/first-time-load, or as a JSON resource in an AJAX manner is all other cases. In both scenarios, the web2py's controller's role would be to query the DAL and optimally translate the data for the client's screen - for the GET method, and do a reverse-translation for the POST one... So here's what I see: I see a diverse web-development world, with varying degrees of server-side logic usage, in some cases dynamically switching from server to client and back, based on needs, requirements, trade-offs criteria, and target-platforms. -- --- 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/groups/opt_out.
