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

241–250 of 382 posts

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

#241

Post by dmitriid »

ipntu wrote: post #235
sbjs wrote: post #199

Earlier quoted context omitted.

Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.

The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX. It's not much, really. I personally find Vue templating syntax much easier to follow than JSX, but that's because I'm used to it. I honestly believe that's how React users feel about JSX too.

> The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX

This is patently not so.

Vue has:

- three different html-like attributes

- three different scripting languages in templates (two Javascript-like, one Javascript, but only expressions)

- one scripting language for controller/model which actually breaks JS assumptions (about what `this` is, for example) by magiacally hoisting some (but not all) properties of an object

https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large

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

#242

Post by akie »

porker wrote: post #219
ilovecaching wrote: post #43

Earlier quoted context omitted.

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?

Higher Order Components are like Aspect Oriented Programming - it takes a component and adds some stuff to it. It can add that stuff to any kind of component. That's all you really need to know.

Examples of HOC are the connect() call from Redux, or the withNavigation() from React Navigation, or injectIntl() from React-Intl. These respectively add Redux functionality, navigation functionality, and internationalization functionality to your component.

I think the name "Higher Order Component", like many things in the React world, is poorly chosen and actually obscures what it is, how it works, and makes it look more intimidating than it really is. It's technically correct (like 'reducer' is), but communicates nothing.

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

#243

Post by ipntu »

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…

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

That's my experience as well. If you use a deep component hierarchy you have bigger problems than those solved by Redux, VueX or the Context API.

Higher order components or even simple functional components are really underrated when it comes to making your application simpler to reason about and to maintain.

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

#244

Post by ipntu »

kevin_thibedeau wrote: post #64
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…

> I am never a fan of two way data binding as an alternative. The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.

A shame that this answer was downvoted on a technicality.

As other people mentioned, Vue indeed doesn't have two-way binding, and v-model doesn't have the pitfalls that Angular had. It is just syntax sugar.

Maybe it's about time Vue people remove the mention of two-way binding from their websites, since it is being used to attack the framework. I've seen that in other discussions here in Hacker News.

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

#245

Post by kalkut »

WA wrote: post #205
pcstl wrote: post #204

Earlier quoted context omitted.

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.

You can make any suitable variation of the following pattern.

You build a DataSource class/prototype with methods such as :

- fetch

- addChangeListener

- removeChangeListener

You extend this class for each data type :

  class CommentsData extends DataSource {
    // Your custom data source with your data treatment and data getters
  }
And you use the Higher-Order Component pattern: https://reactjs.org/docs/higher-order-components.html

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

#246

Post by rajangdavis »

breakingcups wrote: post #224
rajangdavis wrote: post #177

I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities. For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues wh…

With Nuxt, use the component: https://nuxtjs.org/api/components-no-ssr/ All my similar issues went away after discovering that.

This the exact opposite of what I am looking for; I want to be able to have components and pages that are rendered on the server side only

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

#247

Post by Fifer82 »

Ronsenshi wrote: post #206
blencdr wrote: post #198

Earlier quoted context omitted.

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?

Was that really a thing though? People cried because they didn't understand the offer of better tooling.

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

#248

Post by Fifer82 »

jazoom wrote: post #77
RussianCow wrote: post #68

Earlier quoted context omitted.

Without hard data, this is pretty meaningless. If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint. > I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see. Maybe existing users (and even for that, I'm sk…

>If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint. And I wouldn't miss you. I can make the service better faster if I don't support the lowest common denominator. I'm sure I'd lose more users if the website was bloated with fallback code and my development speed was such that features a…

I completely agree with this sentiment.

I absolutely hate the "does it work on ie6".

The time you spend dealing with old browsers is never returned in profit. I had one customer (ie10) in 4 years, and losing him cost me and made me nothing.

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

#249

Post by spiritcat »

kibibu wrote: post #208
spiritcat wrote: post #105

Earlier quoted context omitted.

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.

I didn't even know this existed.

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

#250

Post by davedx »

akie wrote: post #242
porker wrote: post #219

Earlier quoted context omitted.

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

Higher Order Components are like Aspect Oriented Programming - it takes a component and adds some stuff to it. It can add that stuff to any kind of component. That's all you really need to know. Examples of HOC are the connect() call from Redux, or the withNavigation() from React Navigation, or injectIntl() from React-Intl. These respectively add Redux functionality, navigation functionality, and internationalization…

I agree.

It's effectively a replacement for the old React mixin system.

It happens to use functional programming methods, but that's an implementation detail.

Post reply on HN