1. 1

  2. 8

    So it is basically saying “Angular 2 will be a success because Angular 1 was a success” or more generally stated in the article, X is successful because X’s author has been successful.

    successful(X) :- author(A, X), author(A, Y), successful(Y).
    1. 5

      Is this where we are in tech? Where it’s more about a prior reputation than actual technological advancement? I mean, we always, as an industry, choose really dumb things to get behind, but making it more about the Matthew Effect than anything else is not something to be proud of.

      I have, first hand, ridden this framework-hype gravy train.

      People get on-board instantly once you have a basic prototype. There is an entire cottage industry of devs who are looking for enormous metaprogramming monstrosities to ‘save’ them from writing a few lines of really simple code. They’re looking for someone/something to do their damn jobs for them.

      1. 5

        Well tech has been about fads for a long time, I don’t know if it is in fact worst in web development. But that said, web development seems to move a lot faster than any other area in tech that I am aware of — this would make it prone to abuse by new shiny things and consultants.

        The other thing is software development methodologies.

    2. 2

      I think we can learn from Python that this isn’t guaranteed to be succeeding it de facto, especially if it breaks compatibility.

      1. [Comment removed by author]

        1. 1

          I don’t see how you come to that conclusion. Abstracting everything as components just means that there are fewer ways of connecting modules that developers have to think about. And the view embedding is just a way of putting the template and the component in the same file for more convenient editing. The embedded view will still be only used by that particular component, so there won’t be spaghetti dependencies to worry about.

          1. 3

            When you reduce the specificity of a type of object, you remove the tools that allow you to reason about it. If you have ViewModel objects, Controller objects, and View objects, you know what each type of object is responsible for providing. If you just have Component objects, you don’t. What happens, for example, if a given component needs to decide between two different views based on criteria in its data? In the former model, I would expect that it simply retrieves a different View object; in the latter, I don’t know. Can you attach multiple “views” (i.e. templates) to a single Component? Can functions attached to the Component return views? Should a Component defer to a different object of the same type when necessary?

            If a given object can idiomatically contain any type of data, you fundamentally can’t reason about it. Even static typing doesn’t help: function foo(a: BlobOfStuff, b: BlobOfStuff): BlobOfStuff is as opaque as function foo(a, b).

            1. 3

              fewer ways of connecting modules that developers have to think about

              In my limited experience, overthinking is not an affliction I’ve seen affect Angular devs.

              1. 1


                1. 1

                  Grr, windows…. I want to see those chars. Oh well, I’ll have to check it out on my linux box when I get home.

          2. 1

            On a side note, why does everyone seem to think that insane_popularity === success, even when that popularity disappears in a year?