Vue.js: the good, the meh, and the ugly
medium.com
Vue.js: the good, the meh, and the ugly
1–10 of 382 posts
Re: Vue.js: the good, the meh, and the ugly
#2I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extremely powerful and elegant (just read about gen_server in Erlang or the State monad). I am never a fan of two way data binding as an alternative. It's extremely hard to reason about, and it's not nearly as composable or simple as a tree of functional transformations. So I think that, if you compare Vue to React Component classes, Vue can be quite nice, but the reality is that idiomatic React should have you writing 80%+ small, simple, composable functions with no state, and you really can't get any syntactically barer then that. It's also the way I teach React. When you first see a function going from state to jsx, it really just makes so much sense, and you ask yourself why you'd ever bother with anything else.
Re: Vue.js: the good, the meh, and the ugly
#3I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
Do you have any suggested resources for learning React in this way?
Re: Vue.js: the good, the meh, and the ugly
#4I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
110% agree
Re: Vue.js: the good, the meh, and the ugly
#5Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technically, in the component, I can just call Axios and get the data then and there, but then I have other components such as the Login that does need to set some Vuex state and therefore that's abstracted away further in the actions/API class as all documentation seems to suggest that's what you should do. I suppose I am just finding it a bit of a challenge to keep things a) consistent and b) not overly abstracted for the task at hand.
Re: Vue.js: the good, the meh, and the ugly
#6It is good just for the simple stuff, the world of webapp examples, todo lists and so on. For all that, Elm is much better.
For all things more complicated and that require intelligence to think about good architecture and how to structure state, the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations.
Also, the community on Discord is not friendly, in fact the community and the limitations of the framework are quite similar, they're all "write a todo-app like the tutorial, or I won't be able to help you".
Re: Vue.js: the good, the meh, and the ugly
#7>You’ll be adding similar boilerplate for computed properties, component state, watchers, etc. Pretty much everything in Vue has its own special syntax with more boilerplate.
I kinda like this syntax, when I first learned vuejs I knew immediately that some magic was going on in the background. If I saw marko's syntax I'd be wondering how this shit is getting done. It also makes it easier when searching for issues or suggestions. "vuejs computed property" vs searching generic terms.
>Chat based community
This part is simply not true, there's tons of individual vuejs communities all pretty decent. Shoot me for saying this but laracast isn't a bad option for Vue help. Everytime I have an obscure problem I find a solution on there.
>The reactivity system will only track changes under certain conditions. Don’t expect to throw anything you wish at it
This is the one part I hate about vue.
>Does this mean authentication logic goes in Vuex too? Will a state manager start mediating all application logic now?
Been there done that. I typically use vuejs for lightweight applications solely because I do run into this issue.
Re: Vue.js: the good, the meh, and the ugly
#8I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
State management by process-directed messages is a really neat way to avoid throwing oneself under the OOP bus.
Furthermore, Elixir has Agent, a higher abstraction on top of Erlang/OTP gen_server that's easier to grok and use in many simple cases with no need to separate the public interface and OTP callbacks.
Re: Vue.js: the good, the meh, and the ugly
#9I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
I wonder how you avoid writing stateful components in real-world complex SPAs.
Re: Vue.js: the good, the meh, and the ugly
#10I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
Do you have any suggested resources for learning React in this way?
Honestly, there isn't much to learn. It's just a function that takes props and returns a React component (usually via JSX). The only big decision is the props API.
https://reactjs.org/docs/components-and-props.html
The best thing to do is just to brush up on functional concepts, thinking about things in terms of composition and application, and threading state through your application and flowing back through to the top via dispatches. Learn more about flow (the concept, not the framework). I like to picture a waterfall, where the water is state that always keeps flowing no matter what it hits. State should start at the top from some source, we don't care what that is, and then flow through the application down into the leaves. Functions can do transforms and reductions on state, but they should never hold on to state the way class components do.