Live data from Hacker News

Why we moved from Angular 2 to Vue.js and why we didn’t choose React

medium.com

91–100 of 151 posts

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#91
post #58

Clickbait. The author switched from Angular 2 beta 9 (not even a release candidate) because he was unable to migrate to Angular 2.0.0 since 'too many things broke to make the upgrade non trivial'. Yet somehow rewriting the entire app in Vue is easier?

You'd be surprised how simple it is to re-write an application in Vue. As someone who just finished doing so, I can say that development speed is like nothing I've ever experienced. The application I rebuilt initially took about 2 months to build with React. I rebuilt it with Vue in 2 weeks by myself. I am not venerating Vue, just simply responding to your concerns about rebuilding entire applications.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#92
Angular 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 time you added the required add-ons (mobx or redux, polyfills, react router, styled components) it was extremely heavy. Furthermore, maintaining these addons, with their own release cycles and bugs is an additional burden on a team.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#93
post #59
post #48

Earlier 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.

I have used Google's beta products for years (Gmail for example). You remark is valid for an alpha version, but a beta version should be the final product with maybe bugs to be fixed.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#94
post #56

Earlier quoted context omitted.

It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize it's not that. It's a good abstraction. It puts concerns in the right place. Now, when I have to write something in any .erb file, it's like pulling teeth. JSX + React is a very good view-layer and component abstraction.

I'm not even saying it's a bad idea , just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"

This is the unfortunate result of people following "best practices" only because that's what other people do, and not because of some justifiable benefit of said practice.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#95
post #76

Earlier quoted context omitted.

Yes, it's in many ways exactly that popularity that's the problem. The ratio of good to mediocre programmers hasn't really changed any, but now there's a whole lot more JS devs out there, so finding the good ones is an exercise in wading through a sea of mediocrity. For better of worse, the Java developer ecosystem does a better job of filtering out the mediocre devs, and generally once you reach a certain level of e…

The problem I tend to see there though is back end developers often lack good UI skills.

It's a fair point, but by the same token it's usually easier to teach a backend dev good UI design principles, than it is to teach a mediocre frontend dev good programming principles. There's also the fact that for a lot of the kinds of work we're hiring for, there's a creative team producing design documents that the developers are working against, so they don't actually need good UI skills generally (although it certainly can help, particularly when the designers produce things that don't actually work in practice).

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#96
post #9

> 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…

> It should take no more than 20 minutes to learn JSX. it should, but in practicality, for most front-end devs especially junior ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times (anecdotal experience) quicker than with React. For most smaller shops/startups Vue is almost always a better idea - it's much easier finding devs (especially remote/<100k comp ones) with previous Angular 1 experi…

If a dev cannot pick up JSX in a day they should be let go. I don't feel this is extreme at all. I'm not saying that React is always the best choice, but JSX is absurdly simple, if it can't be understand very quickly that is a red flag.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#97
> At the time we were thinking about Vue.js vs React, we were also considering rewriting our mobile app and React Native looked like a really good choice. That was a big plus for React since Vue.js didn’t have anything remotely stable that resembles what React Native is trying to do, so the possibility of reusing code between the web and app clients was a huge plus, but I decided that I wasn’t going to consider possibilities that might or might not happen. After all, from my experience, with Node.js I reuse a really insignificant amount of code between the browser and the server.

The main benefit of using React if you are considering using React Native is that you and your team won't need to learn another framework in order to build native mobile apps for iOS and Android - if they know React already, they'll be up to speed with React Native very quickly.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#98
Angular 2+ does require more up front investment. However once you get going, the framework's convention is pretty seamless and on can create rather structured, team friendly projects, and iterate functions quickly.

The Angular CLI tool is a must! Without it, the friction to get dive into the Angular 2+ world is significantly more.

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#99

Angular 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…

Please enlighten me — what kind of state management does Angular give you for free?

Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React

#100
post #16

everybody 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…

>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 real boundary is.

Just no. many times presentation code is tightly coupled with some desired functionality that drives that presentation. HTML inside JS is just inherently weird. It's one level of counter-intuitiveness to have the HTML set to some variable and put away and referenced further by the var.

It's another level to have html in-line with JS method calls. The two languages just doesn't jive syntactically

Post reply on HN