Vue.JS could have a better shot at being respected if it drops the mixing of declarative and imperative code (logic in HTML) as that introduces a dichotomy in its world view that is hard to eliminate.
Why we chose Vue.js over React
231–240 of 267 posts
Re: Why we chose Vue.js over React
#232Earlier quoted context omitted.
> [event.target.name]: event.target.value Dumb question but I've never seen this syntax before. What does it do or what is it called? (The brackets)
It's not a dumb question at all. It's relatively new, and I would implore the originator of that comment to take a different tone. It requires a newer browser or some sort of transpilation step. (You're probably already using one if you're using React) Most of the React community has forged forward with ES6/ES2015, so learning that is definitely a part of the process.
He may have chosen to use newer syntax, but the same pattern can be used without computed keys with only a tiny more code:
var stateUpdate = {}
stateUpdate[event.target.name] = event.target.value;
this.setState=(stateUpdate);
Re: Why we chose Vue.js over React
#233Earlier quoted context omitted.
> [event.target.name]: event.target.value Dumb question but I've never seen this syntax before. What does it do or what is it called? (The brackets)
It's not a dumb question at all. It's relatively new, and I would implore the originator of that comment to take a different tone. It requires a newer browser or some sort of transpilation step. (You're probably already using one if you're using React) Most of the React community has forged forward with ES6/ES2015, so learning that is definitely a part of the process.
[deleted]
Re: Why we chose Vue.js over React
#234The arguments against JSX and React requiring many small components are very surface level and sound like "we couldn't figure out how to make it work for us so it must be impossible". 1. This was mentioned already, but, yes, you can use ternaries and boolean logic for simple conditionals (loggedIn && Logout || Login ) 2. When you need more markup, put them in an if-else statement in the same render function. render()…
After working with Angular templates for a long time and then switching to JSX, I'm never going back to having my markup in a string blob with magical attributes that make it do stuff. why would you do this in Angular? i thought the whole point was to use html templates in separate .html files. as for "magical" attributes, angular2 moved away from that and is using mostly native html attributes. i.e. [disabled]="x" […
It's still just a giant string blob which is interpreted by Angular at runtime. Just because it's in a seperate file doesn't change this.
JSX, on the other hand, is Javascript function calls. You're writing JS to describe the UI.
Re: Why we chose Vue.js over React
#235The arguments against JSX and React requiring many small components are very surface level and sound like "we couldn't figure out how to make it work for us so it must be impossible". 1. This was mentioned already, but, yes, you can use ternaries and boolean logic for simple conditionals (loggedIn && Logout || Login ) 2. When you need more markup, put them in an if-else statement in the same render function. render()…
Wow. Do people consider this kind of coding acceptable now? We spent decades trying to separate templates, business logic, and inlined JS, and you managed to cram all three into a short snippet.
It's actually no different to any other templating solution. Take a look at this[1] Mustache.js example and note the logic! At least JSX is honest about what it is.
Re: Why we chose Vue.js over React
#236The arguments against JSX and React requiring many small components are very surface level and sound like "we couldn't figure out how to make it work for us so it must be impossible". 1. This was mentioned already, but, yes, you can use ternaries and boolean logic for simple conditionals (loggedIn && Logout || Login ) 2. When you need more markup, put them in an if-else statement in the same render function. render()…
After making some simple , etc custom components.... I've wondered why they don't exist in react by default, or arent the common pattern. They are very readable... maybe people just dont like the "logic" in a tag... i guess... whatever, made for some really readable code...
I would rather 'regular' JS functions like .map() rather than React-specific functions like and (not to mention the namespace clash with existing JS keywords)
Re: Why we chose Vue.js over React
#237Earlier quoted context omitted.
It's not a dumb question at all. It's relatively new, and I would implore the originator of that comment to take a different tone. It requires a newer browser or some sort of transpilation step. (You're probably already using one if you're using React) Most of the React community has forged forward with ES6/ES2015, so learning that is definitely a part of the process.
He may have chosen to use newer syntax, but the same pattern can be used without computed keys with only a tiny more code: var stateUpdate = {} stateUpdate[event.target.name] = event.target.value; this.setState=(stateUpdate); I don't think there was anything necessarily wrong with his tone as he was addressing the tone of the original article.
This is exactly what I've been using for a while now, and was hoping something better already existed in ES6. Great to know there is!
FWIW, this is supported in the newest Chrome as well.
Re: Why we chose Vue.js over React
#238Earlier quoted context omitted.
It's not a dumb question at all. It's relatively new, and I would implore the originator of that comment to take a different tone. It requires a newer browser or some sort of transpilation step. (You're probably already using one if you're using React) Most of the React community has forged forward with ES6/ES2015, so learning that is definitely a part of the process.
He may have chosen to use newer syntax, but the same pattern can be used without computed keys with only a tiny more code: var stateUpdate = {} stateUpdate[event.target.name] = event.target.value; this.setState=(stateUpdate); I don't think there was anything necessarily wrong with his tone as he was addressing the tone of the original article.
Telling someone, "or maybe you should learn JavaScript" is kind a really jerky way of saying, "you don't know what you're doing". I do think it was a terrible way to share knowledge. Yet it was an excellent way to say, "I know more than you".
Re: Why we chose Vue.js over React
#239Earlier quoted context omitted.
Well, there's a difference between going out of fashion and being revealed as something that shouldn't be used (like Angular and Ember). Maybe Vue is just becoming the new shiny.
Ember should be used more often. It saves a ton of time with large apps and has really neat plugins like FastBoot. It's underrated.
I think the pendulum will keep swinging between the minimalists (React/Vue.js) and the frameworks (Ember/Angular).
Ember is completely underrated and overshadowed by React right now. It takes some of the best ideas from React (components, shadow DOM, FastBoot) and puts them in a cohesive framework that has an incredible support ecosystem and upgrade path.
Re: Why we chose Vue.js over React
#240Earlier quoted context omitted.
All you need is re-frame. It is well documented and the philosophy is explained as well.
Thanks for the tip, I enjoyed their comprehensive readme. I might give this a go next time around. https://github.com/Day8/re-frame
Definitely try it sooner rather than later, it's good stuff. I feel like re-frame is what you would get if you put the time into selecting the best libraries to integrate with React, and then removed as much boilerplate as possible.