[hippich]

I am working on a large app based on angular (not my decision - I voted against it :)), and felt many pain points already, from poor design overall, to crappy extensions most of the currents apps are using.

It Kinda reminds me whole Wordpress thing. Really subpar codebase - but at the same time very easy to make simple things, and as a result - a lot of popularity. And this comes not as surprise to see so many blog posts comparing Angular to jQuery...

But perhaps this bothers me the most - https://www.youtube.com/watch?v=X0VsStcCCM8#t=745

Guy behind framework openly admits he did not really pay attention to what other frameworks were doing (and Ember used to be Sproutcore and went through similar observe-loop pains in the past.) He just transferred his Java-server-side-MVC experience ($scope/$context - these are very distinct server-side MVC concepts) as is to the browser, which, as turned out, not quite well suited for long living in-browser apps..

And then whole dependency/packaging mess. There were already solution and tooling in place for AMD - but he decided to reinvent it, and as a result integrating any serious building process is a pain (i am not talking about 1 page apps here, i am talking about apps with 10Mb of JS code bases.)

While this all workable, and this is what I do at my day job, this should not be necessary. I call it "bullshit job" just like many "create report" type of jobs - where no real value is created.

If you know 100% that your app will never grow outside small prototype - go for it, otherwise either have plan in place to redo your app in sane framework, or do your app in sane framework from the start.

[wuliwong]

Currently, all our javascript apps use Backbone and a few use Marionette. I'm a fan of Marionette but certainly no evangelist for it. For me, it really soothes the main pain points I had with Backbone. All that being said, we are about to be forced to use Angular on a big new directive and will even have to re-write some of our old apps with Angular. I am very worried about this.

[hippich]

I went through exactly the same thing during last year. And if you liked backbone/marionette combination, you very likely hate angular :) BTW, make sure decision maker knows that Angular 2.0 should be released soon and there is no upgrade path between 1.x and 2.x :)

[marcofiset]

What would be a sane framework? Every one of them seems to have many pain points, and every other developper tells you should use X instead of Y because Z.

[hippich]

I specifically did not mention any names to not trigger flamewar. And mentioned Ember only in relation to the video.

For me personally it is Backbone (very minimal skeleton-like framework), view/binding library I like today (and can switch tomorrow) and routing I probably write myself for specific use case.

If this is too "low-level", next what I will check in "higher level" framework - as least "magic" as possible - i.e. explicit getters and setters with current state of Ecmascript, clear rules on how and when rendering happens, debuggable views (which often means views being compiled into JS.), being able to split large application in pieces which get loaded on demand without hacking/monkey-patching framework, being able to use jQuery if I want to, and not include it if I don't need it.

Sorry, no specific answer to your question, as I think it is problem specific, and even Angular can be used in some limited cases as it turned out.

[_asummers]

> debuggable views

One thing I've found while doing Android dev is that views should exist as an immutable collection of state (POJO in Java), and there should be some mechanism to inflate a view from that state. I'm not sure how Angular or Backbone deal with this, but that switch simplified the logic a great deal and made testing straightforward.

[hippich]

this is idea behind handlebars templating - ideally, no logic whatsoever and you just supply object with data to render. But in reality it gets more complicated than that and sometimes you need to debug templates too. Unfortunately, debugging angular templates is pretty much hell (mostly because of all the "magic").

[_asummers]

The way Square's library Mortar handles it in Android is that you essentially have a Model-View Model-View-Presenter sort of situation, where your View Model is JUST your data, your View is JUST the view logic, and the Presenter takes care of knowing how to inflate/deflate the view. It's pretty clean if your design is clean but can get hairy easily if it isn't; that's a feature not a bug for me.

[shubhamjain]

I would suggest an exercise which my senior suggested. Take a look at what very successful websites use. I looked at the code of Facebook and the simplicity of their code fascinates me.

The only thing they seem to use is react, a requirejs like module system combined with an EventEmitter. I still don't understand the need of three layers of abstraction on the front-end level. I would love to be proven wrong, but that seems outright over-engineering.

[jackweirdy]

Don’t make the mistake of assuming there’s a “Right Number” of levels of abstraction. Their suitability is based on how clearly they help you interact with a system whose implementation you don’t care about.

That’s a totally human quality metric, which you can’t enumerate.

[kawera]

I would suggest you spend a few minutes reading about Twitter's Flight[1]. We've been using it for a year and it's been a pleasure.

[1] https://flightjs.github.io/

[jbeja]

Purescript.

[marcofiset]

I wouldn't call PureScript a framework. It's a compile-to-JS language. It may be useful for people that already know Haskell pretty well, but I can't see why a Javascript developper would choose to use this language. It's a completely new syntax and way of thinking about programming, which you can't pick up in less than a couple of weeks at least, unless you are already familiar with a functionnal programming language.

[lomnakkus]

Purescript is a language, not a framework.