> JSX was also a problem since we could not reuse HTML code Who has source code in native HTML lying around?
Why we moved from Angular 2 to Vue.js and why we didn’t choose React
101–110 of 151 posts
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…
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
#103Earlier 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…
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
#104Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#105Earlier 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…
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#106Angular 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…
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.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#107Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#108Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#109everybody 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…
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
#110Thanks 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?