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

331–340 of 382 posts

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

#331

Post by mattmanser »

Falling3 wrote: post #329
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…

> streets ahead Pierce? Is that you?

No, I'm from the UK, it's a common idiom over here.

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

#332

Post by DCoder »

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.

TSX views with full typechecking blow all stringly-typed templating solutions like Knockout Templates out of the water. In addition to that, immediate DOM repaint without any consolidation is inefficient and hard to debug at times.

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

#333

Post by mosdl »

acemarke wrote: post #326
mosdl wrote: post #323

Earlier quoted context omitted.

What connect optimizations? Redux is quite slow.

`connect` does a _lot_ of work to ensure that your own components only re-render when necessary: - It checks to see if the root Redux state is different than last time, and bails out if it's the same reference under the assumption that nothing changed - It checks to see if the return values from your `mapState` function are shallow-equality different than last time, and again bails out if they're the same - The handl…

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.

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

#334

Post by biggerfisch »

ixtli wrote: post #291

One of the gems in this that i think might be getting overlooked: > This trend of using chats for questions is plaguing open source projects and I think it needs to end. There is no collective learning anymore. This is a very important notion not least of all from an archival pov.

I see why many people consider this to be a problem, and it does severely limit the ability of knowledge to persist, but I think there are some benefits to it, namely that the answers can always be up-to-date.

I don't know how many times I've found answers for versions of my libraries/toolkits that are so old that they're useless. There's little point these days in persisting answers to questions about Node 0.4.0, for example - and that's only ~7 years old, downright modern by some viewpoints.

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

#335

Post by crazyideaman »

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?

Vue's single file components (SFC) require a build tool such as Webpack or Browserify. See https://vuejs.org/v2/guide/single-file-components.html

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

#336

Post by kalkut »

boubiyeah wrote: post #287
kalkut wrote: post #245

Earlier quoted context omitted.

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-compo…

That's just a more Object Oriented Redux (or less, if we consider OOP is originally message passing), and probably without all the connect optimizations. I'm not a fan of Redux either, but I fail to see what problems this approach solves.

> That's just a more Object Oriented Redux

> I fail to see what problems this approach solves.

You are absolutely right I gave an ad-hoc Redux as an example of Higher-Order Component.

Being OOP or not is only a matter of implementation of your data source. Here you have absolute control on it and depending on the type of your data, the frequency at which it is updated or its (a)synchronicity, you may prefer/need something very different from a dispatcher/action/reducer system.

The real pattern here is the HCO and yes Redux also use this pattern to build "smart components" with "dumb" ones. But it does it in a very opinionated way.

As an example : for performance reasons you really don't want Redux to handle real-time data with very frequent updates, it is better to manage this kind of data your own way.

A more common case is having only a few amount of data that have to be shared across the tree (things like an user session or the chosen language). If your component tree has too many level of depth an ad-hoc solution can do fine here.

IMHO there is two type of arguments for why Redux might not be needed :

1) A reasonable UI respects separation of concerns.

There should be limited need for data exchanges or interactions between two unrelated components. Making the data flow from the local state of a "smart component" is fine most of the time.

2) What Redux does can be done with less boilerplate when and where it is needed.

You can make your component "smart" in a lot of ways. It can be done with pure React state management, it can be done with custom data sources and HCO, it can be done with JavaScript CustomEvents and so on.

The worst problem here is that because Redux is a (very good) opinionated abstraction, lots of developers forget it is a library and not a framework so they try to find what they think is the most Redux-way of doing things. I've seen tons of projects that ended up being a mess of Redux/Thunk/Reselect plus whatever middlewares where updating a single property implies at least handling it in the reducer, adding a selector, and adding the result in mapStateToProps. Redux is definitely not a bad solution but in becoming a standard one it hurt a lot of projects.

This situation is very well explained by pcstl above when he says

> People mainly use Redux because they don't understand that React isn't Angular.

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

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

#337

Post by rajangdavis »

sne11ius wrote: post #316
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…

I haven't used nuxt, but this vuejs component "hides" the wrapped component during server render: https://github.com/egoist/vue-no-ssr Regarding the "client/server render results do not match" issues: Fixing these is mostly easy in my experience, especially since vue will log the offending dom nodes to the dev console.

To clarify, this is not quite what I am looking for.

My challenge is that I don't want everything to be rendered on the client. I only want very specific things to be client rendered and nuxt does not have a way to do this (I think).

The no-ssr thing is the opposite of the functionality that I would like. I want to have the ability to declare which pieces are only server rendered and sprinkle in in client-side rendering where it makes sense.

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

#338

Post by kalkut »

mosdl wrote: post #333
acemarke wrote: post #326

Earlier quoted context omitted.

`connect` does a _lot_ of work to ensure that your own components only re-render when necessary: - It checks to see if the root Redux state is different than last time, and bails out if it's the same reference under the assumption that nothing changed - It checks to see if the return values from your `mapState` function are shallow-equality different than last time, and again bails out if they're the same - The handl…

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.

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

#339

Post by sbjs »

dmitriid wrote: post #290
ipntu wrote: post #286

Earlier quoted context omitted.

This is patently not so. Maybe if you are used to JSX. - three different html-like attributes : and @ are just shorthand for v-bind and v-on attributes. v-bind and v-on (and v-if) accept regular javascript, and it's not just expressions... you can use `active = true` to change a data value, for instance. The only exception is v-for, as you mentioned, but it is close enough to ES6 for syntax to make sense, at least IM…

> just shorthand > accept regular javascript... The only exception is... but it is close enough to ES6 So you basically validated all I've said. And it's also incomplete. Because the amount of gotchas and things that you have to constantly keep in mind in Vue is mind-boggling compared to JSX. Because JSX is a paper-thin wrapper on top of React.createComponent, and goes out of its way to keep everything in Javascript.…

Just wanted to add to your argument an inverse argument (for JSX, instead of against Vue):

JSX is actually just JavaScript with this one special rule:

    child1 {child2}
becomes

    transform("foo", { bar: baz, children: ["child1 ", child2] })
That's it. All the rules of JSX can be inferred from that one transformation.

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

#340

Post by infinite8s »

The_suffocated wrote: post #300
buremba wrote: post #9

Earlier quoted context omitted.

I wonder how you avoid writing stateful components in real-world complex SPAs.

Discussions of this sort are often confusing. When one talks about using Redux or some javascript library to do "state management", I always wonder whether one is talking about application states (i.e. states originating from business logic but unrelated to UI) or UI states.

Application states. Redux isn't meant to maintain UI state.
Post reply on HN