Another similar (though somewhat less mature) option is 
Derby<http://derbyjs.com/>(also built on Node.js). Advantages over Meteor are 
two-way data binding 
and the ability to render on the server as well as the client (for search 
engine crawling and faster initial page loads).

Anthony

On Thursday, April 18, 2013 1:20:57 PM UTC-4, Ramos wrote:
>
> as i understood , the discussion seems to be the around single page apps 
> that have its code in the client and then just push/pull data from the 
> server.
>
> meteor takes care of this problem and we just have to subscribe to changes 
> in reactive data sources.
> Its less code to worry about. No ajax! Just works! The client keeps a 
> local copy of the mongo database that gets sync with server.
>
> The way i see it, its "AWSOME". 
> Now you try to convinve me otherwise. :)
>
> Best regards
>
> António
>
>
>
> 2013/4/18 Derek <sp1...@gmail.com <javascript:>>
>
>> What's the question that it's supposed to answer?
>>
>>
>> On Thursday, April 18, 2013 8:13:55 AM UTC-7, Ramos wrote:
>>
>>> is meteor the answer?
>>>
>>>
>>> 2013/4/18 Magnitus <fbunn...@hotmail.com>
>>>
>>>> I'm not even sure I'll go with Angular myself at this point. I'll delve 
>>>> more deeply into that framework once I feel I have a sufficient grasp of 
>>>> Ember.
>>>>
>>>> For the whole server-side dynamically generating client-side, I'm 
>>>> afraid it's not my vision.
>>>>
>>>> The direction things are moving toward is to move away from the server 
>>>> dynamically generating client-side and rather have the client-side 
>>>> generate 
>>>> itself using data it gets from the server.
>>>>
>>>> I've done both and I find that having the client-side generate itself 
>>>> is the cleaner approach in the end (though it probably has a steeper 
>>>> learning curve, unfortunately). In essence, it makes the "V" part of MVC 
>>>> more trivial for the server and moves more of that logic on the 
>>>> client-side 
>>>> where I think it belongs.
>>>>
>>>> The way I'd see web2py supporting "widgets" is simply to provide some 
>>>> protocol (currently via ajax) that the client-side expects from the server 
>>>> to update itself. Maybe also javascript files for different frameworks 
>>>> (vanilla jQuery, Ember, Angular) if you want some pre-made solutions so 
>>>> that web2py can be as interoperable on the client side as it is on the 
>>>> backend (where you can choose from many different servers and databases). 
>>>>
>>>> On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, April 16, 2013 10:38:11 PM UTC+2, Magnitus wrote:
>>>>>>
>>>>>> Well, basically, it limited the usefulness of the form facilities and 
>>>>>> the tight default integration between authentication and the rendered 
>>>>>> pages 
>>>>>> took some time to bypass and then there was stripping the layout.html 
>>>>>> file 
>>>>>> to it's bare essentials.
>>>>>>
>>>>>> Overall, I've always been much happier to use web2py for it's 
>>>>>> server-side features and let it be a flexible interface with which 100% 
>>>>>> custom-made client-side code could interact.
>>>>>>
>>>>>>  
>>>>> yeah. the real problem is that no-one working on angularjs is making 
>>>>> public its own widgets. 
>>>>> All that it takes is overloading SQLFORM.widgets and given that we 
>>>>> ship web2py with a formstyle parameter that can be a callable from some 
>>>>> time, all that is needed is something that generates angular templates 
>>>>> out 
>>>>> of models (and someone that is willing to do it). 
>>>>> Once stable, that formstyle can be included in standard web2py and the 
>>>>> "newwidgets.py" module shipped in gluon/contrib.
>>>>> then SQLFORM(thetable, formstyle='angularjs') will be all what's needed
>>>>>
>>>>> Right now I don't have any interest in angularjs so I call myself out 
>>>>> of the competition, but feel free to pack a starter app and I'll be more 
>>>>> than glad to review the code.
>>>>>
>>>>>
>>>>>  -- 
>>>>  
>>>> --- 
>>>> 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/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>  
>>>>  
>>>>
>>>
>>>  -- 
>>  
>> --- 
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 

--- 
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.


Reply via email to