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.
Vue.js: the good, the meh, and the ugly
281–290 of 382 posts
Re: Vue.js: the good, the meh, and the ugly
#282Earlier 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
Re: Vue.js: the good, the meh, and the ugly
#283Earlier 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…
Re: Vue.js: the good, the meh, and the ugly
#284I 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…
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
#285Earlier 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…
Re: Vue.js: the good, the meh, and the ugly
#286Earlier 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
#287Earlier 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…
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
#288I 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…
Re: Vue.js: the good, the meh, and the ugly
#289Earlier 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…
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
#290Earlier 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…
> 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'
})
}
}
})