> > Iy is not going to work in the foreseeable future, for many web-apps to > hold their entire database on the client side...
Are you talking about the model definitions, or the actual data? They certainly don't move all the data in the entire database to the client. > For simple and small web-sites, that may work out, but once you get pass a > certain level of complexity, and have hundreds of inter-linking tables, > then in most of these cases it would make no sense having an identical data > model in the client - it would be horobly wastefull and inefficient to the > point of being unusable. At least Derby allows for server-only routes and models, in addition to whatever is on the client. > Also, the client-side is still very lacking in terms of options > of handling and handling relational data-models. > I've noticed these frameworks tend to be geared toward document-based datastores, like MongoDB, rather than RDBMS's. > In short, it would fit a very, well, (ahm..) "boring" target-audience... > (no offence...) > Not for complex web-apps. > Not sure how complex these are, but they don't seem trivial, and certainly not "boring": https://unroll.me/ https://www.habitrpg.com/static/front I predict that this would be the model that would emergent to be > the dominant one - you already see glimpses of it - Google Wave was an > example - even long before web-sockets and data-store on the client. > Interestingly, one of the Google Wave developers went on to create ShareJS and now works on Derby (which is incorporating ShareJS). Anthony -- --- 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.
