[ng12]

> We discovered that VueX makes our lives easier. If you are writing a medium to large feature, use VueX. If it's a tiny feature, you might get away without it.

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.

[josefrichter]

Rookie Vue dev here. I found Vue super easy to understand and to start using for my own simple stuff basically from day 1. Gradually as my tiny projects grew in complexity, I naturally started to feel the need to manage state better. And again, Vue docs led me gradually thru pure-Vue solutions towards VueX. It all felt very naturally, the documentation didn’t push me to anything, just gave me answers at my pace. Can’t say the same about React, even though I’m a big fan of both.

[knowThySelfx]

Vue documentation is just superb. Kudos to those wrote it. Evan Yu, in particular. Only those who understand a topic very well can present it so simply.

[stevenwoo]

How are you learning Vue? Looking to expand my toolkit.

[claar]

Vue official docs/tutorial are great. I also highly recommend Laracasts free Vue lessons:

* https://laracasts.com/series/learn-vue-2-step-by-step * https://laracasts.com/series/testing-vue

[kylestlb]

Awesome Vue has a good list of many vue resources: https://github.com/vuejs/awesome-vue

[keviv]

Initially, https://www.udemy.com/vuejs-2-the-complete-guide/ course helped me to get going. After that, I just read the official documentation and examples on Github.

[jakecodes]

Hey ng12, author here. I totally agree with you. I am the biggest proponents of keeping things simple. I initially was hesitant to introduce Vuex. I've written a few huge apps in Vue without anything else but Vue. The cool thing is you can, of course, continue to do that. But again, you just have to follow some strict patterns. Or, to make it simpler, you can get some help from Vuex and let it help you follow those strict patterns. Either way, one is best off if they follow a strict pattern. If not self guided, then library guided. Especially on a big team you can reduce the stress of that strictness if everyone uses Vuex. With so much code flying through GitLab, Vuex is the answer, for quicker code reviews.

[scruple]

I guided my (small-ish) team away from VueX when we reached for VueJS earlier this year in an application. I based these decisions, at least in part, off of the GitLab engineering teams efforts, as well, for what it's worth. We are all still happy wth that decision. I don't have much more to add to the discussion but to say that it's very nice knowing that if we reached a certain level of complexity that we could, fairly easily, introduce VueX and be back at our previous pace without a lot of hubbub.

[jakecodes]

Glad to hear that we influenced your decision.

[dlwdlw]

From my experience telling people this doesn't work as everyone thinks they are smart enough to avoid the trap. Like many companies going into China assuming things will be easy. Code ends up complex yet works because the complexity was successfully wrangled, missing the point of complexity reduction rather than wrangling.

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.

[sillysaurus3]

One cure for this is to have someone who cares solely about simplicity, as an ideal above all else, in charge of technical decisions.

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.

[_qbjt]

I think one reason for that steep learning curve might be that many aspects of React, namely component lifecycles and state management within components, are abstracted away or simply moot once you start managing state with Redux. Also, while the two libraries work great together (I consider Redux indispensable for new React apps), they aren’t really similar as far as library design and patterns are concerned. Finally, there is something to be said about the mental overhead added by Redux middleware. If you’re dispatching async actions, you’re probably using Redux Thunk. If your app has forms, you might be using Redux Form (I honestly avoid it because its own abstractions and Field components end up getting in my way). Ultimately, the process of learning how to use all of these tools in tandem can feel somewhat disjointed, especially when you’re also integrating them with other parts of the web stack, modern and in some cases legacy.

I’ve never used Vue but I’m also curious to see how it and VueX fares in this regard.

[fny]

What Vue can do is create a well-designed state management library that works out of the box without umpteen lines of boilerplate... and that's exactly VueX.

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

[gravity13]

To be fair, you don't really need to declare your constants elsewhere. This is just a pattern people stuck with, because they're stubborn about constants, I think. Doing a find/replace is so incredibly easy that it's kind of silly to add a bunch more boilerplate to protect against one DRY quip.

[ng12]

I'm a really big fan of the Ducks pattern where your action types are private to each reducer unless they're explicitly exported as an API. In my own code I don't even do that, instead exporting a function which operates on the state.

https://github.com/erikras/ducks-modular-redux

[gravity13]

Hm, interesting. I like it. I'm also curious about how selectors come into play here as well (exported getter functions for shielding app from reducer state shape).

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.

[ng12]

I refuse to believe VueX is any simpler than Redux: https://github.com/vuejs/vuex/blob/dev/examples/counter/stor...

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

[conradfr]

Vuex is simpler than Redux. First you don't have to grasp the Container/Component pattern. Second you have less middleware ("what, you don't use redux-saga and redux-think?").

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)

[ng12]

> Container/Component

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.

[conradfr]

That's not part of Redux, maybe, but it's very prominent in the official tutorial in the basic section : https://redux.js.org/docs/basics/UsageWithReact.html

[dubcanada]

It's not, it's literally the same (they said VueX is based on Redux). The difference is React.

[joshribakoff]

I disagree that its "literally" the same. Vuex requires you to mutate state, through their API (if declaring new/dynamic properties). Redux is agnostic about how you handle state, but encourages immutability. Vuex is inherently not immutable, its coupled to the vue reactivity system which is based on mutations & memoization.

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.

[watty]

It looks like VueX supports async out of the box. That's a huge win IMO.

[ng12]

Is it? I thought Redux abstracting out the thunk layer was silly until that line of thinking lead to Redux-Saga. It actually seems to have been a pretty smart move.

[watty]

There's vuex-saga as well. Something built in would have been nice because even though sagas are cool, the learning curve is steep enough for me to avoid it in projects.

[sametmax]

It avoids it by design. Most of my vue project only uses vue. Not even webpack. Just the static vue file. I don't even have that many components because view doesn't force that on me.

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.

[hesarenu]

Reactjs developers should familiar with other state management libs like mobx or mobxstatetree .

[k__]

Funny thing is, Vue wihtout extras is more complex than React without extras.

[sametmax]

Nope. Nope. Nope.

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.

[xeromal]

I'd clarify your statement of "3 times the work" as a positive. I had to read twice to not think that Vue took 3x the effort to do something.

[SnowingXIV]

This might be a dumb question, but what’s the best way to actually use this to make a real application? I’m talking speak to a database and hook up a backend. I’ve enjoyed using vue from a “this is a neat way to make components” but I’ve never successfully been able to do anything with it. I understand it’s just the “view” and not a full MVC like rails but I want that to exist. I want it super opinionated and favor convention over configuration.

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.

[kevinleedrum]

Academind has a great video series on creating a Vue app that uses Firebase as the backend, and anyone can follow along and reproduce the results. He also uses Vuetify for the sake of having some prebuilt UI components. https://www.youtube.com/watch?v=dIkPb8krORU

[sametmax]

Yes you need a lot more tools. A backend framework with a REST API plugged to a data base is common way of doing it. Personally I use Django + Django Rest Framework a lot on the server and axios to query it on the client. But you mileage may vary.

[SnowingXIV]

I would love to see a start to finish crud example of the "least" amount of magic and copy paste code for a guide on setting this up. I've messed around with Django and it seemed harder to grasp than rails due to using regex out of the gate to apply a simple route as opposed to get/do or resources.

[k__]

Even if you ignore 2-way-binding?

[sametmax]

The whole component russian dolls with data/callback passing is something most beginers have a very hard time to grasp. Add webpack to the mix, make them fight with JSX that doesn't want to do what they need and voila, you get a sad student.

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.

[nightski]

Uh, you pass data & callbacks through props in vue also, unless you use a single component. Why not just compare it to using a single component in react then also and be honest?

[sametmax]

Actually beginers in view won't use a component at all. They will use it angulajs 1 style

[k__]

That wasn't my question, but okay. lol

[philliphaydon]

I disagree. I was going to use react for a personal project and got stuck because of documentation and the various blog posts and tutorials all being different and using different libraries and patterns etc etc. This made getting a basic hello world impossible for me. (I’ve since used react and it’s now trivial but starting out was not easy, barrier to entry is still higher than vue.)

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.

[jaequery]

no, it's actually quite the opposite. vue took all the complexities out of react/redux it's not even funny.

[k__]

I'm not talking about Redux.

[sillysaurus3]

Then it's an unfair comparison. Vue does state management out of the box. React really doesn't. Yeah, it has setState, but that's nothing compared to Vue.

[ng12]

I'm very skeptical of that assertion. Can you provide an example of something Vue provides that React does not?

[k__]

With Vuex?

[enraged_camel]

No, he said out of the box. Vuex is not part of Vue core, it's an extra.

[kimjongman]

My students are more productive by 200% with vue

[lxcid]

I agree. It felt like Vue is rewalking the path of React all over again.

But I think it’s good that there’s competing library, though the problem domain felt eerily similar.

[gingerb]

> Redux came out, everyone fell in love with it

Not me.

[a13n]

When did new react developers start learning redux? From my experience that just isn't true.

[SwellJoe]

I've been learning React lately, and many tutorials, even those targeted at beginners, include Redux. Many seem to be a sort-of cargo cult without any understanding of why they're using Redux, and in many cases, there's no reason to introduce Redux into the mix. I've also noticed a lot of tutorials are content marketing from companies wanting to sell bolt-on services and tools, which is pretty weird; I've never used a language/ecosystem that had so many hangers-on before. And, it leads to the same situation: "Learn React (plus these other complicated things that we want to sell you)!"

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.

[jbreckmckye]

There is a big problem with the commercialisation of React. More and more companies are using learning resources as marketing material. And now one popular JS developer has started beginning his GitHub readmes with advertisements for a paid JS course. It's a far cry from the open, guileless sharing culture of webdev 10 years ago.

[SwellJoe]

I'm somehow less bothered by the latter. Folks gotta make a living, somehow, and sometimes people have to make choices between doing OSS development or having a real job and doing a lot less of the OSS work.

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

[acemarke]

I'm a Redux maintainer, and I spend most of my free time answering questions about React and Redux.

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.

[sillysaurus3]

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.

[shados]

> Put yourself in the shoes of a CTO at a new startup

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

[rescripting]

If you're the CTO of a new startup, don't pick a technology to build your startup in without building something with that technology first.

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.

[sillysaurus3]

Certainly, and that's the way to do it. My point is, you end up converging on learning Redux. You really do learn Redux no matter what, so it's kind of a myth that you "don't need to learn Redux."

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.

[ng12]

I don't understand your argument -- wouldn't it follow then that Vue devs converge on learning VueX? VueX is very similar to Redux, I don't see how that's a point in Vue's favor if our metric is time spent learning.

[ng12]

> Put yourself in the shoes of a CTO at a new startup

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.

[Griffinsauce]

A few pages with a form? Avoid code alltogether. Build it with a wysiwyg tool in 2 hours and get that stuff to users pronto.

[ng12]

The majority of complaints I hear (either at work or online) about React are actually about the React ecosystem -- they have trouble with Webpack or Redux and throw the baby out with the bathwater. I think very few people learn React by writing a pure app (e.g. hand-compiled, no state library).

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.

[GFischer]

The thing is, even if you want to hold yourself to a simple React-only app, the moment you want to leverage someone else's work, you are thrown into the shark-infested waters of the React ecosystem.

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.

[lucideer]

While I personally avoided this pitfall and learnt React alone before Redux, I have not meet anyone else who did the same. Literally everyone I've talked to about learning React did so (or tried, and failed to do so) with both, up front.

[a13n]

Wow, I wonder where people are getting the idea that they need to learn Redux. If you start a new job at a company that uses React, then you probably need to learn React + Redux simultaneously. But if you're just picking up React, Redux isn't useful whatsoever.

This image, from React conf years ago, communicates this sentiment perfectly: https://i.stack.imgur.com/tnk9a.png

[sotojuan]

> Wow, I wonder where people are getting the idea that they need to learn Redux

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.

[k__]

I started with Redux too, because the lead dev on a project said it's a must.

Now I did two projects without and everything is nice and simple.

[a13n]

It's definitely a must after a certain codebase size. 20k LoC maybe? But for personal projects, no way.

[giobox]

If you are working with React in a professional setting, Redux is practically the default choice for state management. If you are building something in a professional setting with React, there's a pretty good chance it's complex enough that it needs a state management library like Redux to do well.

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.