Give me some reasons to love Vue

It's if you don't ever need to programmatically dynamically lazy load a chunked asset that's not associated with a route.

there is 10x as much documentation than react, is a lot easier to learn, and decouples HTML, CSS, and Javascript.

It’s not redux 🤮

You can say “how Vuetiful!”

@d-fanelli yeah I hate redux too but I'm forced to learn and use it because of work lol 😅

@Devnergy @d-fanelli What’s wrong with Redux?

@Devnergy that’s pretty much why I was learning it too. Because business wants it. But I do like it’s time travel debugging thingy. That’s it’s one advantage over context. Unless of course my mortal feeble mind cannot possibly grasp why this sacred tool of the gods is needed. I’ll just go back to my hooks and context and know my role as a pleb

@Root
Redux is poorly implemented CQRS whose primary selling point is that you don't have to (but really should) understand that underlying principle.

As to why it's not great: It's stringly typed, has effectively no support for tombstoning, or namespace ownership (store name conflict resolution is manual, conventional). I've also personally never worked on a project where it wasn't eventually a massive memory leak; components and modules would go out of scope and get collected, but the data it used was still present because the people who wrote it aren't familiar with cache policies and decoupled the store mechanism from the subscriber behavior mechanism. I've also seen people end up with the multiple listener problem where every update creates a new listener, and those that did clean it up had to dispose of the listener objects and resubscribe on every update which just leads to subscriber churn and unnecessary reprocessing due to what I refer to as the "Dory Antipattern." You also can't encapsulate behaviors on a per subscriber basis, share it around and lazily subscribe; rather, you stuff what you want to do into the sausage maker, and everyone gets the same sausage, there's no potential to specialize it because it doesn't have per subscriber pre-subscription operators.

Conversely, it really doesn't take much work to implement state machine logic in Rxjs, and you get to keep both type safety and gain the benefit of composability. Conjugated streams allow you to link teardown behaviors to lifecycle operations naturally with no side effects or state pins. Refcount gc behavior and backpressure control becomes implicit. You see what it's doing, you can set breakpoints and debug and there's no bullshit.

@SortOfTested 😂 Comparing it to a sausage maker is actually pretty accurate. Guess I’ve never thought about it at scale and what issues this would cause.

Come to think of it, I’ve never really thought about frontend anything at scale besides CSS. 🤔

- It's easy to get started than with React and Angular.
- It brings the best of both worlds.
- It's useful for a wide variety of software projects (going static sites to hybrid apps).
- Its ecosystem is fantastic.
- It makes it easier to pick up other frameworks like Angular and Ember and libraries like React.
- If you know Angular, it's going to reasonably easy to get started with.
- It's performant.
- You can progressively change any web apps or websites to Vue based ones without rewriting anything from scratch.

Disclaimer: I have only made one react app from scratch and worked on a couple others. This is me saying the thing I've used more is easier.

I found Vue much, much easier to learn than React, and I have yet to encounter an issue in Vue that is specific to Vue.

Nesting and slotting components I feel is a lot more intuitive. Achieving the same in React looks like hacks in comparison.

My biggest gripe is probably how they went a little overboard abstracting out all the "scary stuff" in a way where you still need to be aware of it but it's more obfuscated - like controlling render conditions and prop reactivity.

I still feel Vue apps are faster to make and easier to maintain.

I. Easy to learn and use and more intuitive than competition
II. The new composition API in Vue 3
III. Separates the markup, style, and script in a very clean way
IV. The ability to scope the style to its own component
V. No need to introduce a new language (JSX)

True love has no reason. ... There is no reason given for God's love for us. Because if God had ever gave a reason then the reason becomes our problem. Because reasons is a condition and condition creates expectations which means I expect this thing to be met in other for my love to remain.

@SortOfTested Interesting but different reasons why I’m not a fan. I never experienced those issues before since the only redux I saw was for smaller apps like todo’s and clocks. I just hated having to create a million files for everything (components, action functions and the stores) and having to memorize action names but it’s better than prop drilling to give the same state to multiple components and it’s time travel debugging is cool.

@SortOfTested or any other redux expert, is redux also used to decouple important logic from the UI? Say we have a button with a click handler that logs you in when clicked, and sets the loggedIn state to true. This state is read by multiple components that reload in response to its update, and the action of logging in affects other states too. If we get rid of this button during a redesign, we lose this logic as it’s tied to the button. Is this a problem redux is meant to fix? Sorry if I’m unclear, haven’t had my coffee yet

@d-fanelli
Yeah, action names is one example of it being stringly typed.

Meanwhile in Rxjs and RFP-land, you can get a state machine by types or symbols or any other identity. "Timeline debugging" is implicit as well, since it's just the state in that stack at the start of each pure function call in the observable sequence. The browser has that tool built in. RxFiddle provides the visualizing. You don't lose anything except the magic.

@d-fanelli
Redux owns all the logic you stuff inside it, it's wrapped up in the god object. You register the do with it, and bind it to a "well known" operation/action identity that the thing which needs the functionality will use to bind to it. It has a tendency to be all concerns for all things.

You could probably use it as a compensating buffer for that problem, but I personally prefer to create a state machine that can either be ref'd directly from it's module, or provided as part of a higher order component.

@SortOfTested thanks for both answers! Another workaround that I would’ve done had I not known redux is simply write and import a function called handleLogin(). When it fires the state is changed right there by the function! The concerns are separated, there’s no god object, it’s logic is written once and context can take care of the prop drilling issue.

@SortOfTested hey I like RxJs too. I first learned Angular then RxJs then it was very good. I like RxJs. Then I learned how redux works then I was like yuck 🤢
I'd rather use hooks and context API OR RxJs than that yucky Redux.

I don't care about that Redux time travel browser extension.

@SortOfTested I never heard of CQRS until your post, and it looks like redux is based off that pattern! I would’ve understood redux way more but none of the countless lessons I put myself through brought it up! I’m pissed that none of the redux articles I tried to get my head around mentioned this! They gave the same mantra of “u need this for complex state because reasons ok article over hope u learned stuff” while being vague as hell probably bc they don’t understand themselves. Then the fake reviewers giving five star ratings “I’ve read countless tutorials but this article finally clicked! Very clear!” -John S

@d-fanelli

Yep. I've pointed it out countless times to hundreds of people. It also includes Sagas in the latest person, which is just the saga pattern cooked up at cornell. And of course it's a poor implementation of that as well.

These fucking easy buttons are making the same mistakes everyone made in 2000 all over again.

https://cs.cornell.edu/andru/cs711/...

@SortOfTested And you never would’ve had to if these damn articles and vids introduced it! I bet those hundreds were just as lost as I was!

@d-fanelli
Most of the people writing the articles we're totally unaware it was even a pattern.

@SortOfTested that’s bc whoever taught them was unaware.

@SortOfTested This redux tool has not only been one of the most confusing things I’ve learned in programming out of all the college classes and on the job training I had, it’s made a huge dent in my self esteem bc I’m used to getting things quickly and I spent a couple months this fall feeling down about this. I would see redux being applied across numerous projects feeling jealous and angry thinking they get something about redux that my pea brain can’t even after all this time, all these tutorials and lessons! I never understood why they were using it but maybe they weren’t using it properly to begin with

Vue loves you

My first encounter with Vue.js happened around the end of 2015 as I was looking for a viable alternative to AngularJS and React.