Live data from Hacker News

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

medium.com

131–140 of 151 posts

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

#131
post #61

Earlier quoted context omitted.

> proprietary templating language Isn't that exactly what JSX is?

No. JSX is a small domain-specific language for expressing a hierarchy of virtual DOM nodes. Angular is a template language in that it eschews JavaScript compatibility in favor of its own directives that try to emulate basic iteration and conditional expression evaluation.

I wish you could write non string based jsx in angular. Or at least make aot fast enough for the regular webpack watch / recompile workflow.

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

#132

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…

> Angular is a application framework, Vue is a view library.

React is more a just view library than Vue, Vue is a complete framework actually with built-in reactivity (no MobX thing needed). Redux state management (which is not always needed) and routing nowadays are separate modules in case of all the frameworks, including Vue.

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

#133
The article says to me that the team/company had no initial actual need to use TypeScript as seems author doesn't get a point of its purpose (of course code writing will be slower on the initial stage as it's not just about writing the code, but also about defining its structure which gives you the benefits with the growth of the project) and so a bad decision was initially made.

In my opinion Vue is ok for the one kind of projects, with smaller team, smaller project lifetime and Angular is ok for other types of projects. React is alien here, ie not really needed.

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

#134
post #116

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

This is probably true, but it's a really poor rationale for choosing a templating* solution. Sure, JSX is slightly easier to pick up than a pure templating solution would be, but that doesn't mean learning modern templating tools is hard. Making already easy things easier isn't much of a win in my book. On the other hand, JSX is extremely difficult to read. I can glance at a relatively complex handlebars template I w…

> It's also worth noting that JSX is easy to pick up for javascript developers. It's next to impossible for the kind of design-focused frontend people who know HTML and CSS

This seems more like a meme than reality. Design is hard. Someone that was able to credentialize in CSS of all things can learn some JS/JSX. Give them some professional courtesy and credit.

Saying that it's "next to impossible" seems kinda toot-my-own-horn dismissive.

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

#135
post #74

Earlier quoted context omitted.

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.

it is valuable to separate, but why is it valuable to force a different syntactic layer, often with heavy constrains on what logic can be expressed which inevitably leaks back into various helpers implemented in the layer you've just separated yourself from? why is it not better to separate using mechanics native to your language?

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

#136
Ember user here, looking for a breath of fresh air from the limitations of Emblem/Handlebars and the endless layers of complex objects.

I am enrolled in Udacity's React Nanodegree, but recently took a closer look at Vue. It seems to offer everything React does (VDOM, one-way data flow, centralized state management, support for JSX), but without the patent drama.

I previously took a nuanced approach to Facebook's unfair patent license, and will probably never need or want to sue them for patent infringement. But Vue is quite a viable alternative, so I see no reason to reward Facebook's unwillingness to play fair.

I plan to finish the Nanodegree, but will probably be skipping React and using Vue for my own real-world projects.

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

#137
post #15

"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." "We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."

We actually implemented quite a big project with Vue/Typescript. Half year later we removed all ts code in favor of plan js.

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

#138

Earlier quoted context omitted.

> It's because it flew in the face of commonly accepted best practices. People need to stop blindly following current "best practices" because they change all the time. Weigh up the pros and cons yourself. I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes. Best practices for web app UIs have changed dramatically as we've went from e.g. server side onl…

> I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes. Don't do that. Perform loops outside of the final template. People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you…

Do you have any specific reasons for why `items.map` should not be inside a jsx tag? Your comment doesn't make it clear why you think this.

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

#139
post #137
post #15

"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." "We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."

We actually implemented quite a big project with Vue/Typescript. Half year later we removed all ts code in favor of plan js.

Why? Could you explain what was the problem, why plain JS was the solution?

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

#140
post #48
post #15

"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." "We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."

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

Expecting a stable API in a so complex space, with so much untested assumptions, so much "research" (or experimenting), is .. wishful thinking.

Yes, using a small lib will get you initially there, but then there will be a full rewrite of that too, or it'll become completely abandoned, etc.

Angular at least has some idea of upgrade path.

Post reply on HN