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

351–360 of 382 posts

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

#351

Post by dave7 »

anderspitman wrote: post #311
tnolet wrote: post #292

Earlier quoted context omitted.

Yes! Also things like Gitter and Slack are really messy for storing knowledge. Questions get lost, answers are interspersed with more questions. Maybe I'm getting old, but give me a forum based, one-thread per topic any time of the day.

I prefer forums as well, at least for technical questions/discussions. It seems to me the biggest advantage of chat apps over forums is that you can use a single account to join many rooms. Are there any forum platforms designed around that idea?

> Are there any forum platforms designed around that idea?

That's basically Reddit

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

#352

Post by b34r »

anderspitman wrote: post #311
tnolet wrote: post #292

Earlier quoted context omitted.

Yes! Also things like Gitter and Slack are really messy for storing knowledge. Questions get lost, answers are interspersed with more questions. Maybe I'm getting old, but give me a forum based, one-thread per topic any time of the day.

I prefer forums as well, at least for technical questions/discussions. It seems to me the biggest advantage of chat apps over forums is that you can use a single account to join many rooms. Are there any forum platforms designed around that idea?

Spectrum.chat

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

#353

Post by acemarke »

kalkut wrote: post #350
acemarke wrote: post #346

Earlier quoted context omitted.

Hmm. Could you maybe file an issue on the React-Redux repo and provide some repro examples for your use case? I'd be interested in seeing the perf traces myself. This would also be valuable as we work on refactoring React-Redux to work with the new React context API. I have a hunch that my proposed architecture will improve perf, but having more benchmarks would be helpful.

You really are helpful and you try to fix this so I really want to say yes but I am currently grinding for my own startup so I know that a lot of time will pass before I actually do it so I don't promise anything. A good way to test it would be to make a simple websocket server that simulate n users each sending n' fake xyz position and rotation data per second. This data updates a Redux store in a React app made wit…

Gotcha. I've made a note of this in https://github.com/reactjs/react-redux/pull/898 for future reference.

If you ever do have some free time to throw together an example app that demonstrates this behavior, please feel free to link it in that issue, or ping me directly (Twitter and Reactiflux are usually best).

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

#354

Post by Globz »

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…

Just to add some weight to your opinion about Redux being cargo-culted take a look at this video

https://youtu.be/S6lwJ6Rixnc?t=6m

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

#355

Post by hardwaresofton »

easymovet wrote: post #288
hardwaresofton wrote: post #203

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…

Has anyone actually run into limitations of knockoutJS that Vue or React solve? Knockout has typescript support, stable codebase, excellent tutorials, large plugin base, and components that can be loaded with requireJS. We've had great luck with it in the wild too.

I think they're just about equivalent -- especially since Knockout's addition of components explicitly as a paradigm (which was a loooong time ago[0]). It's really just a matter of where the hype-train ends up going over the years.

I tried out knockout's components way back when I saw the blog post[0], and they were pretty nice.

[0]: http://www.knockmeout.net/2014/06/knockout-3-2-preview-compo...

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

#356

Post by Too »

mateuszf wrote: post #220
aylmao wrote: post #41

Earlier quoted context omitted.

> 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

Both Airbnb and O365 web apps are horribly slow in the browser and hasn't had any noticeable feature growth in the past 4 years so i wouldn't use these as good examples of neither performance nor productivity.

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

#357

Post by Too »

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.

Vue also has "1.5-way binding" with computed properties, which is what you normally need 2-way binding for, but without all the problems full 2-way binding might introduce.

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

#358

Post by Too »

nogridbag wrote: post #319
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…

>>The reactivity system will only track changes under certain conditions. Don’t expect to throw anything you wish at it >This is the one part I hate about vue. Haven't used Vue for a while, but if I recall correctly it will only track changes on keys defined in the original data object. Is that what you and the parent are referring to?

Angular has similar problems, it is dangerous to replace an array rather than replace the elements of an array for example.

Don't know how vue compares with this but for angular beginners this is a very common mistake.

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

#359

Post by Too »

narrowtux wrote: post #265
mmcnl wrote: post #66

The ugly in this article isn't really the ugly, it's the good. Nobody's holding you back from writing a simple ES6 module that handles API requests for you. Vue is a view layer, nothing more and nothing less.

To be fair, being used to full frameworks such as angular, you think that you have to do it in some kind of vue-way or react-way. I even made the mistake of using a vue-specific HTTP library when I started. Only later I learned that Vue and react give you the freedom to do whatever you want.

Great comment. Seeing all the hate Angular gets I think this is the biggest mistake people do when they use angular, they try to do everything the angular-way with an angular service for everything, like you say even getting a angular-specific HTTP library, wtf?! They should have just removed the whole concept of services to not confuse people. If you instead only use it as a view layer it is actually quite nice. Same with vue and react, you should only use it as a view layer, not build your entire business logic on top or around of it!

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

#360

Post by mattmanser »

pjmlp wrote: post #252
mattmanser wrote: post #234

Earlier quoted context omitted.

Having done this in the wild a while ago, it seemed to be hard for most of the other developers to do anything complex with it. You either really got it and then could do wonderful things, or you sorta muddled along with it and it was ok but it was like they were wearing a straitjacket. I made a pivot table control out of it, with almost all the logic inside the XLST, it was amazingly fast compared to IE6's javascrip…

Once upon a time my web site was doing all the rendering via XML/XLST, and I looked forward to what might have been Web Components via the XML Components standards. Oh well, at least Web Components seem to finally be around the corner, a decade later.

Yes, the lack of reusable controls in hrml is utterly crazy!
Post reply on HN