Live data from Hacker News

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

medium.com

281–290 of 382 posts

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

#281

Earlier quoted context omitted.

> 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. It took me many years to realize this. I think very few front end developers understand this. And more problematically: very few framework devs seem to understand it. Stated another way.... Your tree of UI widgets, and Your tree of data which feeds those widgets ... are two orthogona…

>Your tree of UI widgets, and >Your tree of data which feeds those widgets Not with a well-designed XML format and XSL-T! But hmm, nobody seems to use that anymore either.

IIRC, Colloquy (a macOS IRC client) used to do this. Each IRC channel was basically an XML feed, and the theming was just XSLT applied to the XML feed and the output displayed in a WebView widget.

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

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

I'm not sure attributes named as "ref" or "className" qualify either as Javascript or HTML

[deleted]

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

#283
post #55

Earlier quoted context omitted.

Our site does't work with js disabled. Serious question: is it common for folks to disable js? vue is used only for the web app. No js frameworks used in the chrome app.

It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no…

Good to know, thank you.

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

#284

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…

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?

Because React = state to DOM while Redux = how to get from previous state + action to a next state? :)

They do different things.

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

#285
post #25

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…

For me (Vue + Vuex) the choice was simple: you get undo for free. Having a shared store really does change the way you look at web apps - it's almost a completely different paradigm. If you can avoid re-loading the data for a view if you already have it then then opening a new view to edit a subset of the data instead of dealing with popup makes life so much easier - you get a lot more freedom with the UX and going b…

But now you have a new problem: Managing the freshness of that cache.

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

#286
post #235

Earlier quoted context omitted.

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

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

    - three different scripting languages in templates (two Javascript-like, one Javascript, but only expressions)
This is splitting hairs a bit, isn't it? Apart from v-for, you can write pretty much anything you want in the other two.

    - 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
You mean the script part of components? Do you have any examples of that?

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

#287
post #245
post #205

Earlier quoted context omitted.

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

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

#288

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.

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

#289

Earlier quoted context omitted.

Netflix, Walmart, etc. solve a much different set of problems than most shops. I'm proud to work for a small company with simple (but rapidly changing) requirements. :)

That doesn't answer my question. What about Vue actually made it a better choice for those requirements? In my experience, the fact that React is a simple view library makes it the perfect choice for small shops. You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested…

> You're taking on considerable risk when you use a technology without a vested backer

I hear this line a lot, and it reminds me of Warren Buffett's line about finding out who's swimming naked when the tide goes out. He's referring to unprofitable companies that get exposed during economic recessions, when their stock prices are no longer boosted by generalized positive sentiment (I'm oversimplifying).

In this context, I think frameworks get exposed when big company support gets withdrawn. Angular didn't always look like an abandoned beached whale. Initially, having the backing of Google made it look like a de facto obvious choice. But when support from a large backer wanes, it quickly accelerates the demise of a framework as what the halo effect previously presented as well-considered design choices are suddenly recast as clear mistakes in hindsight.

This might never happen with React. But if it does, it will be swift and loom with unmistakable signs in the rearview mirror.

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

#290
post #286

Earlier quoted context omitted.

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

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

Lets see your defence:

- : and @ as shorthands

It means new syntax that you have to learn, and know differences between. For all intents and purposes Vue has three different types html-like attributes. JSX has only one: javascript names.

- v-bind etc. accepting regular Javascript

Let's see how this is false:

    
This is not Javascript. If it was, it would assign the result of the function call to @click. It doesn't. It's a Javascript-like scripting language that has magical binding into regular Javascript.

- exception is v-for, as you mentioned, but it is close enough to ES6 for syntax to make sense

So, it's not Javascript (unlike some other places where it is Javascript), and it's not ES6 syntax, but it's "close enough to ES6". So it's not. It's a different Javascript-like scripting language.

The only place where Vue allows regular unadulterated Javascript is inside curly braces: {{}}. And there it only allows expressions (Note: JSX also only allows expressions inside curly braces).

However. Even there it's not Javascript. Not really:

    {{ record.commit.message | truncate }}
Valid Vue. Invalid Javascript.

- You mean the script part of components? Do you have any examples of that?

Of course. See inline comments. Example from here: https://vuejs.org/v2/examples/tree-view.html

    Vue.component('item', {
      template: '#item-template',
      props: {
        model: Object
      },
      data: function () {
        return {
          open: false
        }
      },
      computed: {
        isFolder: function () {
          // `this.model` magically hoisted into `this`
          // from `object.props.model`
          return this.model.children &&
            this.model.children.length
        }
      },
      methods: {
        toggle: function () {
          // `this.isFolder` magically hoisted into `this` from
          // `object.computed.isFolder`
          if (this.isFolder) {
            // `this.open` magically hoisted into `this` from
            // `object.data` which is a function that 
            // returns an object whose keys and values are hoisted 
            // into `this`
            this.open = !this.open
          }
        },
        changeType: function () {
          if (!this.isFolder) {
            // this.open can be set directly. Magic
            // this.model.children cannot. Not magic
            Vue.set(this.model, 'children', [])

            // `this.addChild` magically hoisted into `this` from
            // `object.methods.addChild`
            this.addChild()
            this.open = true
          }
        },
        addChild: function () {
          this.model.children.push({
            name: 'new stuff'
          })
        }
      }
    })
Post reply on HN