Live data from Hacker News

How we do Vue: one year later (2017)

about.gitlab.com

71–80 of 159 posts

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

#71
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…

>>Irrespective of that, these days I am hard pressed to not use typed JS in some form or fashion anyways. What do you mean by "anyways"? I use TypeScript with Vue and it's great.

I could see it being great if everyone on the project were writing class components and using JSX. String templates and extended objects?

Mutiny.

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

#72

Earlier quoted context omitted.

#1 reason for me? The community. Hands down the community. Vue has such a better community than react or angular by a Long shot. If you ever end up needing help and jump into the discord channel. No matter how annoying you are the entire community is always patient polite and helpful. I can’t say my experience has been close to the same in react or angular.

Have you been on the React discord channel? Acemarke is like 20 people masquerading as a single person. I've never had a bad experience with the React community. Case in point, any whiff of dissatisfaction and Dan Abramov will comment on your post. Literally can't get any better service than that.

Thanks. I had no idea react had discord, I believe I used gitter? at the time. I may have just had a bad apple but it just left a bad taste in my mouth, something I haven't experienced with Vue.

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

#73
post #30
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.

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…

> using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets

Sounds like you should be making more use of computed properties and component methods.

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

#74
I have used both React and Vue in large, long lived apps. I personally found both to be excellent - React has better TS support as of now. When Vue 3 hits with its internal TS api and you can use TSX as a first class citizen, I’d say you could go with either and have a comparable experience. At the moment the lack of static type checking due to Vue’s .vue file is the main disadvantage, IMO.

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

#75

Earlier quoted context omitted.

>I HIGHLY recommend it, and this is from someone doing web since 1997. I started in 97 as well, and cannot recommend Vue enough. I've done React, Angular 1 & 2, and I keep coming back to Vue. I always feel like with React/Angular I'm conforming to work how they want me to work. (Esp. Angular - React is more forgiving). Whereas Vue is just a complement to the way I already work. I can use as much or as little of it as…

So for personal projects or for small apps I think that’s great. But when I think about projects that need to live on well after I’m around, then they shouldn’t work the way I work, they should be in standard way that anyone can come into and know what’s going on. That jumping applications between teams feels simple. This is why I like angular quite a bit, it’s not whatever the dev decided to do. It doesn’t include a…

I think OP does not mean that Vue is unstructured / non-disciplined. Vue does have a rigid structure and standard though, but it's pleasantly designed and doesn't get in your way. Maintenance has been a breeze for me.

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

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

I've always found Redux to be an overcomplicated mess, whereas Vuex is quite simple and has a nice, logical flow. For those who think it's still too complex, I've heard that Pathify https://davestewart.github.io/vuex-pathify is a great solution.

I regret every line of Redux boilerplate I ever wrote before discovering MobX. MobX is now even more fantastic with the new proxy based implementation.

Reading up on VueX.. Not really looking forward to having to use it over MobX.

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

#77
post #10

Earlier quoted context omitted.

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.

> highly over-engineered Redux is a couple hundred lines of code. A good way to learn the pattern it to reimplement it yourself - which you could probably do in ~100LOC if you ignore the helper functions

I believe the OP meant in the sense of say, implementing a client for a network service in python using recursion with multiple re-entry points instead of a for loop..

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

#78

I used riot.js for a few years and was quite happy with it. Sadly it had a few misconceptions (e.g. the parent.parent.parent... problem) which could have been changed easily. But as the lead dev wasn't very cooperative I switched to the closest alternative: Vue. I don't have enough experience with Vue yet to judge it, but given how similar Vue and riot.js are I hope that it gives me the same productivity without thos…

I also came to vue from riot, and now find myself much more productive with vue. stick with it. and check out nuxt for out of the box server-side rendering, another thing that was a bit tricky with riot.

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

#79
post #2

When you have to hassle the backend guys because querying <<100 comments is slow, is that the point where you stop and ask "what are we doing here".

I thought the same thing.

> Surely you could query the DOM for this. A better solution, in this case, is to let the backend developers mark the last user comment in the JSON they return. Backend developers have direct access to the database, which means they may be able to optimize the code. Then no client-side work has to be done at all, in this case.

Look, I know what I am, I'm no fancy-pants silicon valley guru here. But what is described in this example is primarily a client-side function. So I think the wording for this is "a different solution" at minimum. Better? Meh. Will that new backend query ever serve any purpose other than facilitating this frontend feature?

Perhaps instead of adhering to a "let's not query the DOM" at all costs, ask yourself what exactly you are complicating and for what gain.

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

#80

Earlier quoted context omitted.

>I HIGHLY recommend it, and this is from someone doing web since 1997. I started in 97 as well, and cannot recommend Vue enough. I've done React, Angular 1 & 2, and I keep coming back to Vue. I always feel like with React/Angular I'm conforming to work how they want me to work. (Esp. Angular - React is more forgiving). Whereas Vue is just a complement to the way I already work. I can use as much or as little of it as…

So for personal projects or for small apps I think that’s great. But when I think about projects that need to live on well after I’m around, then they shouldn’t work the way I work, they should be in standard way that anyone can come into and know what’s going on. That jumping applications between teams feels simple. This is why I like angular quite a bit, it’s not whatever the dev decided to do. It doesn’t include a…

I think you might be reading into what the poster wrote the wrong way. the implications of a framework being able to be used the way the poster descibes is that it closely follows existing standards and best practices. So as opposed to forcing you to do things entirely differently, it helps you work the way you might already work. Quite different from an anything goes wild wild west. And as with any language or framework, whether or not it's hard to debug is up to the developer.
Post reply on HN