People are already migrating from ng2? It just came out!
ng2 final was released in September 2016, but many were using it well before then, as in the article. (first beta was in January 2016 I believe)
Why we moved from Angular 2 to Vue.js and why we didn’t choose React
121–130 of 151 posts
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#122Earlier quoted context omitted.
If you know only JS, JSX is much easier to pick up than some proprietary templating language. How do I do an if, a loop, a map, ... any code at all? In JSX, the answer is squiggly-brackets and regular old JS code. In Angular's templating system and Vue's, you've got to relearn all of these and more.
You can use JSX without trouble with Vue
Here's a link for anyone wanting to read more about it: https://vuejs.org/v2/guide/render-function.html#JSX
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#123everybody who feels so strongly about separation of code from templates - do you realize that down there it's still just bunch of string concat calls? it's literally what ERB templates in Ruby compile to, and similarly in literally every other template language. rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the r…
I love this quote straight from the vuejs documentation:
"separation of concerns is not equal to separation of file types"
https://vuejs.org/v2/guide/single-file-components.html#What-...
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#124Angular is a application framework, Vue is a view library. It's really frustrating to see these two compared, because they have different purposes and intentions. Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. By the time you slap all of that on top, you may have well just stuck with Angular. I noticed in React by the tim…
> Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. That's not really true anymore; there is now an official router[1] and state management library[2] for Vue. You don't have to use them, but I think the comparison is still completely fair. [1]: https://github.com/vuejs/vue-router [2]: https://github.com/vuejs/vuex
This is a great point, I did not know it was officially in the build. Thanks!
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#125Earlier quoted context omitted.
That's not really the point of separation of concerns. It's for the benefit of programmers, especially maintenance programmers, not the machine.
Did I suggest mixing presentation and business logic anywhere? My point was that forcing textual representation and another syntactic layer for presentation logic is unnecessary and harmful.
OK, but I don't agree. I think it is valuable to separate your template and behaviors associated with it for exactly the same reasons.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#126People are already migrating from ng2? It just came out!
ng2 final was released in September 2016, but many were using it well before then, as in the article. (first beta was in January 2016 I believe)
I guess maybe it because I am not a frontend person but completely redoing a project in less than two years seems kind of crazy to me.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#127Earlier quoted context omitted.
> "We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice." Angular.2 has been in beta for years. And when it went out of beta it basically became something else. This is not a good thing. It's normal for teams to be excepting at least some level of stability in the library they are using. And now that Angular.X pretends to be using semver,…
If you rely on a beta product you should have no expectation of API stability. It's very easy to blame vendors when it's your own poor decision making that got you in the mess to begin with.
No idea why that comment is getting down voted. Beta can mean different things to different people. We all know google put gmail into beta for years, it was solid for years. That's one example of a product in beta.
But seriously, take a bet on a hip framework and it comes good (like react), good for you . But you can't cry when frameworks change API wildly when they clearly have a beta label on them.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#128Earlier quoted context omitted.
If you rely on a beta product you should have no expectation of API stability. It's very easy to blame vendors when it's your own poor decision making that got you in the mess to begin with.
> If you rely on a beta product you should have no expectation of API stability. If i rely on a beta product, i don't expect a complete rewrite of the API when a stable version is released. That's exactly what happened, several times with Angular. Now you can't have it both ways as a vendor. You can't expect people to try out your product and test it in a professional setting then change everything at the last moment…
I don't know what he's saying, but I would say that you should not have your product depend on something that is subject to change. Thus, although the vendor can do wrong by changing their product API when it is in Beta, it's still ultimately your fault for relying on something that hasn't had a stable release.
Although I get what people are saying about Beta products, the truth is that different vendors use the term "Beta" with different levels of precision, and thus should not typically be trusted not to pull the rug out from under you in some way if they haven't firmly committed to stability.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#129Maybe my viewpoint is too 'elitist' or something, but I have a hard time taking this seriously when one of the chief complaints of Typescript is that it is too "difficult" It really makes me question the validity of the rest of the points.
While I understand the preference for not wanting it, it is a very "high-level" sort of complaint, and the rest of the points seem similarly "high-level."
They could all be valid points, but I wouldn't take any of them purely at face value.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#130> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If…
> TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript.
If you code in TypeScript and extensively use plain objects and "any" types then you don't get a point of TypeScript and so you better don't use it at all.
> It makes more sense to group code based on function.
The idea of code layers and separation of concern comes form the improving code maintainability and testability ideas. Generally if you code has no layers, then it won't be convenient to unit test it. So it makes sense to group the files based on the function, so you can for example switch the entire function easily, but not putting all the function related sources code to the single file.
> In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern.
Single file components is a term, it's more like junction point for the component's parts, as it allows to reference separate/external files into the component file instead of putting everything inside a single file.