Live data from Hacker News

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

medium.com

71–80 of 151 posts

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

#71
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?"

Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic.

It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.

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

#72
post #32
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…

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.

What happened to jQuery when John Resig focused on other things?

I'm actually hoping Vue.js builds everything needed for a Reactive minimalist framework and then development slows down similar to the speed of jQuery. I think people are sick of frameworks doing overhauls of their entire codebases every major version release.

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

#73

Earlier quoted context omitted.

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…

Would you share some stats about the upgrade? How many LoCs was the codebase and how many man/hours it took?

s/upgrade/rewrite . I don't believe a second there is a reasonable way to upgrade 1.X from 4.X without rewriting all UI related code.

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

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

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.

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

#75
> I didn’t feel Typescript added substantial value and even worse, we noticed that our coding speed was reduced. With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. I highly recommend you to read the following articles before you start using Typescript. It is not the right solution for everyone.

If you read the linked article, it's using a graph of the number of GitHub issues labelled "bug" to justify that languages with strong static types don't reduce the number of bugs which isn't meaningful or convincing...

> The main thing we didn’t like and we still don’t like about Angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, the decision to use Typescript was already taken and from what I understand, using pure Javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case, getting rid of Typescript meant a full rewrite of the project. ... > I still remember how easy to work with Angular 1 was, it certainly had it’s own problems, but it was nice to work with it compared to other frameworks, something that Angular 2 lost somewhere on the way.

I recently moved from Angular 1 because it didn't work well with TypeScript. The rest of my project was in TypeScript and all the bugs were coming from the Angular 1 layer because there was no static checking there.

TypeScript is an enormous improvement over plain JavaScript in my opinion in terms of productivity (better refactoring, better autocomplete) and making your code more robust (no unexpected null/undefined variables, no more mixing up strings and arrays). Ignoring TypeScript for large projects is a big mistake.

Angular 2 felt too verbose and overly complex so I switched to Vue which has decent add ons to work with TypeScript. If you use JSX for Vue templates as well, you get type checking for your templates.

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

#76
post #54

Earlier quoted context omitted.

Ramp up time shouldn't be the only consideration, in any moderately sized project ramp up time will be dwarfed by other concerns like ease of development. In general, ramp up time is one of the weakest arguments in favor of anything you can make and should only be taken into consideration after all other concerns have been shown to be moot. Likewise the argument about "finding devs". Any competent developer should be…

Is that still true to this day? JS has exploded in popularity and utility in the last few years. Even Stanford and other high quality CS schools are teaching JS now.

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 experience picking up something like JS becomes a trivial exercise. We tend to favor candidates that have experience in multiple languages because it's a strong signal that they're a quality developer, and you tend to find more of that in your backend developer pool, where the frontend developer pool tends to have a lot of experience with a ton of frameworks, but they're all almost exclusively pure javascript focused.

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

#77

Earlier quoted context omitted.

Angular 2 kinda sucks. Simple oversights like not having a way to change focus on input fields leads me to believe it's run by crazy purists. There's many other mistakes, like not having access to component state for custom validators and the infamous change detection errors. Sometimes the error messages border on horrific, reminds me of debugging assembly. Some of these issues don't have any good solutions. The need…

No Framework is perfect. There are always tradeoffs. Just because some things didn't work for you doesn't mean you can generalize and say Angular2 is bad. The way the Author wrote, he is generalizing things and making assumptions based on baseless facts

Angular 2 is behind React and Vue in developer satisfaction. And the criticisms levied against NG2 are legitimate. They dropped the ball on a lot of things that were solved a long time ago in React.

Vue, on the other hand, has adopted many of the best features of React and responded well to user feedback. I think it's a strong competitor and I can totally understand someone picking Vue over React. I cannot say the same for NG2.

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

#79
post #31
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…

JSX is not html. JSX is not a templating language. The similarity between JSX syntax and the equivalent virtual DOM node names is the reason it exists. When you write JSX code you are writing javascript code using the JSX DSL to generate the virtual dom. 'HTML templates embedded in code' is simply not what happens when you use JSX. The fact that you got fooled into thinking that is the opposite of a DSL problem.

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

#80
The thing I find amusing about posts like these is that they come about once every 18 months. Just substitute the left framework for last years shiny and the right for the latest shiny. We developers are nothing if not consistent in our ability to chase the latest shiny. I do wish more developers would take the time to master languages instead of learning new frameworks though.
Post reply on HN