1. 34
  1.  

  2. 15

    This article put a finger in a major problem in programming.

    One one side, you can choose simples lean libraries. Using them to resolve simple problems is really easy, but once you want to use them to create a big application you are doomed to code yourself the same patterns again and again.

    So frameworks appears to fill the gap, and provide you a good architecture to organize your big application.

    There are two kind of frameworks:

    • the specialized one; they take decisions that remove a lot of your liberties. But are very efficient in their subdomain.
    • the framework that promise everything: clean organization and liberty.

    The second type of framework are from my experience complete failures. I am under the impression that Angular is in this category. Complex framework that promise everything, and therefore you end up having a lot of false complexity. Angular kind of becomes the Java J2EE of the js world.

    1. 6

      I am in no way in allegiance with AngularJs, but if you don’t mind hearing from an actual working developer who actually uses a lot of AngularJs maybe you’ll get a fair representation of it’s use as a front-end framework. I do work at a large enterprise company, and we typically use AngularJs because it’s easy to learn and pickup, and there’s a ton of documentation online on just about everything you’d like to do with a SPA. It’s well supported cross-browser, though we run into a bug or two on IE, generally there’s always an easy work around to fix it and we rarely have to deal with cross-browser issues. Generally speaking, unless you’re building something complicated, a developer can get up and running building an SPA within two weeks – as in, just about anybody, such as a junior right out of community college, can write a decent commerical grade AngularJs SPA within weeks. We rarely use services for anything other than making http calls to our API, but factories can be customized to be used in a lot of other ways. They’re the main way to share data across controllers – generally, you keep one controller per view, and share data between them using services (i.e. factories). The design pattern is meant to be simple, so it’s easy to pick up quickly. So far, we’ve seen nothing but success from AngularJs. It hasn’t failed in any significant way since we’ve started using it a year and a half ago, and it’s significantly reduces dev time (and therefore costs).

      I haven’t had the opportunity to use ReactJS on a significant project, but I notice it’s used a lot by the consulting/developers-who-blog community (as opposed to the working community). From a technical stand point, it looks a lot more flexible, in the sense that it isn’t an MVC (or uses any pattern for that matter), and all extensions are components that can be added on an as need basis. I’ve also read that Om renders faster than angular/ember/backbone. It’s probably a very good tool for building SPAs, but it also looks like it has a stepper learning curve – from my initial impressions of it – though like I said – I haven’t had the chance to use it on anything significant yet.

      I wouldn’t say I’d use AngularJs for everything – I’ve noticed most of Google’s products haven’t been written in Angular, but if you are building a significantly important enough project – I’d probably go the route of not using any framework at all and use all custom JS period.

      Honestly, articles like these are very silly. His opinion was based on a pretty shallow early impression of something he barely knows anything about – yet it still elicited 300+ comments. The fact that someone can write an blog article with a title like “you have ruined javascript” and evoke so much attention disappoints me.

      I think skepticism is a natural healthy reaction towards any system, but I think the issue revolves more around the abuses of big business than the specific technology and technical issues at hand. Also, I think there’s way more excessive crap being built for ember these days within the open source community – from what I’ve noticed around the internet….

      1. 3

        From the technical point of view, Angular if far from being the worst. I came from jQuery land and used Angular for some slightly complex dashboards. Angular was great to use then. Mostly because at the time the documentation was mostly inexistant and we have chosen to use only a small part of what angular propose.

        Now we switched from Angular to React, more precisely reagent. Which make a double jump, one from Angular to React the other from javascript to Clojurescript. While reagent is still not perfect it is far better to use. The actual application is far more complex than before. But with reagent we minimized our boilerplate, and administrative decisions comparatively to Angular.

        So yes, Angular is good, and easy to learn. But reagent is better and easier to learn.

        Actually if I had to choose, I believe I’ll give a chance to elm (elm-html + ports more precisely). Until here the elm concepts feel really adapted to big applications and interoperability with external resources.

        So the technical point is, yes Angular is better than jQuery, lighter than ember, but React is better than Angular, reagent better than just React, elm apparently better than reagent.

        Now, my remark wasn’t only valid for frontend frameworks. But more generally in the “framework vs library” debate, framework are great if they specialize on a narrow domain and don’t try to generalize their concept to all domains. If you don’t know where you’ll end up, chances are libraries are the way to go.

        If you try to make your framework play out of its specialized garden, then you soon start to create a bunch of new organizational concepts. Generally at the end of the day, your framework will look like an insane administration.

        While Angular is far from being the worst, there are better alternatives. Because I sincerely believe that elm is easier to learn and master than Angular (if you aren’t afraid by a new syntax).

        1. 2

          From a technical stand point, [ReactJS] looks a lot more flexible, in the sense that it isn’t an MVC (or uses any pattern for that matter)

          You keep using that word. I do not think it means what you think it means.

      2. 7

        I would enjoy this article a lot more if every other word was not an expletive…

        1. 2

          So much wailing, so little code

          1. 1

            loved the ode to jquery in the comments. sample quote:

            And it’s just a function that spits out adapter/decorator objects for the DOM. But damn is it a nicely written tool. Elegant, powerful, robust, performant (yes, really) and absolutely crystal clear. It made everything that was a headache about the DOM go away without burying what you were actually doing assuming you knew what you were doing in the first place.