1. 6
  1.  

  2. 3

    I used Angular2 on a project recently. I’m just not a fan; it feels way too over-engineered and complex and “the complicator’s gloves” for my tastes. Lots of ComponentServiceFactory kinds of stuff.

    1. 4

      This story buries the lede a little bit, which is that the next next major version of Angular will happen six months after the next one, and major version releases will then happen regularly every six months.

      This is either significant misversioning or absolutely insane (leaning heavily towards the latter). Having a foundational framework break your code every six months is outrageous, assuming (reasonably) that they won’t keep a dozen different mutually-incompatible versions in support.

      1. 3

        I hope it translates into dropping deprecated features etc. every six months. They’re talking about having a higher emphasis on compatibility going forwards (and not adding new features if they can’t add them compatibly, keeping changes much smaller than angular 1 -> 2), so hopefully it shouldn’t mean breaking compatibility willy-nilly. At the same time maintaining 100% compatibility is virtually impossible in a language like Javascript, so any version with changes probably technically needs to be a major version.

        1. 2

          Having a foundational framework break your code every six months is outrageous, assuming (reasonably) that they won’t keep a dozen different mutually-incompatible versions in support.

          Having “breaking changes” batched up so that they only happen every six months is not at all the same thing as having the framework break your code every six months. In Angular 1, most releases had “breaking changes,” but the vast majority of actual applications continued to work just fine on the newer versions. That seems to be the intent here as well.

          I suggest looking at the official release policy, particularly the deprecation policy.

          1. 1

            Having a foundational framework break your code every six months is outrageous, assuming (reasonably) that they won’t keep a dozen different mutually-incompatible versions in support.

            I see this merely as confirmation that they still don’t have the slightest idea what Semantic Versioning is.

          2. 2

            “The Angular team plans to switch to using TypeScript 2.1 or even 2.2 from 1.8 that is currently used now. That will involve some breaking changes which means introducing a new major version.” – this is going to end up like Scala (incompatible libraries inbetween versions), where the problems of the language/platform leaks into the projects that use it. Strict typing is not a bad idea for such a big piece of software, but I’m surprised they didn’t choose closure-compiler instead of TS, especially given these significant drawbacks.

            1. 1

              I’m not sure that I follow. TypeScript itself is one of the easiest dependencies to update for an Angular app. In most cases it would just be npm install typescript@latest --save-dev. What difficulties are you foreseeing?

              1. 1

                The breaking changes between 1.8 and 2.1 are actually cases where the type inference got better. So you’re most likely going to be catching more bugs (though perhaps some of your extra-dynamic code will require a couple more casts now)