Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

31–40 of 151 posts

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

#31

Post by ashark »

mohaine wrote: post #21
erokar wrote: 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…

We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immediately on board with it being called a moron seemingly overnight, I guess because Facebook says it's fine?

Some people have a little whiplash from all that, and I think it's understandable.

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

#32

Post by ergo14 »

baybal2 wrote: post #8
ergo14 wrote: 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…

I'm not talking about the API design, I'm more worried what happens if Evan dies, or just loses interest in it. Bus factor of 1.

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

#33

Post by mrighele »

sgt wrote: post #4
zerr wrote: post #2

While we are at it - any success stories with Weex? (a la Vue.js native)

A few months later: "Try Weact, a Weex alternative." The speed at which these frameworks pop up is almost exhausting.

My approach for a JS framework or library is that the time I can hope it will be maintained for is at most the time that it has already been maintained. This way, depending on how long my project is supposed to be supported I can make a reasonable choice about what to use. I call it "JS half-life time".

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

#34

Post by pete_b »

Angular 2 in beta made bold claims about being 'production ready' which reads 'almost done', it was frustrating just how long it then took to become what I would consider production ready.

I consider Angular 4 the first release to produce just about acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changing framework.

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

#35

Post by newcomcjoe »

keymone wrote: 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…

Vue 2 allows you to precompile your templates so you're not sending out a bunch of strings of data. Since it uses a virtual DOM, you can use a build tool to compile your templates down to the virtual DOM code to help your application run faster.

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

#37

Post by christophilus »

che_shirecat wrote: post #20
erokar wrote: 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 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.

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

#38

Post by mohaine »

nailer wrote: post #28
mohaine wrote: post #21

Earlier quoted context omitted.

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

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

No, they are not. There is no real difference (other then syntax) between

{ rows.map(r=>()) }

and

These are both logic that have to be run to display your page. The only real difference is that with JSX, it is easy and powerful enough to use that you could stick some non-display logic in there. Easy and powerful should not be an argument against it.

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

#39

Post by christophilus »

ashark wrote: post #31
mohaine wrote: post #21

Earlier quoted context omitted.

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

We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immedi…

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.

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

#40

Post by stupidcar »

pete_b wrote: post #34

Angular 2 in beta made bold claims about being 'production ready' which reads 'almost done', it was frustrating just how long it then took to become what I would consider production ready. I consider Angular 4 the first release to produce just about acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changin…

I think this had to more to do with internal pressures at Google than the actual state of the code. They had been working on it for a long time, and, I think were under some pressure to actually ship something. Angular v4 is what the first production version should have looked like.

Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually very happy with where it's ended up. It feels like a very good combination of power and flexibility. There are still some complex bits, but it feels more like the complexity is necessary and sanely designed, rather than the craziness of what AngularJS's directive stuff evolved into.

Post reply on HN