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

41–50 of 382 posts

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

#41

Post by aylmao »

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…

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

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

#42

Post by ng12 »

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…

Actually that's my favorite thing about the Redux model.

The vast majority of our codebase is comprised of simple idiomatic React components. Our reducers and glue code (e.g. @connected containers) are a very small portion of the codebase. If I woke up tomorrow and decided Redux was the source of all our problems I could completely remove it while only needing to refactor a small portion (<5%) of our codebase that's mostly boilerplate anyways.

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

#43

Post by ilovecaching »

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…

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 experience a good website does group related pieces of information, and so well organized state often maps easily to a well organized UI, functional programming gives us the tools to avoid deeply nested expressions regardless of your application (or even your framework).

One thing to realize is that you always get to decide on the granularity of your compositions. It is not necessary to build a deep hierarchy if you design the granularity of your interfaces correctly. Another great tool is higher order functional programming, such as passing components to components (via children). In this way, it is easy to describe generic interfaces and supply specific pieces of data without having the intermediary interfaces know or care about that data. Another approach, akin to using something like the state monad, is to use Reacts context feature, but this is rarely needed, in my experience.

Personally I make heavy use of higher order components, and I find I rarely exceed a component tree height of three.

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

#44

Post by dangerbird2 »

ElatedOwl wrote: post #28

We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works. TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen. There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design v…

Typescript support has gotten much better in the past few months. In particular, the vue-cli scaffold provides the correct stubs so typescript doesn't freak out when importing single-file components.

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

#45

Post by RussianCow »

noir_lord wrote: post #21
parr0t wrote: post #5

Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technica…

I just put those Api calls in a module in the same dir as the component usually. Then api.fetchFoo(bar).then() mostly does it. Benefit is separation of API from component.

This doesn't actually solve the dilemma of where to put the logic—all you've done is moved the API code into its own object, but your component is still the one controlling the higher-level flow in this case.

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

#46

Post by ilovecaching »

allover wrote: post #33
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…

> 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? Sadly it seems that's mainly been cargo-culted. It's not the case that React+Redux is the equivalent to say Angular, but by some unfortunate accident due to Facebook's announcement of Flux, and then the hype around Redux as a 'better Flux', people started assuming Re…

Agreed. Cargo culting is the main issue. The solution is to try and remain unbiased, and not look for direct synonyms between two very distinct approaches to managing user interfaces.

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

#47

Post by keithnz »

fiatjaf wrote: post #6

It is good just for the simple stuff, the world of webapp examples, todo lists and so on. For all that, Elm is much better. For all things more complicated and that require intelligence to think about good architecture and how to structure state, the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations. Also, the community on Discord is not friendl…

do you have any concrete reasons why? I've done a lot of Vue and React, and long term I have found Vue much more maintainable and productive. Not saying there is anything wrong with React. But I just don't see Vue as a limitation on writing complex apps.

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

#48

Post by pier25 »

fiatjaf wrote: post #6

It is good just for the simple stuff, the world of webapp examples, todo lists and so on. For all that, Elm is much better. For all things more complicated and that require intelligence to think about good architecture and how to structure state, the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations. Also, the community on Discord is not friendl…

> the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations.

Can you elaborate on that?

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

#49

Post by xj9 »

buremba wrote: post #30
ilovecaching wrote: post #14

Earlier quoted context omitted.

It's quite easy, I honestly think the only roadblock is how one thinks about computation. If you think of your UI as a single computational expression you're building up from functional composition, then the issue of state never arises. It's just about defining the shape of the interfaces.

Sounds cool but I can't actually imagine the way you described. :) Any tutorials, articles?

try working through some tutorials on erlang/otp supervisor trees. the concepts are very similar.

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

#50

Post by heisenbergs »

ElatedOwl wrote: post #28

We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works. TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen. There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design v…

vue 3 will be entirely rewritten in typescript.

https://github.com/vuejs/roadmap

Post reply on HN