7 ms·

As a gentle reminder, Fred Brooks said "there are no silver bullets" in software (http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_

by yajoe 13y ago

As a gentle reminder, Fred Brooks said "there are no silver bullets" in software (http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet ). Even without knowing the details of this article, I believe it's unlikely that "not even close" is at all accurate. There likely are advantages, but from my experience (10k+ LOC apps on each Ember, Angular, and Backbone) no one MVC (or MV-) framework is inherently better. They all have serious tradeoffs that SO has done a much better job documenting. One nit from the essay: the author comments on the missing 'model' from Angular and provides an example of a computed property to illustrate this. 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. Angular (err Restangular to be specific) has a way to do this with less code and an aesthetic (data binding in HTML) that I personally like. If, however, you were writing code that needed the client to have a lot more business logic (i.e. computed properties, browser local storage, etc) then something like Ember would be a better choice because of its 'Model.' A lot of shit crud apps, however, don't need that much business logic in the client (at least for an MVP), and that would be my narrative for why Angular appears more popular. That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use (gallery of 1000s thumbnails). He should disclaim that YMMV. Neither is inherently better, and both teams working on them are full of smart, quality engineers that understand these problems in ways I never will.

prollyignored 13y ago
This is something else. I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles" <template> Is X trying to change the paradigm ? No. Use Y. Is Y trying to change the paradigm ? Yes. Use Y </template> Some dumb geeks just can't handle "worse is better" !
EvilTrout 13y ago
> 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 don't embrace it. > That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications. If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!
- btilly 13y ago
  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 server are different languages and so are harder to keep in sync.
  - EvilTrout 13y ago
    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 requests do go through correctly. So if you submit a spam post for example, we'll show it in the client side view right away, but once the server asynchronously replies a failure, we'll display an error message and remove it. This can be jarring in the case of a failure as you'll see something appear then go away, but the vast majority of the time it doesn't happen. The client side interface should do what it does best - display stuff quickly and avoid server round trips as much as possible.
    - SolarUpNote 13y ago
      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, and could be submitted to the server 2 seconds from now, or something?
      - EvilTrout 13y ago
pbiggar 13y ago
> 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.
- beambot 13y ago
  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...
  - pbiggar 13y ago
    I read it as 10KLOC.
  - yajoe 13y ago
    I forgot to write LOC after 10k; my point was that each app took longer than a weekend to write and I had to deal with at least one wart in each framework.
    - beambot 13y ago
      Ah, that makes much more sense! Thanks for the informed insights. (To the people downvoting my previous comment: wtf?! Politely questioning someone's stated experience when it borders on absurdity is perfectly valid. And the GP provided a perfectly reasonable explanation: s/10k+ apps/10k+ loc apps/.)
- yajoe 13y ago
  I'm definitely not qualified to provide an opinion. My short summary: Backbone was tiring for me and my partner with all the files and code to set up each view. I also never liked putting templates in script tags -- it just felt dirty. We see Ember and Angular as similar (how do you pick which language you like?), and we only picked one for atheistic reasons (data-binding in HTML) in our current project. Since I haven't written the same app in each framework, it would be unfair to comment further.
ilaksh 13y ago
What a cop-out. I am pretty sure you prefer Angular but are just too pussy to say it. Maybe you think people will think less of you for preferring the framework that is less complex. I assumed 'not even close' would mean this guy would be siding with AngularJS. Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better. What I think is that deep down people are afraid that others will think they weren't smart enough to figure out the more complex and difficult to use thing. What I am sure of is that a system that is less complex and easier to use is better engineering.
- pbiggar 13y ago
  Please turn down the dial a little bit. Calling a stranger a pussy may be the norm on the internet at large, but it's not appropriate here.
- d0m 13y ago
  >> What I am sure of is that a system that is less complex and easier to use is better engineering. I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web. I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks. Part of the problem, I believe, is the way I learn. I usually read a quick tutorial, hack a little bit, read a bit more, hack more, read the full documentation, hack a real project (and getting into the wire of the API at this point). It's a bit oversimplified, but I believe you get the picture. However, with Ember, it seems to me like it's hard to get started and running without having a full understanding of the full system and how everything fits together. So yeah, in the end, maybe if you know every part of Ember and how it intrinsically work, then that's an awesome framework to work with. But for the others, like me, who learn in a more spiral-ish way, I think Ember makes it very hard to get shit done and appreciate the value of the framework. And please, don't get me wrong, I admire programmers who can read the full documentation first.. A good analogy might be the manual (man) on Linux. I know people say RTFM all the time. But for me, it's really more about googling non-stop to get a feeling on the quickest solution for my problem. I guess it's just a different way to learn and approaches solutions to problem. I know a couple excellent programmers who would just go reading the man and figure everything by themselves. That being said, not sure why you're being so aggressive in your statements.. I feel you had very valid arguments but these are totally buried under this arrogance.
novaleaf 13y ago
thanks for the mention of restangular, i didn't know about it until now. https://github.com/mgonto/restangular https://github.com/mgonto/restangular

by yajoe 13y ago

prollyignored 13y ago

This is something else. I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles" <template> Is X trying to change the paradigm ? No. Use Y. Is Y trying to change the paradigm ? Yes. Use Y </template> Some dumb geeks just can't handle "worse is better" !

EvilTrout 13y ago

> 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 don't embrace it. > That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications. If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!

btilly 13y ago
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 server are different languages and so are harder to keep in sync.
- EvilTrout 13y ago
  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 requests do go through correctly. So if you submit a spam post for example, we'll show it in the client side view right away, but once the server asynchronously replies a failure, we'll display an error message and remove it. This can be jarring in the case of a failure as you'll see something appear then go away, but the vast majority of the time it doesn't happen. The client side interface should do what it does best - display stuff quickly and avoid server round trips as much as possible.
  - SolarUpNote 13y ago
    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, and could be submitted to the server 2 seconds from now, or something?
    - EvilTrout 13y ago

pbiggar 13y ago

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

beambot 13y ago
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...
- pbiggar 13y ago
  I read it as 10KLOC.
- yajoe 13y ago
  I forgot to write LOC after 10k; my point was that each app took longer than a weekend to write and I had to deal with at least one wart in each framework.
  - beambot 13y ago
    Ah, that makes much more sense! Thanks for the informed insights. (To the people downvoting my previous comment: wtf?! Politely questioning someone's stated experience when it borders on absurdity is perfectly valid. And the GP provided a perfectly reasonable explanation: s/10k+ apps/10k+ loc apps/.)
yajoe 13y ago
I'm definitely not qualified to provide an opinion. My short summary: Backbone was tiring for me and my partner with all the files and code to set up each view. I also never liked putting templates in script tags -- it just felt dirty. We see Ember and Angular as similar (how do you pick which language you like?), and we only picked one for atheistic reasons (data-binding in HTML) in our current project. Since I haven't written the same app in each framework, it would be unfair to comment further.

ilaksh 13y ago

What a cop-out. I am pretty sure you prefer Angular but are just too pussy to say it. Maybe you think people will think less of you for preferring the framework that is less complex. I assumed 'not even close' would mean this guy would be siding with AngularJS. Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better. What I think is that deep down people are afraid that others will think they weren't smart enough to figure out the more complex and difficult to use thing. What I am sure of is that a system that is less complex and easier to use is better engineering.

pbiggar 13y ago
Please turn down the dial a little bit. Calling a stranger a pussy may be the norm on the internet at large, but it's not appropriate here.
d0m 13y ago
>> What I am sure of is that a system that is less complex and easier to use is better engineering. I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web. I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks. Part of the problem, I believe, is the way I learn. I usually read a quick tutorial, hack a little bit, read a bit more, hack more, read the full documentation, hack a real project (and getting into the wire of the API at this point). It's a bit oversimplified, but I believe you get the picture. However, with Ember, it seems to me like it's hard to get started and running without having a full understanding of the full system and how everything fits together. So yeah, in the end, maybe if you know every part of Ember and how it intrinsically work, then that's an awesome framework to work with. But for the others, like me, who learn in a more spiral-ish way, I think Ember makes it very hard to get shit done and appreciate the value of the framework. And please, don't get me wrong, I admire programmers who can read the full documentation first.. A good analogy might be the manual (man) on Linux. I know people say RTFM all the time. But for me, it's really more about googling non-stop to get a feeling on the quickest solution for my problem. I guess it's just a different way to learn and approaches solutions to problem. I know a couple excellent programmers who would just go reading the man and figure everything by themselves. That being said, not sure why you're being so aggressive in your statements.. I feel you had very valid arguments but these are totally buried under this arrogance.

novaleaf 13y ago

thanks for the mention of restangular, i didn't know about it until now. https://github.com/mgonto/restangular https://github.com/mgonto/restangular