61–70 of 163 posts
I just have the "feeling" that with Discourse being written in EmberJS, people are mindlessly going to flock to it without really looking at anything else. And even if AngularJS really is better, it will be left behind. Just because...
Earlier quoted context omitted.
> 10k+ apps on each Ember, Angular, and Backbone Have you written about them? I haven't come across anyone who has enough experience with more than one of them to comment broadly.
Am I missing something? 10k apps on each, so 30k apps... meaning "30 thousand applications"? If those three libraries have each been around for ~10 years (have they?), that's like 3 apps on each per day . That seems like an awful lot...
> Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time? Yes, thats why I choose Angular over Ember every time. EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time wri…
Wait, are you saying you choose Angular for non super simple stuff? Because I couldn't even consider it due to it's lack of nested layout and routing for anything beyond something super simple.
> Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time? Yes, thats why I choose Angular over Ember every time. EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time wri…
Wait, are you saying you choose Angular for non super simple stuff? Because I couldn't even consider it due to it's lack of nested layout and routing for anything beyond something super simple.
Is there anyone out there who has written non-trivial applications (i.e. a _lot more_ than the quintessential todo app) in both, AngularJS & EmberJS and can offer a non-biased opinion? Some time ago, I started off with AngularJS, I liked what I saw (except the dirty checking part) and started building my product / startup with it. I don't have the time to stop all dev and experiment with EmberJS, but would like to kn…
Let me say to start that I'm no JavaScript expert. I don't write JavaScript full-time (we're a small company; I don't do anything "full"-time), though I do like the language and what it can do for web-based client-side programming. I've written non-trivial apps for the same backend, first in Ember, then in Angular. The Ember app is the consumer-driven frontend, while Angular runs the administrative interface. It wasn…
Not true. All Discourse content has been indexed by Google since day one. Even though it's a Javascript app it's search engine friendly.
Secondly, Stack Overflow is the official place for Ember questions. The forums are for general discussion about features and other Ember related topics. Go to SO if you have a question and tag it as ember!
Earlier quoted context omitted.
> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that d…
My question is then: why are people purposely choosing not to use the advantages of client side MVC code? You can't trust the client. Therefore a good part of the logic MUST be built on the server side. When you've had to build that logic once, building it again on the client side is a maintainability problem of exactly the same kind that you decry with Angular.js. Except worse, because frequently the client and serv…
Earlier quoted context omitted.
I'm mostly talking about sharing data in this post. If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server. Secondly, client and server interfaces are not as symmetric as you indicate. Discourse has much more validation logic on the server than the client. We generally "assume success", because the vast majority of requ…
What you're saying is interesting - I just want to make sure I'm understanding correctly. So, the app functions on its own in the client, and only checks-in periodically with the server to see if anything is not valid? (As opposed to sending a request to the server for every change.) So for example: when I submit a comment, it doesn't go to the server right away. It immediately displays successfully in my browser, an…
Ajax by definition is asynchronous. When you submit a post, the Ajax request is fired right away. But we don't wait for a response before showing the post in the stream (success case). We show it right away.
Then WHEN we receive a reply, we check the error status and if it was success, do nothing. If it failed, we revert the UI to the previous state. This is really easy with a client side MVC framework.
The downside is the failure case can be disorienting, as something will appear and then disappear. But the vast majority of requests, say, 99% never fail so the user so we optimize for that case.
Is there anyone out there who has written non-trivial applications (i.e. a _lot more_ than the quintessential todo app) in both, AngularJS & EmberJS and can offer a non-biased opinion? Some time ago, I started off with AngularJS, I liked what I saw (except the dirty checking part) and started building my product / startup with it. I don't have the time to stop all dev and experiment with EmberJS, but would like to kn…
there is no directives in EmberJS , you could use any DOM templating engine ( =/= string template engine like Mustach ) with it I guess to get something similar to directives.
Earlier quoted context omitted.
You can't possibly argue that using Backbone for models is idomatic AngularJS. If you're arguing that with a bunch of extra code on top of AngularJS it does what Ember does out of the box, that was kind of my point.
...fair. What's your take on points #1, #2, #3 and #5?
What you are suggesting is good practice but something that I suspect very few Angular developers do as it's not encouraged by the framework itself.
If you follow the guides on the official Angular site, they're done none of the things you suggest.