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

341–350 of 382 posts

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

#341

Post by acemarke »

kalkut wrote: post #338
mosdl wrote: post #333

Earlier quoted context omitted.

In large apps mapStateToProps gets called when things my component doesn't care about change - its a simple downside to having one global store as a design. We now speed things up buy removing redux and just using events with multiple stores anyone can access - we can easily tune the system and don't have to rely on magic that can never be as efficient. Plus the syntax is much cleaner.

Dispatch is another big culprit. I have exactly the same experience and implemented the same solution. An ex-colleague also did the same thing. We both worked on collaborative webapps but in different companies at the time so performance gain was very important. I still use Redux on some projects but I definitely start the new ones without thinking about it.

> Dispatch is another big culprit.

Could you clarify what you mean by that?

Per both of your comments: generally speaking, your `mapState` functions _should_ run as quickly as possible. Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those.

If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut down on unnecessary work.

So, in a well-written app, your `mapState` functions shouldn't be bottlenecks.

As I said, if you've got some examples of specific perf issues, I'd be happy to offer advice.

[0] https://blog.isquaredsoftware.com/2017/12/idiomatic-redux-us...

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

#342

Post by mosdl »

acemarke wrote: post #341
kalkut wrote: post #338

Earlier quoted context omitted.

Dispatch is another big culprit. I have exactly the same experience and implemented the same solution. An ex-colleague also did the same thing. We both worked on collaborative webapps but in different companies at the time so performance gain was very important. I still use Redux on some projects but I definitely start the new ones without thinking about it.

> Dispatch is another big culprit. Could you clarify what you mean by that? Per both of your comments: generally speaking, your `mapState` functions _should_ run as quickly as possible. Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those. If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut…

The problem is that they run too often, not that they are slow. mapStateToProps is called too often, and that leads to a bunch of needless shallow compares and often renders. Its a weakness of the magic design, and if I need to optimize the magic might as well just implement the whole thing.

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

#343

Post by mosdl »

acemarke wrote: post #308
allover wrote: post #253

Earlier quoted context omitted.

Yep, sorry I should have included the reference. This post is by the redux-form creator, in which he states why it was a bad idea, and announces its 'spiritual successor': https://codeburst.io/final-form-the-road-to-the-checkered-fl... > Also, everyone high up in the React community, including both inventors of Redux [1], say that Redux is not the best place to keep form data. Oops. [1] https://github.com/reactjs/red…

Now, it _does_ depend on your use case. An isolated login form? Yeah, no point keeping that in Redux - it's not being shared, it's not being persisted, there's no real need to track the history of changes. But, there are certainly situations where you might want to keep some form data in Redux. As a specific example from my own app: we show some polylines on a 3D globe, and allow the user to edit them. We need to be…

You can achieve all of that with a singleton that is shared and some events (and do some of your own batching). No need for another dependency and you save bloat size.

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

#344

Post by d0100 »

pcstl wrote: post #228
Vinnl wrote: post #214

Earlier quoted context omitted.

> Your application state should be kept separately, Is Redux not exactly that?

It can be used for that, but it quickly becomes cumbersome. Redux, in my opinion, should be used for complex UI state in applications with complex interfaces where interactions with one part of the UI can change very different parts ("spooky action at a distance", so to say). But it shouldn't be used to keep all your application's state. Your application's state should live outside of React, and be passed in as the r…

I think the opposite.

Redux should have your application state, and any UI state should be in pure React (portals, context, etc).

Redux -> app data React -> UI

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

#345

Post by kalkut »

acemarke wrote: post #341
kalkut wrote: post #338

Earlier quoted context omitted.

Dispatch is another big culprit. I have exactly the same experience and implemented the same solution. An ex-colleague also did the same thing. We both worked on collaborative webapps but in different companies at the time so performance gain was very important. I still use Redux on some projects but I definitely start the new ones without thinking about it.

> Dispatch is another big culprit. Could you clarify what you mean by that? Per both of your comments: generally speaking, your `mapState` functions _should_ run as quickly as possible. Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those. If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut…

> Could you clarify what you mean by that?

A call to dispatch is significantly more expensive than the update of a JS object

> Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those.

Ideally it should, but in practice it is really much more expensive than getting a value in a JS object

> If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut down on unnecessary work.

I used Reselect before removing Redux. Beyond the fact that it adds a lot of boilerplate it does not help if you do need a lot of data updates.

> So, in a well-written app, your `mapState` functions shouldn't be bottlenecks.

It shouldn't but a few dozen of updates per second through Redux on a mobile take a toll on its performance serious enough to not be able to keep 60fps in a WebGL context.

I decided to remove Redux after noticing the performance overhead per function call in the Chrome performance profiler, so I know that in practice "dispatch" and "mapState" are not comparable to just editing or grabbing "a couple values from the Redux state"

My ex-coworker had the same issues because he needed to display a lot of items handled collaboratively with smartphones. In both of our cases we have a high rate of data updates, even if we optimize like crazy we are never going to fall under 4-5 update/second per connected user.

So yeah Redux can run well for webapps with a slow/regular pace of update but for more performance sensitive apps you do pay a Redux performance tax.

Again I still use Redux on some projects and I like it but the limits are there. So now I don't hesitate to do without it first and to use it when I need its abstraction.

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

#346

Post by acemarke »

kalkut wrote: post #345
acemarke wrote: post #341

Earlier quoted context omitted.

> Dispatch is another big culprit. Could you clarify what you mean by that? Per both of your comments: generally speaking, your `mapState` functions _should_ run as quickly as possible. Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those. If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut…

> Could you clarify what you mean by that? A call to dispatch is significantly more expensive than the update of a JS object > Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those. Ideally it should, but in practice it is really much more expensive than getting a value in a JS object > If a component needs the store data to be transformed in some way, we recomme…

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.

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

#347

Post by shakna »

The_suffocated wrote: post #301
shakna wrote: post #70

Earlier quoted context omitted.

Version with debug enabled: Production version: If you need something more complex, vue-cli has webpack inbuilt: vue init webpack my-project cd my-project npm install npm run dev Or if you need webpack, but not the complexity, swap the word 'webpack' in the above command to 'webpack-simple'. ... Vue has already done the hard work of getting the build apps configured for you.

I don't follow. How to use Vue's single-file component if you only load Vue from a script tag? And can I use Brunch instead of Webpack if I want to use single-file components?

> And can I use Brunch instead of Webpack if I want to use single-file components?

Probably, but Vue only officially supports Webpack or Browserify.

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

#348

Post by [deleted] »

mosdl wrote: post #343
acemarke wrote: post #308

Earlier quoted context omitted.

Now, it _does_ depend on your use case. An isolated login form? Yeah, no point keeping that in Redux - it's not being shared, it's not being persisted, there's no real need to track the history of changes. But, there are certainly situations where you might want to keep some form data in Redux. As a specific example from my own app: we show some polylines on a 3D globe, and allow the user to edit them. We need to be…

You can achieve all of that with a singleton that is shared and some events (and do some of your own batching). No need for another dependency and you save bloat size.

[deleted]

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

#349

Post by acemarke »

mosdl wrote: post #343
acemarke wrote: post #308

Earlier quoted context omitted.

Now, it _does_ depend on your use case. An isolated login form? Yeah, no point keeping that in Redux - it's not being shared, it's not being persisted, there's no real need to track the history of changes. But, there are certainly situations where you might want to keep some form data in Redux. As a specific example from my own app: we show some polylines on a 3D globe, and allow the user to edit them. We need to be…

You can achieve all of that with a singleton that is shared and some events (and do some of your own batching). No need for another dependency and you save bloat size.

Well, the whole app is built around Redux in the first place :)

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

#350

Post by kalkut »

acemarke wrote: post #346
kalkut wrote: post #345

Earlier quoted context omitted.

> Could you clarify what you mean by that? A call to dispatch is significantly more expensive than the update of a JS object > Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those. Ideally it should, but in practice it is really much more expensive than getting a value in a JS object > If a component needs the store data to be transformed in some way, we recomme…

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 with Aframe (HTML wrapper around ThreeJS). You make n cubes move and rotate along the data in the store. Compare the fps you get against the fps you get with a vanilla solution. Also check what happens on the performance tab of chrome

I am able to recognize that my use case is very specific. I used React/Redux/Reselect and Aframe/ThreeJS with sockets a year ago. Now I kept React but the rest of the stack have changed for nearly a year

Post reply on HN