|
Scaramouche posted:Can one of you skinny jeaned guys chime with why the Yahoo redesign is so terrible? On my Nexus 4/Nexus 7 it takes over a minute to render the mobile version (showing FOUC the entire time). mobile.yahoo.com seems to be pretty fast, actually. The new slate site, on the other hand is a buggy, ugly shithole. I'm a fat man in stretch pants, though, so I probably don't know what's going on. I'm glad this thread is around but it seems like it could get hard to navigate pretty fast. Maybe we should tag posts that are about a specific framework with a /angular or /ember at the top just so it can be easier to jump/skip through them. On the topic of Meteor, a lot of people got really silly about  INSECURE BY DESIGN when it was first announced. Obviously they're not going into release with a framework that freaking dumps your whole database to every single client that ever connects. It's silly to even assume that anyone would plan to do that.This screencast explains how Meteor does authentication at the moment. The vision they have for the platform looks amazingly sexy and full stack reactivity is mind-blowing(changes in the database automatically push to all clients connected to it, if they're authorized to see those records). As far as I can tell if Ember+<some persistence layer+a server> and Meteor are pretty close in their final objectives. Ember itself seems to be more polished than the Meteor front-end stuff and Meteor's MongoDB integration seems better than Ember Data. But EmberJS can just use a Rails backend, which is what Discourse does. I'm just beginning to learn about Ember and Meteor, so I'll definitely be keeping an eye on this thread. Goons that have experience with any of these frameworks in production: What types of sites do you use them for? What's your production stack look like? Workflow? Testing tools?
|
#
¿
Sep 24, 2013 23:17
|
|
|
|
| # ¿ May 7, 2024 06:00 |
|
|
The Insect Court posted:It uses its own packaging system, but apparently in recent releases they've improved npm compatibility a lot. My biggest complaint so far is that it's very "opinionated". There's no (supported) way to use anything other than mongodb on the backend, or Handlebars on the front-end. I'm also vaguely concerned with performance, since it seems to push a lot of data in response to changes in tracked queries. Any npm package can be used with Meteor, it just needs to be wrapped in a Meteor package(which just means require it and add some extra configuration stuff Meteor needs). Their roadmap to 1.0 and beyond looks pretty cool. The platform is opinionated because they wanted people to be able to build stuff with it. The main concern I have is the low focus on testing and the possibility that it might never actually be fast enough. I get a Google Wave sort of feel from Meteor. Super exciting, but maybe well ahead of its time. That being said they have years to get this stuff done properly. Whether they succeed or not, I think they'll push the industry in the right direction. They're stance on things like authentication is particularly refreshing. No, their default one line FB/Google/Whatever auth system isn't going to work for everyone. But they're treating user account management as a basic responsibility of the framework, which I think is a step forward from Rails(which itself has a pretty hassle free authentication/roles setup, once you're familiar with 3-4 gems).
|
|
#
¿
Sep 25, 2013 12:01
|
|
|
duck monster posted:Personally I would fire any programmer that told me ACID guarantees are not "super important". Playing chicken with your data is how companies get killed. How is one playing chicken? As far as I know NoSQL compromises ACID by being more relaxed about Consistency, ie. IF you have multiple shards, updates won't instantly show up in all shards. I hope I'm not missing a crucial flaw. It's not like NoSQL databases randomly and unexplainedly lose data. That was just a silly myth.
|
|
#
¿
Oct 7, 2013 16:27
|
|
|
Trying to build an Ember app on top of an existing API and I am having the most absurd problem. I want to authenticate certain routes. I've managed to grab the authentication token from the server and now I want to place it in X request header for every subsequent ajax call. How the hell do I do this? I try to call Ember.$.ajaxPrefilter and use a global variable to pass it from the controller to the function call(since I can't access controller variables in the prefilter call. For some reason). Doesn't set a header. I try to add a field to the json request sent to the server. Doesn't seem to be possible? Every google search seems to send me to an Ember-auth tutorial. I really don't want to implement 5 million gems when the entire auth process should involve passing one bloody variable from a controller into a json pre formatter.
|
|
#
¿
Dec 11, 2013 13:51
|
|