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

371–380 of 382 posts

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

#371

Post by dmitriid »

drunknhik wrote: post #369
dmitriid wrote: post #290

Earlier quoted context omitted.

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

Have you ever made a graphql server with apollo-tools? Do you complain that SDL is a "new syntax" that you have to learn when you can just use regular javascript? > > 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. Great, so it's not javascript. To a lot of folks it loo…

> Have you ever made a graphql server with apollo-tools?

Have I ever mentioned apollo or graphql tools? Let me check: no

> There's a lot less noise, and it's _much_ friendlier for (most) designers.

I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX.

And of course, it's not better than JSX for very obvious reason that you chose to ignore: how { } in JSX accepts plain JS with the only exception that it has to be an expression. And (and it's the most important part): curly braces in JSX mean and accept the same thing everywhere in JSX.

In Vue though: What do @ attributes accept? What do : attributes accept? What do curly braces accept? etc.

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

#372

Post by dmitriid »

likeclockwork wrote: post #367
dmitriid wrote: post #290

Earlier quoted context omitted.

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

> 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. You're wrong. The contents of the event handler is JS, the whole snippet is obviously HTML. Say Hi. This is also plain regular HTML and has been since HTML4 (1997). The value of the onclick…

I love it how you chose just one of so many things listed. And how you got it so wrong:

> This is also plain regular HTML and has been since HTML4 (1997).

What below is plain regular HTML? Taken from here: https://vuejs.org/v2/examples/tree-view.html

         [{{ open ? '-' : '+' }}]
Oh. Ooops. None of it. It's a custom HTML-like DSL with three types of magic attributes (magically bound to some Javasdcript code) with three different scripting languages in it.

For reference: https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Ev... etc.

Edit

Let's add more "plain old HTML". Plain old HTML v-ifs that accept JS booleans. Ah, plain old HTML v-fors that accept a ES6-like (but not truly ES6) mini-DSL. And other plain old HTML attributes.

    
      
      
      +

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

#373

Post by davestewart »

petepete wrote: post #13
parr0t wrote: post #5

Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technica…

It's not perfect, but I think Vuex Pathify can help keep Vuex organised and somewhat sane. https://davestewart.github.io/vuex-pathify/

Is there anything in particular you found sub-optimal?

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

#374

Post by MaxLeiter »

KaoruAoiShiho wrote: post #26
Sir_Cmpwn wrote: post #18

>Chat based community There's nothing wrong with using chat for collaboration and support. However, using a proprietary platform like Discord for this purpose a braindead move. It's astonishingly dumb to do this. Listen, IRC is not sexy. But it works, and has been chugging along for decades now - in the same time that a few dozen proprietary chat platforms have come and gone. It's supported by dozens of open source c…

UI clients unfortunately suck in comparison. That's really the problem with these no-owner platforms. Nobody has the financial incentive to make the big monetary investment needed to get the last 10% user experience stuff fixed.

Work is being done in this front with ircv3 and modern clients, though

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

#375

Post by drunknhik »

dmitriid wrote: post #371
drunknhik wrote: post #369

Earlier quoted context omitted.

Have you ever made a graphql server with apollo-tools? Do you complain that SDL is a "new syntax" that you have to learn when you can just use regular javascript? > > 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. Great, so it's not javascript. To a lot of folks it loo…

> Have you ever made a graphql server with apollo-tools? Have I ever mentioned apollo or graphql tools? Let me check: no > There's a lot less noise, and it's _much_ friendlier for (most) designers. I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX. And of course, it's not better than JSX for very obvious reason that you chose to ignore: how { }…

My only point in mentioning apollo-tools is that DSLs are very powerful, and have the potential to make complex problems much simpler. SDL is a great example of is, as are vue templates. You may not appreciate the DSL, but, believe me, there are a lot of people who much prefer it. I'm specifically calling out designer type folks here.

> I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX.

It's not a question of "better" or "worse". It's a question of tradeoffs on spectrum of abstraction.

I'm not here to bash JSX or react. But you apparently are, and I'm just trying to open your eyes a bit.

When vue came out with JSX, I tried to force it on my team, and there are a serious backlash, to the point where I came to realization that the vue's major strength is actually the templates, and the magic.

You may not like the magic, but a lot of folks do.

As for your specific questions

@ and : are just short hands. That's like saying: what's the difference between `map` vs `reduce` in my component to iterate over an array. They _can_ do the same thing, but map is shorter. In plain JS I can do `i = i + i` `i += i` or `i++` to increment an variable.

@ just means "event handler". @click = "onClick" : just means "use a dynamic value for this prop { } you can put any JS expression, with the plus that you don't have to litter your code with `this`.

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

#376

Post by dmitriid »

drunknhik wrote: post #375
dmitriid wrote: post #371

Earlier quoted context omitted.

> Have you ever made a graphql server with apollo-tools? Have I ever mentioned apollo or graphql tools? Let me check: no > There's a lot less noise, and it's _much_ friendlier for (most) designers. I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX. And of course, it's not better than JSX for very obvious reason that you chose to ignore: how { }…

My only point in mentioning apollo-tools is that DSLs are very powerful, and have the potential to make complex problems much simpler. SDL is a great example of is, as are vue templates. You may not appreciate the DSL, but, believe me, there are a lot of people who much prefer it. I'm specifically calling out designer type folks here. > I love how you could find exactly one thing out of a whole list of things that ma…

> My only point in mentioning apollo-tools is that DSLs are very powerful, and have the potential to make complex problems much simpler.

Yes. But just because it has that potential, doesn't mean that Vue's DSL(s) are not without the many problems anf gotchas I described. Just because Apollo's/GraphQL's DSL is potentially good, doesn't mean that Vue's is. etc.

> It's not a question of "better" or "worse". It's a question of tradeoffs on spectrum of abstraction. > I'm not here to bash JSX or react. But you apparently are, and I'm just trying to open your eyes a bit.

My eyes are wide open. Where in JSX I see a uniform approach that works in all JSX contexts, in Vue I see several DSLs bound together by magic of the library.

> @ and : are just short hands. That's like saying: what's the difference between `map` vs `reduce`

Shorthands mean:

- new syntax. For all intents and purposes it's a new syntax (call it a DSL syntax). And you have to know the difference and gotchas of that syntax. You have to know where you can:

-- provide a thing that looks like a function ref

-- provide a thing that looks like a function call

-- provide a thing that looks like a bound variable

-- provide a thing that looks like a Javascript expression

etc. etc. etc.

And that is further compounded by the fact that `v-` attributes sometimes take single Javascript-like expressions, sometimes not (v-for), some have additional "arguments". some have additional modifiers etc. etc.

And of course, some of it is Javascript expressions inside strings (`v-` attributes), some of it is Javascript-like (but not really Javascript) DSL inside mustache's curly braces (inside tags).

So here's the original statement that started this thread: "The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX"

This is demonstrably provably patently not so, as this thread has demonstrated.

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

#377

Post by dmitriid »

drunknhik wrote: post #375
dmitriid wrote: post #371

Earlier quoted context omitted.

> Have you ever made a graphql server with apollo-tools? Have I ever mentioned apollo or graphql tools? Let me check: no > There's a lot less noise, and it's _much_ friendlier for (most) designers. I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX. And of course, it's not better than JSX for very obvious reason that you chose to ignore: how { }…

My only point in mentioning apollo-tools is that DSLs are very powerful, and have the potential to make complex problems much simpler. SDL is a great example of is, as are vue templates. You may not appreciate the DSL, but, believe me, there are a lot of people who much prefer it. I'm specifically calling out designer type folks here. > I love how you could find exactly one thing out of a whole list of things that ma…

Additionally:

> with the plus that you don't have to litter your code with `this`.

"Littering code with this" is exactly how plain old vanilla JS works. Besides, "littering your code with this" very much depends on where your callbacks and variables come from... as in any old plain vanilla Javascript code. Because JSX is a paper-thin DSL on top of vanilla JS. Brilliantly and succintly described in this comment: https://news.ycombinator.com/item?id=17474370

In Vue you don't litter your code with this. You litter your code with hoisted variables and functions that are arbitarily hoisted into scope and injected everywhere. See my comment here: https://news.ycombinator.com/item?id=17471199 starting at "Of course. See inline comments."

The amount of gotchas and special syntaxes, and special cases, and the amount of moving part you have to understand to see where things come from and go to in Vue is insurmountably larger than in JSX.

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

#378

Post by erikpukinskis »

boubiyeah wrote: post #312
erikpukinskis wrote: post #210

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…

You wrote "React take the strongest stance" but you meant redux right?

No, React has a notion of a single giant state object, right?

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

#379

Post by Operyl »

MaxLeiter wrote: post #374
KaoruAoiShiho wrote: post #26

Earlier quoted context omitted.

UI clients unfortunately suck in comparison. That's really the problem with these no-owner platforms. Nobody has the financial incentive to make the big monetary investment needed to get the last 10% user experience stuff fixed.

Work is being done in this front with ircv3 and modern clients, though

We’ve been hearing this for the past ten years now it feels like. IRCv3 seems to have fallen short on most of its promises.

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

#380

Post by crimsonalucard »

vanderZwan wrote: post #211
crimsonalucard wrote: post #160

My problem with current gen frameworks is composition and modularity with components. Making components stateless and having all data come in as props from parents is good for modularity but how do you pass data back to the parent? This is where the modularity becomes awkward. I know of two ways in vue to do this and both ways either completely break or make modularity awkward. The first way is to signal the parent w…

> The second way is to use vuex as a global. This breaks modularity by immediately tying the component to a global. Vuex makes things easy but breaks modularity completely as soon as a component refrences vuex. Can you explain a bit what you mean here? I haven't used vuex yet, but to use my Redux/React experience as stand-in: the channel to emit data changes through is passed as a prop as well, so the component is st…

>Can you explain a bit what you mean here?

Any time you have something reference a global it becomes tied to that global whether it's a function, component or something else. If I want to take that component and move it to another project then I have to take that global and move it along with the component. That is a form of broken modularity.

Passing a closure or global channel from parent to child is not modular. It ties the parent to the child.

Observe function composition, lets say I want to build a function that adds 3 to a number and then adds 2 to a number. I have a base function called f defined as:

f(n) = n + 1

now I create two functions through composition:

g(n) = f . f . f

h(n) = f . f

by composing f 3 times then 2 times I have thus created the equivalent:

g(n) = f(f(f(n))) = n + 3

h(n) = f(f(n)) = n + 2

the final function d(n):

d(n) = g . h = g(h(n)) = n + 3 + 2

Every aspect of my created function is modular and I have maximized code reuse. Vue or React components do not have this property. If I build a UI from vue components, the majority of those components can never be reused while on the other hand my d(n) function is the reuse of a single function composed 5 times. The main reason is because data from the child must be sent back to the parent this either makes the child tied to the parent or the parent tied to the child.

The property of composition is achievable with a single source of truth cascading data down to stateless components that only display the data. Modularity breaks on the feedback loop. Is there a category we can invent that will fit the UI mold?

Post reply on HN