Live data from Hacker News

How we do Vue: one year later (2017)

about.gitlab.com

101–110 of 159 posts

Re: How we do Vue: one year later (2017)

#101

Earlier quoted context omitted.

I'm too inexperienced to have a definitive opinion, but I'm not nearly so positive and wanted to toss out a contrasting opinion to the current comments. After a few years of using React and some past experience with various other templating/view systems (webdev of one sort or another since '99) I started picking up a little Vue. So far it's been easy enough, but it is highly confusing compared to most other systems I…

> In one place a string is a string, in another it's a reference to a component property. It's not wrong, but this way it sounds way more scary than: "Properties which start with "v-" are treated specially by Vue and don't end up in the rendered output."

It doesn’t sound scary. It sounds correct and on the point.

Vue’s v-* attributes are a stringy mess [1], and it doesn’t really matter that they don’t end up in the output.

[1] https://news.ycombinator.com/item?id=19199423

Re: How we do Vue: one year later (2017)

#102

Earlier quoted context omitted.

I'm too inexperienced to have a definitive opinion, but I'm not nearly so positive and wanted to toss out a contrasting opinion to the current comments. After a few years of using React and some past experience with various other templating/view systems (webdev of one sort or another since '99) I started picking up a little Vue. So far it's been easy enough, but it is highly confusing compared to most other systems I…

I have the opposite feeling to you. The template feels like HTML to me and the syntax is clear and concise. React for me gets confusing with it all muddled together. But each to their own.

Compared to React (and React’s JSX) Vue’s syntax is orders of magnitude more complex and is very inconsistent: https://news.ycombinator.com/item?id=19199423

Re: How we do Vue: one year later (2017)

#104

Earlier quoted context omitted.

And why would that not be correct, and what are the sources of your number?

Most probably because Vue is enormously popular in China and npm mirrors are mostly used in china.

Vue can also be used from a CDN and doesn't require NPM.

Re: How we do Vue: one year later (2017)

#105
post #10
post #4

> Just use VueX That's the problem with large-scale Vue apps. Vue is awesome until you need to use VueX, after which it just becomes an inferior version of React + Redux.

Inferior? How exactly? I found Redux to be highly over-engineered in contrast to Vuex which is a lot like MobX - easy to use, yet powerful.

Agreed. Give me MobX over Redux any day of the week.

Re: How we do Vue: one year later (2017)

#106
post #68
post #30

Earlier quoted context omitted.

Vue's templating engine, honestly, seems somewhat poorly thought-out. The usual way of writing it errs on the side of HTML over JS, using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets. It makes it harder to visually parse, and it's sometimes annoying to not be able to use one type of quote marks unescaped within the statement. Overall, this is one of many ways in which Vu…

My least favorite part of Vue. Proper intelisense/checking for the templates never materialized either. A start-and-stop effort or two languishing in the Github issues.. I have a feeling after Vue 3 hits and in a couple years JSX will be the defacto way to work with Vue.

Putting three bits of code/markup written in different languages in the same file was always a bad idea.

Re: How we do Vue: one year later (2017)

#107
post #52
post #36

Earlier quoted context omitted.

I have to agree with this. Ultimately whether or not you like Vue or React better boils down to if you agree with the semantics of the web, and including them in your app building process (i.e you like html, and css, and just want to "pepper" in some logic and interactivity with JavaScript), or if you would rather just embrace JavaScript whole-heartedly. Vue relies too much on overloading the string type for my taste…

As far as component libraries that start from HTML, I think Marko has the best syntax. Attributes are always parsed as JS expressions, for example. There's still some quirks, but overall it's pretty nice. https://markojs.com/docs/syntax/ There are some benefits from just embracing JavaScript though, especially, as you mention, integration with things like TypeScript.

That attribute syntax is awesome! I've found VueJS's handling of attributes to be somewhat confusing, sometimes getting a different type passed through than I was expecting. Marko takes the approach that would least confuse.

Re: How we do Vue: one year later (2017)

#108

The revolving door of front-end frameworks is somewhat irritating; spending a nontrivial amount of time in Angular (1), then React, and now Vue. I wonder what the next one will be

You say "revolving" as if users have been forced to move from one to the other, but all three are current and legitimate choices, no?

angular.js is not a viable choice anymore (no clear statements of how long it's going to be supported), causing huge migration costs for everyone involved.

Re: How we do Vue: one year later (2017)

#109
post #14

I write Vue every day, in a large application. Only small bits use VueX. Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid. I HIGHLY recommend it, and this is from someone doing web since 1997.

I'm too inexperienced to have a definitive opinion, but I'm not nearly so positive and wanted to toss out a contrasting opinion to the current comments. After a few years of using React and some past experience with various other templating/view systems (webdev of one sort or another since '99) I started picking up a little Vue. So far it's been easy enough, but it is highly confusing compared to most other systems I…

One thing I love about Vue is flexibility.

If you want to use pure javascript, you can create the render function directly and forget about templates. Most of vuetify components are pure javascript.

Also vue has support for JSX if you prefer that.

Re: How we do Vue: one year later (2017)

#110
I've been working with Vue for a few months now, after several years with React, angular, JSP, rails and django (and of course jquery).

I know a lot of people, especially in HN, are impressed by it but I found it very lacking. It makes things easy to write at first and with very little learning curve but trades that ease of use for stability, simplicity and maintainability.

The main problems, to me, are:

* too much global state - the Vue object is the new window,a global registry, you add custom elements,filters,directives,plugins and even just utility methods. You can of course opt not to use it, but since all the libraries use it and it's the canonical way, you'd be hard pressed to.

* lack of controlled components - unlike react there are no controlled components. For example if you are trying to make an input that doesn't accept certain characters, in vue you'll need to handle keypress events to make sure the value doesn't change, while in react you can simply not update the rendered value. This can be worked around of course, but the fact that vue doesn't have a clear definition of it permeates throughout the ecosystem.

* component definition syntax - the syntax for definition a component with it's data,props,methods,computed,hooks is a very inconvenient way of writing classes (which vue 3 is going to support natively finally)

* template syntax - after doing JSX, going back to template syntax is not the greatest experience. It doesn't work as well with IDEs, you have to spin circles to do things that can be a one liner in javascript and it prevents doing any form of reuse and structure unless it's by splitting it to more components (I.E. no way to use just functions or internal methods).

Of course vue prides itself for the fact that you can choose to do things a different way - use JSX instead of template Syntax, don't use the global vue registry, etc...

But that's really in theory, it's like React can be used without JSX, it's technically true, but it's extremely hard not to and the ecosystem won't work well.

As to VueX, for me it takes the verbosity, single global object and dependence on strings for differentiation from redux and leaves out the immutability and reducer syntax. It takes the publish/subscribe technique from ReactiveX or mobX but leaves out the ability to combine, manipulate, stream and the general reusability that those frameworks provide. It is almost a comical selection of the worst features of both without any of the benefits.

Post reply on HN