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

211–220 of 382 posts

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

#211

Post by vanderZwan »

crimsonalucard wrote: post #160

My problem with current gen frameworks is composition and modularity with components. Making components stateless and having all data come in as props from parents is good for modularity but how do you pass data back to the parent? This is where the modularity becomes awkward. I know of two ways in vue to do this and both ways either completely break or make modularity awkward. The first way is to signal the parent w…

> The second way is to use vuex as a global. This breaks modularity by immediately tying the component to a global. Vuex makes things easy but breaks modularity completely as soon as a component refrences vuex.

Can you explain a bit what you mean here?

I haven't used vuex yet, but to use my Redux/React experience as stand-in: the channel to emit data changes through is passed as a prop as well, so the component is still "modular" in that it is not hardwired to redux (or, presumably, vuex). Since it has to connect to the outside world somehow, that can't be the criterium for breaking modularity either. So I don't see where the modularity

Having the data in a Single Source Of Truth seems a sensible reason to store it globally as well.

(aside: elsewhere here I discovered S.js, a reactivity library that looks really interesting. Perhaps using something like that to make the data reactive to UI changes is what you're after?)

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

#212

Post by hvidgaard »

> Vue is really fast. Maybe not the fastest, but its performance is overkill for the vast majority of web projects. When was the last time you needed to render and update thousands of DOM elements per second?

Rubs me the wrong way. Better performance is always a net gain, and a high performance website provides miles better UX than the same website with waiting all the time.

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

#213

Post by Vinnl »

hvidgaard wrote: post #212

> Vue is really fast. Maybe not the fastest, but its performance is overkill for the vast majority of web projects. When was the last time you needed to render and update thousands of DOM elements per second? Rubs me the wrong way. Better performance is always a net gain, and a high performance website provides miles better UX than the same website with waiting all the time.

> Better performance is always a net gain,

I think that's easily disputed: it's always a trade-off. A 0.001 ms improvement in performance is a net loss if makes code 10x less readable, because that means programmers are more likely to introduce bugs, which would be a net loss. For example, I one worked with someone who changed all i++'s in a codebase to ++i's, even though they were not in performance-critical codepaths. That was not worth the effort.

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

#214

Post by Vinnl »

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.

> Your application state should be kept separately,

Is Redux not exactly that?

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

#216

Post by exwizzard »

sheeshkebab wrote: post #190
heisenbergs wrote: post #50

Earlier quoted context omitted.

vue 3 will be entirely rewritten in typescript. https://github.com/vuejs/roadmap

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

Why? The page clearly states:

Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users.

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

#217

Post by nnq »

What I still never saw so far, and what this article also avoids, was an actual explantion of

- why ever choose Vue over a minimalistic React setup?

I mean, yeah, when people say "React" they mean "Reach + a ton of other heavy complex stuff", but core react + redux seems even more lightweight than Vue. Or you'd just choose Vue to keeps way the "React gurus" that would come in and overcomplicate everything? :)

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

#218

Post by laichzeit0 »

davidmurdoch wrote: post #166
condescendence wrote: post #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…

I hadn't heard of laracast until starting Vue development a few weeks ago. The quality of answers were so low I found myself longing for the days of expertsexchange.com. Why did laracast get so popular for Vue? What was wrong with Stack Overflow?

What does gender reassignment have to do with Vue?

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

#219

Post by porker »

ilovecaching wrote: post #43
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…

So I see where you're coming from. To first address Redux, etc, React has no opinion on state storage, it's a feature not a bug. Obviously you need to store state somewhere, and Redux, Relay, etc are just tools to address that concern. But that's really unrelated to what you're trying to address, which is coupling between leaves that have shallow common ancestors, but are themselves quite deep. Although in my experie…

Is there a blog post explaining higher order components in more detail, preferably with examples?

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

#220

Post by mateuszf »

aylmao wrote: post #41
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…

> as soon as you're in the real world, you hit its limitations very quickly. Isn't a good chunk of AirBnB, Facebook, Instagram, Netflix, The New York Times and Dropbox written in React? The built-in state management has limitations, of course. I see it best for keeping state relevant to display-- React is supposed to be a "view" library, not a state management one.

And also Office 356
Post reply on HN