Live data from Hacker News

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

medium.com

21–30 of 151 posts

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

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

> This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.

I see this so much as an argument against React/JSX. I can not never figure out how putting the display logic in the display template is some how going away from separation of concerns.

As for JXF being hard to learn, that is just silly. Sure there are a few quirks but nothing in comparison to a learning a new templating tag language.

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

#22
post #8
post #5

Earlier quoted context omitted.

I like Vue, but one thing that worries me is that 99% of commits are being made by a single person.

I like it, a mirror opposite of extreme "designed by committee" practices of big co. funded frameworks. I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new…

ES6 actually supports both Sets and Maps:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#23
post #7

2 flaws with this article. 1) Using a Beta product and complaining on Angular2. You could have waited till the product is matured 2) Blaming for the developers inefficiency on Typescript. If your developers coding speed is reduced blame on your developers. Your title and article appears that something is wrong with Angular2 and moved to Vue.js. Before you post such articles make sure what your write makes sense

He cites two articles going into much more detail on the line of thinking regarding the tradeoff that is static typing. I realize this is one of those tab/spaces kinds of religious debates, but hopefully all sides can acknowledge that we are talking tradeoffs and not universal truths. Maybe one day we'll see loose typing as evil as "goto" statements, but the evidence isn't there yet. IMO.

Goto statements aren't always (or even usually) evil either. Sometimes I get the feeling no one ever really read past the headline of that paper.

Sure, you shouldn't use them unless you really have to, but "really have to" is a line that is difficult to discern. Dijkstra himself noted, "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one."

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

#24

Vue seems to be less taxing on the mind. Compared to React, I feel Vue is more easy to build with. Just my 2 Cents

I agree. Having used both on small projects I was able to get started and finish quicker on Vue.

That being said, I use React more because of the larger community, (easier to find answers, and components) as well as more jobs for React vs Vue.

Also, Fiber introduces better animation performance, which i'll eventually use.

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

#26
post #8

Earlier quoted context omitted.

I like it, a mirror opposite of extreme "designed by committee" practices of big co. funded frameworks. I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new…

ES6 actually supports both Sets and Maps: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I mean Vue does not work well with them. If you set a data value to be a Map, vue will not be able to track changes to it

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

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

I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for.

Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together.

You write html inside js? or sql inside python? omg noob!

Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .

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

#28
post #21
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…

> This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function. I see this so much as an argument against React/JSX. I can not never figure out how putting the display logic in the display template is some how going away from separation of concerns. As for JXF being hard to learn, that is just silly. Sure there…

Without arguing one way or the other:

- Traditional SoC: template, styling, and logic for my app are separated

- React/ractive/vue/preact SoC: parts of my app - login boxes, payment areas, order displays - are separated. They may further be separated by template, styling, and logic or not.

You're slicing something vertically vs horizontally.

In practice I prefer one of these but saying which one wouldn't help illustrate the concept.

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

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

You are probably right that Angular 1.x devs will ramp up a bit faster in Vue than React. Angular and Vue both add template syntax to HTML, which will be more familiar to Angular devs. However, I do not think initial ramp up time should matter that much, at least not for long running projects. More important questions are: How will the project scale? How easy will it be to maintain?

> React is overengineering for most web apps.

This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.

Post reply on HN