* https://laracasts.com/series/learn-vue-2-step-by-step * https://laracasts.com/series/testing-vue
Thematically, it may be a result of obsession over tools instead of product which occurs in other areas like photography, writing(hipster typewriters), and others. In tech, technology as lever supports a "hacker" mindset of getting 10 for 1. However this misses the point of hacking to get around your weaknesses in order to focus on your core competency which MUST intrinsically have value instead of being an empty shell.
The core competency for many client side developers is probably more rooted in a form of design than pure technical ability. Design, like music, writing, speaking, and art have incredibly low barriers to entry. This can create an arrogant mindset from people coming from more rigorous disciplines. Instead of focusing on the thing that must be done, they try to take shortcuts that only have the appearance of reaching the goal.
When you're hyper-vigilant about simplicity, you end up creating the simplest design that meets the goals. It takes a little extra time, but it's so worth it.
I’ve never used Vue but I’m also curious to see how it and VueX fares in this regard.
If you love to type, though, I highly recommend Redux!
const ADD_TODO = 'ADD_TODO'
import { ADD_TODO } from '../actionTypes'
function addTodo(text) {
return { type: ADD_TODO, text }
}
dispatch(addTodo(text))You might still need to place actions/selectors in their own directory since they're not necessarily specific to any reducer. I believe this is how sagas are organized, though.
Also you don't have to import your actions, it's just a smart thing to do. This gives me heartache a bit: https://github.com/vuejs/vuex/blob/dev/examples/counter/Coun...
Vue and Vuex seem less clever JS (shiny es6 features), less clever programming (mutability etc) which I feel may be a detriment for complex apps in the long term but it is simpler.
(I may be biased because before Vue and React/Redux I did Angular1 & React/Reflux and I view Vue as a Angular/React mix and Vuex is not far from Reflux)
That's not part of Redux, it's a separate design pattern you can use with any Flux architecture. React-Redux doesn't even require you to do it that way, and for good reason: you might not need it. There's nothing wrong with just importing a store reference wherever you want it. That's a totally reasonable pattern for some applications.
This illustrates my point I guess. There's so many people thinking about how to architect and implement React applications that there's a lot of cargo-culting.
Vuex & Vue are the easier APIs to learn. Not only that the developer ergonomics are just better for Vue's API. For example in vue you have "mounted()" instead of "componentDidMount()" or "ngOnInit()". Likewise, redux requires learning CS terms (if you don't know them) like thunk, saga, memoized selectors, etc. Vue uses more layman's terms, like "computed" instead of "memoized selector" which just makes it easier to learn.
My big hangup with Vue is having to declare reactive properties up front. It's author says this is a best practice anyways, but it leads to hard to debug issues when you accidentally declare new properties at runtime & you get race conditions. With react & redux both making immutability possible & encouraging immutability, you get easier to debug apps. But there is a more up front investment.
I also really love Vue's single file components. I know you can do that in Angular & React, but again the API is just so much more ergonomic in Vue.
It's good enough and fast enough as it is for most medium side projects.
And the awesome thing is that you can scale it up for this one big project you need it for.
Trainer here. I train in React and in Vue.
My students do 3 times the work with raw vue than in raw react. Every one of them. All the time.
It's not even on the same map.
I haven’t found anything nice for a guide in building a real world application like this. Maybe it would involve multiple things vue + ? + Postgres or Mongo or some other option. But I want love something that would hold my hand start to finish connecting the dots.
Starting with vue is just: add a script tag, put your template here, now your data here. Done.
The start up experience is nothing alike.
Like you can write Java without IDE. Nobody would. But plenty do with Python.
For a Js developer reactjs would be easy. But if your not that experienced or just HTML guy then I can understand why they find vue/angular easy. Both have a framework built in for routing, css , http. You just need to learn their syntax and nothing much. With reactjs you need to come with your structure, find the correct routing, state managements,css libs etc
Vue on the other hand was so simple. And the documentation made getting hello world done in a few minutes. This got me off the ground and made me feel productive as I felt I knew right away what vue was doing at a most basic level. Then it was just constant learning on top.
But I think it’s good that there’s competing library, though the problem domain felt eerily similar.
Not me.
I mean, it's necessary, at some point, to see a full system that uses all the tools for delivering a real application. But, it is definitely a lot of concepts to grok at once. I actually found it most useful to see tutorials that started without even using React, and built up from first principles to what React does (given that React is conceptually very simple, this isn't so crazy...a toy version of React can be built in an hour or so, so it's perfect for a video or article; much of the complexity in React is in making it fast rather than in making it work). But, that may not be a necessary first step for people who have more frontend or reactive programming experience than I have.
But, the learning materials and marketing are the ones that bug me...especially the ones that neglect to mention that the materials cover React+product, and only mention React in the title. You might not even know it's marketing until you've read half the darned thing and the crux of the thing turns out to be "now create an account here and use this service to outsource the specific thing you googled to learn how to implement yourself". GraphQL has a lot of the same thing going on. It's like "how to draw an owl", only instead of "now draw the rest of the fucking owl", it's "now send us money every month for the rest of your app's life and we'll draw an owl for you".
Yes, since probably early 2016, many tutorials have basically said "you need to learn React and Redux together", and that's the message that a lot of junior devs have been taught.
However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation.
That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together.
Put yourself in the shoes of a CTO at a new startup. They need to decide whether to build their company on top of React or Vue. They need to make this decision quickly.
Is it really fair to say they don't need to learn Redux? And that maybe Redux won't apply to their situation?
Of course Redux will apply, because Redux is for all intents and purposes how you manage state at scale. And everyone who's entering the field who isn't a junior dev is thinking "We need to come up with a way to manage state at scale. Does Vue help us do that, or are we stuck with React+Redux?"
It really doesn't help matters when you look into big players like airbnb and discover that they wrote their own state management framework rather than use Redux. They even have a two week onboarding process for new devs that teach them how to write features using their blend of tech. It's a bit... Eh... The whole thing just feels like WPF, a dead technology that few people here have probably heard of. There must be a simpler way.
My first step is to hire someone that knows how to build a FE app. We'll use the tool that someone is familiar with.
If you're a CTO of an incubator startup with 2 people straight out of college who learnt Python and basic JavaScript and you're trying to build a serious web app from there, well, it doesn't really matter what you pick, you'll have to rewrite it in a few months anyway (that's a pretty common scenario).
Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux.
Then, build something small. Learn Vue. Repeat.
Now you understand both options enough to make an educated decision. Feel confident building your big, gotta-get-it-right-off-the-bat startup project in whatever works best for you.
Theoretically, you can get by without learning it. In practice, the moment you try to build a real company, you need it. That necessitates learning Redux.
I think this is an uncomfortable thought because it implies that Vue is way easier for devs to get into, and that's step one to displacing React+Redux. But that seems like an uncomfortable truth.
Whoever is in charge of React needs to give Vue the Snapchat treatment. Take them seriously as competitors. There's still time.
You have to take yourself out of the "experienced React+Redux dev" mindset and put yourself in the shoes of "Experienced dev looking to invest in one of two ecosystems" mindset. Which one is the path of least resistance?
The point is, React+Redux people would love to believe that it's "Vue+VueX." But in reality, it feels like "just vue." A sword is stronger as a single piece, and Vue+VueX feels like a single piece.
It's up to people to learn both and decide for themselves, but my argument is simply this: it's a mistake to underestimate the traction Vue is gaining.
There's a strong temptation to blame the dev: They're not smart enough, they should have been able to pick up Redux easier, Vue+VueX is the same as React+Redux. But all I can do is report my experiences, and an honest survey of the ecosystem would lead us to conclude that Vue+VueX is far easier to learn without sacrificing any flexibility for your company in the long run.
To be clear: I like both React and Vue and am fundamentally skeptical of arguments that one is significantly better/worse/different than the other.
Okay, how big is our web application? A few pages with a form? We'll avoid Redux for now. We might even avoid React.
It's like anything else: should you set up a Spark cluster if you're only processing Gb's of data? Probably not, but you might need it some day -- so make your best guess.
React itself is an incredibly simple library: you can explain the entire thing in a few sentences. In my experience it has an undeserved reputation for being more complex than Vue.
I think React is very cool, and I haven't tried Vue, but everything on this thread points to it being a much better learning experience, and might be better for small or middle-sized projects.
This image, from React conf years ago, communicates this sentiment perfectly: https://i.stack.imgur.com/tnk9a.png
Because everyone with a React job or substantial React project uses Redux (or a similar library). It is common for junior devs to rush through learning libraries in hopes of being employable or a "real developer" as soon as possible.
Now I did two projects without and everything is nice and simple.
Almost everyone I know learning React in a professional capacity ends up having to learn Redux at much the same time, my experience is very much the opposite.
I feel like this is Vue starting to get the React treatment. React was (and still is!) a very simple library until people realized they needed to do fancy things to make complex applications manageable. Redux came out, everyone fell in love with it, and React+Redux became an official couple. This lead to the perception that React has a steep learning curve because new developers were learning React+Redux without learning React first.
I wonder what Vue can do to avoid the same pitfall.