Live data from Hacker News

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

medium.com

101–110 of 151 posts

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

#101

> JSX was also a problem since we could not reuse HTML code Who has source code in native HTML lying around?

Even more, a simple find and replace for "class" to "className", and wrap it in a render function. There, now the HTML is being reused as JSX.

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

#102

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

Alibaba's working on a Vue-based mobile alternative called Weex. It's still in its infancy, but it's worth checking out:

https://weex.incubator.apache.org/ https://github.com/alibaba/weex

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

#103

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.

> 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'd obviously not do that when looking at raw code.

    const MyComponent = (props) => {
        const itemList = props.itemData.map((itemData) => {
            return ;
        }

        return List of items
{itemList}; }
It's as simple as that. There is never a reason to mix logic into the "template" part of the component.

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

#105

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…

I'm not seeing a huge difference. It's a bit cleaner, similar to how it would look if you did a similar refactor of plain JavaScript code, but it's still very similar. If the logic is short, it's cleaner to inline it sometimes. Going back to my comment, what are the pros and cons or is this just separation based on principle?

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

#106

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…

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

That's not really true anymore; there is now an official router[1] and state management library[2] for Vue. You don't have to use them, but I think the comparison is still completely fair.

[1]: https://github.com/vuejs/vue-router

[2]: https://github.com/vuejs/vuex

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

#109
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 pu…

> HTML inside JS is just inherently weird. ... The two languages just doesn't jive syntactically

that's because you can't escape the notion that DOM must always be represented as HTML and nothing else. [v]DOM is a very well structured entity, and it so happens that our programming languages love structured entities and manipulating them.

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

#110
Just wanted to come here and say thanks to the author for writing up your assessment of their tech stack and the pluses and minuses - it's brave to do so and it's obviously spurred discussion.

Thanks for sharing some of your learning and having the guts to put it out there, and congrats on shipping the results.

I have a couple of questions:

1) You had two people working on the project - how do you think it would scale out to 10? React's componentized / functional nature allows for that pretty easily which is a consideration for me.

2) Managing JavaScript in templates (html) with Angular 1.x was always weird because you couldn't necessarily tell if the execution was happening in the view or the controller. Does Vue make that any easier when it mixes templates and JS together? I also appreciate knowing that this file is where everything is contained for X element or function.

3) How are the test harnesses?

Post reply on HN