4 ms·

I feel Angular is better than almost everything out there but still not quite right. It seems way too complex for what it does, and the syntax looks like somebo

I feel Angular is better than almost everything out there but still not quite right. It seems way too complex for what it does, and the syntax looks like somebody vomited all over your code. Does two-way databinding have to be so awkward? Angular does help you in writing maintainable code (which is vital for JavaScript - dealing with large JS codebases is hard), but it also ties you to a technology which is probably transitional. I have high hopes for 2.0, and I hope they work out these issues.

KajMagnus 12y ago
Have you seen React.js (http://facebook.github.io/react/ http://facebook.github.io/react/) and Mithril (http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/)? They're supposedly smaller, faster, and easier than Angular, and does roughly the same things, as far as I've read. And they support server side rendering. At least React does.
- skeletonjelly 12y ago
  React is just for presentation though (the V in MVC)
  - Renaud 12y ago
    But React + Flux is an alternative to MVC. Still early days for Flux, but the principles are sound and I hope it offers a viable alternative to all these framework that rely mainly on variants of the MVC pattern.
    - Kiro 12y ago
      Flux seem so overcomplicated I can't believe what I'm seeing.
      - colinramsay 12y ago
        I think Flux is probably very simple, it's just been presented very, very poorly.
        Kiro 12y ago
        Do you have any good tutorial that presents in a better way?
        andwaal 12y ago
        Check out https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs better explained and more elegant implemented( no string dirty-checking for one).
        colinramsay 12y ago
        I agree with andwaal that reflux is the simplest way so far that I've seen. I think what is really lacking is a demonstration application which isn't just "hello world" or the standard todo app rewritten in React. I just don't find that helpful. For another overview, see this article: http://blog.andrewray.me/reactjs-for-stupid-people/ http://blog.andrewray.me/reactjs-for-stupid-people/ Please don't take offence at the title, I didn't write it :D
      - mercer 12y ago
        Perhaps Reflux is better for your purposes? https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs
      - o_____________o 12y ago
        The overcomplication (relative to what could be) is due to boilerplate and poorly defined convention for anything but the canonical todo app. It's early days. There are some frameworks using some form of the Flux spec like Fluxxor and Reflux, but they're not opinionated or complete enough to hit the ground running. The author of Fluxxor, for example, is himself working out where to put very basic functionality like network service calls. In the react-router project, there's not an obvious way to either render from server or refetch data on route changes. This is all very basic functionality for a medium to large project. It will feel like you're in the weeds after a couple of days of development. We need a Flux++ framework with some stronger opinions, closer to Ember or Angular in scope.
- rmsaksida 12y ago
  Thanks for mentioning Mithril, I didn't know about it. It looks very interesting. I've been meaning to try React.js for a while now, just haven't found the time. About Mithril, HTML generation with JavaScript is an odd design choice. Obviously it's much better from a technical point of view, but nested or complex HTML must get ugly fast, and I really don't want to deal with template code written by non-developers. Having said that, for a certain class of apps with high performance requirements and comprehensive browser support, Mithril is a very appealing option.
  - insin 12y ago
    > but nested or complex HTML must get ugly fast That's the problem JSX solves - nesting tags and attributes is less syntactically onerous than managing a tree of function calls or nested object structures, with their attendant braces and commas. Here's the Mithril getting started example [1] done using JSX [2], for comparison (some of the other code has changed since I did this, but the rendering part looks the same) [1] http://lhorie.github.io/mithril/getting-started.html#summary http://lhorie.github.io/mithril/getting-started.html#summary [2] https://github.com/insin/msx/blob/master/test/jsx/example.jsx https://github.com/insin/msx/blob/master/test/jsx/example.js...
    - kallussed 12y ago
      I like JSX, but I would say that Mithril + CoffeeScript is even nicer. A coffeescript example (not mine): http://www.reddit.com/r/javascript/comments/20pzbj/mithril_a_javascript_framework_for_building/ckfgfey http://www.reddit.com/r/javascript/comments/20pzbj/mithril_a... or https://github.com/Whoaa512/mithril-coffee-gulp-seed/blob/master/app/scripts/components/MyComponent.coffee https://github.com/Whoaa512/mithril-coffee-gulp-seed/blob/ma... Looks really clean...
JDDunn9 12y ago
> Does two-way databinding have to be so awkward? The verbose parts have nothing to do with the data-binding. The dependency injection is there for testability (https://docs.angularjs.org/guide/unit-testing https://docs.angularjs.org/guide/unit-testing), you have to use array notation because JS changes variable names upon minification. The rest is just objects being used to set up options.
- andybak 12y ago
  JS doesn't change variable names upon minification - minifiers do. For the dubious benefit of saving probably less than 5-10% of a transfer we've decided it's worth repeating ourselves pointlessly. Fix the minifiers.
  - ahoge 12y ago
    > Fix the minifiers. Most minifiers have a switch for that. E.g. UglifyJS2's is "-m"/"--mangle". YUI Compressor's is "--nomunge". By the way, this stuff looks a lot nicer with AngularDart or Angular 2.x.
- Cthulhu_ 12y ago
  Array notation is only required if you're not actually up to date on modern build tooling - ng-annotate [0] will automatically generate array notation DI statements in most of your application code. [0] https://github.com/olov/ng-annotate https://github.com/olov/ng-annotate
noelwelsh 12y ago
I prefer React to Angular -- I find it much simpler to work with. I wrote up some thoughts here: http://noelwelsh.com/programming/2014/08/17/angularjs-vs-react/ http://noelwelsh.com/programming/2014/08/17/angularjs-vs-rea...
- xsace 12y ago
  Used both a lot. I agree the above statement.
lukasm 12y ago
I had the same feeling, but after 6 months is seems more natural than jQuery. It's kind of like git. You have to change your mindset coming from SVN.
- deleted 12y ago
  [deleted]
holic 12y ago
I felt the same, and then I found Vue: http://vuejs.org/ http://vuejs.org/
Cthulhu_ 12y ago
How are you finding it awkward? It's the simplest way of getting data into a template that I know of - assign a value to a scope and done, no hassle. And vice-versa, too. (disclaimer: I come from Backbone, where we did all data and event binding by hand)
- rmsaksida 12y ago
  Sorry for not clarifying. What I find awkward about it is the Angular-specific baggage and the syntax, which just got more complex. Stuff like ng-model-options="{ updateOn: 'blur' }" is far from straightforward. I guess you could do ng-model-options="model.modelOptions" and define the behavior in the controller, but then your controller would be handling far more than it should. By the way, wouldn't a separate directive be more appropriate for this? ng-update-on="blur" is more palatable. And in my experience with Angular, it's never just "assign a value to a scope and done", except for the most trivial situations. When you leave these behind, you have to think about scope hierarchies. You have to watch your watchers. When you use something like angular-translate, you have to carefully consider synchronicity issues and the performance drawbacks of each way to bind your models. And so on. I love the power and flexibility that Angular gives you, but I wish there was a simpler way for it to do its magic.
  - cloakandswagger 12y ago
    >When you leave these behind, you have to think about scope hierarchies. Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance >You have to watch your watchers What? >I wish there was a simpler way for it to do its magic. To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular)
    - rmsaksida 12y ago
      > Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance Obviously, but you shouldn't have to care about prototypical inheritance for simple databinding. The way view-models work in Angular leads to some complicated scenarios which, in my opinion, shouldn't exist in the first place (http://toddmotto.com/all-about-angulars-emit-broadcast-on-publish-subscribing/ http://toddmotto.com/all-about-angulars-emit-broadcast-on-pu...). > What? See https://medium.com/@kentcdodds/counting-angularjs-watchers-11c5134dc2ef https://medium.com/@kentcdodds/counting-angularjs-watchers-1... for an explanation. > To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular) I have no problem with learning framework specific syntax and Angular is actually lightweight, both from an architecture and from a code weight point of view. What I do find problematic in Angular are some design decisions which often lead to complicated, and non-beautiful, code. Angular is no doubt incredibly useful, even for smaller apps, and I'm grateful for its existence. It is a step in the right direction. But I do think it has room for improvement.

KajMagnus 12y ago

Have you seen React.js (http://facebook.github.io/react/ http://facebook.github.io/react/) and Mithril (http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/)? They're supposedly smaller, faster, and easier than Angular, and does roughly the same things, as far as I've read. And they support server side rendering. At least React does.

skeletonjelly 12y ago
React is just for presentation though (the V in MVC)
- Renaud 12y ago
  But React + Flux is an alternative to MVC. Still early days for Flux, but the principles are sound and I hope it offers a viable alternative to all these framework that rely mainly on variants of the MVC pattern.
  - Kiro 12y ago
    Flux seem so overcomplicated I can't believe what I'm seeing.
    - colinramsay 12y ago
      I think Flux is probably very simple, it's just been presented very, very poorly.
      - Kiro 12y ago
        Do you have any good tutorial that presents in a better way?
        andwaal 12y ago
        Check out https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs better explained and more elegant implemented( no string dirty-checking for one).
        colinramsay 12y ago
        I agree with andwaal that reflux is the simplest way so far that I've seen. I think what is really lacking is a demonstration application which isn't just "hello world" or the standard todo app rewritten in React. I just don't find that helpful. For another overview, see this article: http://blog.andrewray.me/reactjs-for-stupid-people/ http://blog.andrewray.me/reactjs-for-stupid-people/ Please don't take offence at the title, I didn't write it :D
    - mercer 12y ago
      Perhaps Reflux is better for your purposes? https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs
    - o_____________o 12y ago
      The overcomplication (relative to what could be) is due to boilerplate and poorly defined convention for anything but the canonical todo app. It's early days. There are some frameworks using some form of the Flux spec like Fluxxor and Reflux, but they're not opinionated or complete enough to hit the ground running. The author of Fluxxor, for example, is himself working out where to put very basic functionality like network service calls. In the react-router project, there's not an obvious way to either render from server or refetch data on route changes. This is all very basic functionality for a medium to large project. It will feel like you're in the weeds after a couple of days of development. We need a Flux++ framework with some stronger opinions, closer to Ember or Angular in scope.
rmsaksida 12y ago
Thanks for mentioning Mithril, I didn't know about it. It looks very interesting. I've been meaning to try React.js for a while now, just haven't found the time. About Mithril, HTML generation with JavaScript is an odd design choice. Obviously it's much better from a technical point of view, but nested or complex HTML must get ugly fast, and I really don't want to deal with template code written by non-developers. Having said that, for a certain class of apps with high performance requirements and comprehensive browser support, Mithril is a very appealing option.
- insin 12y ago
  > but nested or complex HTML must get ugly fast That's the problem JSX solves - nesting tags and attributes is less syntactically onerous than managing a tree of function calls or nested object structures, with their attendant braces and commas. Here's the Mithril getting started example [1] done using JSX [2], for comparison (some of the other code has changed since I did this, but the rendering part looks the same) [1] http://lhorie.github.io/mithril/getting-started.html#summary http://lhorie.github.io/mithril/getting-started.html#summary [2] https://github.com/insin/msx/blob/master/test/jsx/example.jsx https://github.com/insin/msx/blob/master/test/jsx/example.js...
  - kallussed 12y ago
    I like JSX, but I would say that Mithril + CoffeeScript is even nicer. A coffeescript example (not mine): http://www.reddit.com/r/javascript/comments/20pzbj/mithril_a_javascript_framework_for_building/ckfgfey http://www.reddit.com/r/javascript/comments/20pzbj/mithril_a... or https://github.com/Whoaa512/mithril-coffee-gulp-seed/blob/master/app/scripts/components/MyComponent.coffee https://github.com/Whoaa512/mithril-coffee-gulp-seed/blob/ma... Looks really clean...

JDDunn9 12y ago

> Does two-way databinding have to be so awkward? The verbose parts have nothing to do with the data-binding. The dependency injection is there for testability (https://docs.angularjs.org/guide/unit-testing https://docs.angularjs.org/guide/unit-testing), you have to use array notation because JS changes variable names upon minification. The rest is just objects being used to set up options.

andybak 12y ago
JS doesn't change variable names upon minification - minifiers do. For the dubious benefit of saving probably less than 5-10% of a transfer we've decided it's worth repeating ourselves pointlessly. Fix the minifiers.
- ahoge 12y ago
  > Fix the minifiers. Most minifiers have a switch for that. E.g. UglifyJS2's is "-m"/"--mangle". YUI Compressor's is "--nomunge". By the way, this stuff looks a lot nicer with AngularDart or Angular 2.x.
Cthulhu_ 12y ago
Array notation is only required if you're not actually up to date on modern build tooling - ng-annotate [0] will automatically generate array notation DI statements in most of your application code. [0] https://github.com/olov/ng-annotate https://github.com/olov/ng-annotate

noelwelsh 12y ago

I prefer React to Angular -- I find it much simpler to work with. I wrote up some thoughts here: http://noelwelsh.com/programming/2014/08/17/angularjs-vs-react/ http://noelwelsh.com/programming/2014/08/17/angularjs-vs-rea...

xsace 12y ago
Used both a lot. I agree the above statement.

lukasm 12y ago

I had the same feeling, but after 6 months is seems more natural than jQuery. It's kind of like git. You have to change your mindset coming from SVN.

deleted 12y ago
[deleted]

holic 12y ago

I felt the same, and then I found Vue: http://vuejs.org/ http://vuejs.org/

Cthulhu_ 12y ago

How are you finding it awkward? It's the simplest way of getting data into a template that I know of - assign a value to a scope and done, no hassle. And vice-versa, too. (disclaimer: I come from Backbone, where we did all data and event binding by hand)

rmsaksida 12y ago
Sorry for not clarifying. What I find awkward about it is the Angular-specific baggage and the syntax, which just got more complex. Stuff like ng-model-options="{ updateOn: 'blur' }" is far from straightforward. I guess you could do ng-model-options="model.modelOptions" and define the behavior in the controller, but then your controller would be handling far more than it should. By the way, wouldn't a separate directive be more appropriate for this? ng-update-on="blur" is more palatable. And in my experience with Angular, it's never just "assign a value to a scope and done", except for the most trivial situations. When you leave these behind, you have to think about scope hierarchies. You have to watch your watchers. When you use something like angular-translate, you have to carefully consider synchronicity issues and the performance drawbacks of each way to bind your models. And so on. I love the power and flexibility that Angular gives you, but I wish there was a simpler way for it to do its magic.
- cloakandswagger 12y ago
  >When you leave these behind, you have to think about scope hierarchies. Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance >You have to watch your watchers What? >I wish there was a simpler way for it to do its magic. To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular)
  - rmsaksida 12y ago
    > Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance Obviously, but you shouldn't have to care about prototypical inheritance for simple databinding. The way view-models work in Angular leads to some complicated scenarios which, in my opinion, shouldn't exist in the first place (http://toddmotto.com/all-about-angulars-emit-broadcast-on-publish-subscribing/ http://toddmotto.com/all-about-angulars-emit-broadcast-on-pu...). > What? See https://medium.com/@kentcdodds/counting-angularjs-watchers-11c5134dc2ef https://medium.com/@kentcdodds/counting-angularjs-watchers-1... for an explanation. > To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular) I have no problem with learning framework specific syntax and Angular is actually lightweight, both from an architecture and from a code weight point of view. What I do find problematic in Angular are some design decisions which often lead to complicated, and non-beautiful, code. Angular is no doubt incredibly useful, even for smaller apps, and I'm grateful for its existence. It is a step in the right direction. But I do think it has room for improvement.