Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js: the good, the meh, and the ugly

medium.com

Post reply on HN
Print view View original

201–210 of 382 posts

Re: Vue.js: the good, the meh, and the ugly

#201

Post by eknkc »

andrewstuart wrote: post #69

I don't get the thing about ReactJS boilerplate where he says "Moving from React to Vue seems like a breath of fresh air. No more bind(this) or setState() everywhere. Yay! " Surely there's better ways of doing ReactJS rather than lots of setState? Of course I use setState but try to avoid it generally. And I almost never, ever use bind() - don't es2015 fat arrows make it obsolete?

Arrows create a brand new function on each render call. Say you have a pure component that you pass an onChange handler. If it’s an arrow function, the component needs to re-render as you created a new function. If it’s a pre bound function reference, the sub component will not receive any prop changes.

Otherwise, yeah.

Re: Vue.js: the good, the meh, and the ugly

#202

Post by mrinterweb »

stupidcar wrote: post #17
ilovecaching wrote: post #2

I 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…

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

I've felt the same way. Vuex, Redux, MobX, or other application state libraries, all help in the event when passing data down through components that don't care about the data they are passing along becomes tedious. I like the general idea of "data down, actions up", but when it comes to separation of concerns, what is the point of a component taking parameters that it is just going to pass to a subcomponent? When components don't use the parameters in a meaningful way, the parameters are just noise. I came to this realization after passing the same parameters down about seven levels deep through components to question the mantra. I try to avoid shared and global state, but there are times that it just becomes very useful. It is important to now and again question if the dogmatic approach is pragmatic.

Re: Vue.js: the good, the meh, and the ugly

#203

Post by hardwaresofton »

I agree with the point that one of the biggest warts on Vue are the corners of the reactivity system (first point in the "Not so magic" section of the article") and how it can surprise you. IMO if Vue had reactivity like KnockoutJS did, it'd be perfect on that front.

I disagreed with the "unclear architectural patterns" -- I've found just writing Vue components that function as Services to hold all that kind of logic more than adequate, and have never really needed to follow the Flux-ish/Vuex approach. 90% of the time all you're doing is making web requests and possibly displaying data or results to the user on the frontend... If you're clever, you're doing a little caching and figuring out when to perform remote fetches, or storing stuff in local/session storage.

I think Model-Service-View frameworks are the (minimal) future, where you just pair a view library with a data management component (something like Backbone, if not Backbone itself). MVC was the dominant paradigm (angular 1 days), then MVVM made an appearance (knockoutjs), and now MV-? where the ? is some event-driven system or flux/vuex style system. I think abstracting to Services allows flexibility at the model-management layer -- if you want your services to send out events (and wire up your components to listen), then good. If you want them to have promised based interfaces, that's fine too.

Re: Vue.js: the good, the meh, and the ugly

#204

Post by pcstl »

stupidcar wrote: post #17
ilovecaching wrote: post #2

I 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…

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

People mainly use Redux because they don't understand that React isn't Angular. React is meant to care only about UI state. Your application state should be kept separately, and React should just be a function from app state to UI.

Redux is what you get when people try to use React as a "full-app" framework instead of what it's meant to be: a view layer.

Re: Vue.js: the good, the meh, and the ugly

#205

Post by WA »

pcstl wrote: post #204
stupidcar wrote: post #17

Earlier quoted context omitted.

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

People mainly use Redux because they don't understand that React isn't Angular. React is meant to care only about UI state. Your application state should be kept separately, and React should just be a function from app state to UI. Redux is what you get when people try to use React as a "full-app" framework instead of what it's meant to be: a view layer.

So how do you manage your application state? I‘m curious, because a search for such a phrase always brings up Redux, Thunks and Saga.

Re: Vue.js: the good, the meh, and the ugly

#206

Post by Ronsenshi »

blencdr wrote: post #198
sheeshkebab wrote: post #190

Earlier quoted context omitted.

And that will probably be the end of vue...

have you even tried to use TypeScript on a real project to say something like that ?

He's possibly meaning that if you completely rewrite framework it would lead to something like what happened to Angular when it was rewritten and promptly lost huge number of followers/users?

Re: Vue.js: the good, the meh, and the ugly

#207

Post by jorblumesea »

philliphaydon wrote: post #193
jorblumesea wrote: post #130

One of the best arguments against Vue is typescript support. React has really good support for it, even for the state libs like Mobx/Redux etc. Until they turn that around it will be hard for any frontend application to scale properly. I think Vue is great for smaller projects and would absolutely recommend it.

TypeScript works fine?!?!? With @vue/cli it's trivial to setup, it's literally option in a new app. Vue 3 they are moving to TypeScript: > Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users. https://github.com/vuejs/roadmap#3x

Hardly as polished as other frameworks. Sorry, just not true.

Re: Vue.js: the good, the meh, and the ugly

#208

Post by kibibu »

spiritcat wrote: post #105
acemarke wrote: post #72

Earlier quoted context omitted.

Out of curiosity, what are you using instead of JSX? Plain `React.createElement()` calls, `createElement` aliased to a shorter variable like `e`, or something like the `react-hyperscript-helpers` library?

it's funny how originally jsx is what kept me away from react, and now it's what keeps me from leaving.

It's funny how everybody hated E4X when Adobe and Mozilla were doing it, and love JSX now.

Re: Vue.js: the good, the meh, and the ugly

#209

Post by tanilama »

stupidcar wrote: post #17
ilovecaching wrote: post #2

I 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…

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

Because async state management is a pain, and hard to reason about, that is what Redux and MobX are for.

Re: Vue.js: the good, the meh, and the ugly

#210

Post by erikpukinskis »

stupidcar wrote: post #17
ilovecaching wrote: post #2

I 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…

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

> the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM.

It took me many years to realize this. I think very few front end developers understand this. And more problematically: very few framework devs seem to understand it.

Stated another way....

Your tree of UI widgets, and

Your tree of data which feeds those widgets

... are two orthogonal trees.

If you are a front end dev and you haven’t spend time wrestling with that, I strongly recommend it. It’s extremely likely your front end architecture is suffering because of it.

React take the strongest stance on this matter, by making the interface to every widget be one giant shared global. But globals are bad, so while it’s good they acknowledge the situation, they mostly punt on the question of how to deal with it.

Post reply on HN