4 ms·
Coming from Angular, I'm biased towards entities declared in the form of a class. It's a style that is easy to manage and familiar to most programmers. Vue cu
by jordache 9y ago
Coming from Angular, I'm biased towards entities declared in the form of a class. It's a style that is easy to manage and familiar to most programmers.
Vue currently seems to be a mix bag of styles. My take away from the little that I dabbled:
- You need the vue-class-component dependency in order to declare class based components, otherwise, you're stuck with the awkward object literal notation
- For state management using Vuex. You are are limited to the object literal style to declare your state store. Very awkward to work with.
Yes to get some data bound to a template and rendered out, Vue takes very little amount of code. However that is not a meaningful benefit to me. I feel Angular's complete framework and class based convention is much more suitable for a team environment.
- philliphaydon 9y agoI couldn’t disagree more. Unless your team have Super in depth knowledge of angular then it’s the wrong choice. It’s defaults to progagate changes cause rendering perf issues that are so frustrating to fix. Out of the box react or vue performs better than angular hands down. I hate that after learning angular 2 I realise I should not followed tutorials and advice and just switched all the defaults off on classes and manually propagate changes when required cos it’s a painful task to do.
- jordache 9y agoI don't know what convoluted patterns you where implementing, but out of the box, the default change detection in angular is performant, esp if you start to leverage observables and the async pipe (to eliminate the need for component onDestroy maintenance tasks). It's a joy to use. Yes Angular provides a lot more options than react or vue, and maybe confusing given the scope of what's possible. However, after the initial learning curve, Angular is a very efficient framework / pattern to work with in a team setting. If you resort to manual change detection, then it's an obvious sign of needing to refactor your design.
- philliphaydon 9y agoThe default change detection can cause the whole page to redraw. Especially if you have a lot of data. It gets even worse.
- jordache 9y agoit's pretty much the same change detection logic across all of these frameworks. Immutable data is key to performant change detection. Angular provides the ability to bind template to immutable state data so the framework can provide the most performant change detection
- philliphaydon 9y agoExcept it's not the same across all these frameworks. If I build a grid with 15 columns and 3500 rows (actual issue faced) which contains 3 characters in a cell and a menu when clicking on the cell. Out of the box Angular took ~8 seconds to make it appear on the screen. Vue and React were both less than 1 second. If I changed the value of a cell, then Angular would redraw the entire grid, Vue and React just updated the cell. You know what the Angular gitter room told me to do... turn off change detection... Changing it to 1 way binding resolved the rendering time and made it on par with the other 2, but it's still frustrating, especially when the same example in Angular 1 worked in less than 1s with 2 way binding.
- jordache 9y ago>Changing it to 1 way binding resolved the rendering time and made it on par with the other 2, You have to explicitly enable 2 way data binding in Angular 2.x +. Angular 2.x+ is 1 way data binding by default. This is a key differentiation between AngularJS 1.x and Angular 2.x+ The fact that you imply you had 2 way data binding initially means you were using angularJS 1.x (not Angular 2.x +) Or if the latter, you had some very poor design decisions to settle on a 2 way data binding solution. Vue and React both are by default 1 way data binding.