Vue.js: the good, the meh, and the ugly • Hacker News Board

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

#21

Post by noir_lord » Thu, Jul 05, 2018, 9:07 PM UTC

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…

I just put those Api calls in a module in the same dir as the component usually.

Then api.fetchFoo(bar).then() mostly does it.

Benefit is separation of API from component.

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

#22

Post by sharpercoder » Thu, Jul 05, 2018, 9:08 PM UTC

dsco wrote: post #15

A lot of the boiler plate can actually be removed if you combine Vue with TypeScript decorators. Here's a library which will do that for you: https://github.com/vuejs/vue-class-component Although at this point in time it is pretty cumbersome to get the entire Vue stack type safe. I think it's getting better but it's far from ideal. You'll need a wide range of libraries to get everything set up. For instance here's th…

I would highly recommend against this setup. While Vue is already very challenging to get right with any build tool, it's especially terrible regarding typescript and much more so with typescript decorators. You need to enable hardly documented configuration switches in multiple dependencies. Then, you must wrestle through a plethora of error messages coming from a diverse set of build tools/libraries/scripts. After you've done that, the only options is praying to the gods a config will work.

I have worked with multiple Vue projects now. The time is spent about 50/50 in pure development and getting the build setup working correctly.

Better pick another tool to do the job which has mature integration with build tools.

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

#23

Post by 33degrees » Thu, Jul 05, 2018, 9:08 PM UTC

buremba wrote: post #9

ilovecaching wrote: post #2

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…

I wonder how you avoid writing stateful components in real-world complex SPAs.

You manage your state outside your components, using Redux / Relay / MobX etc...

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

#24

Post by mlevental » Thu, Jul 05, 2018, 9:12 PM UTC

sharpercoder wrote: post #16

One particular weak point of Vue is it's dependency on build tools. I spend a few days buiding a great app, and then another few days on getting the build apps configured right with Vue. You google from one error message to another, where each message is unclear and no relation to any build tool/plugin/library/script is made. I really like Vue for the many great strong points it offers. But I'm equally ready to compl…

literally in their docs they have you into a plain HTML file to get started. and it's not like react doesn't the same issue - hell CRA had to be built.

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

#25

Post by smackay » Thu, Jul 05, 2018, 9:13 PM UTC

stupidcar wrote: post #17

ilovecaching wrote: post #2

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…

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 back to the previous view with the parent data is almost zero-cost.

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

#26

Post by KaoruAoiShiho » Thu, Jul 05, 2018, 9:13 PM UTC

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.

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

#27

Post by KaoruAoiShiho » Thu, Jul 05, 2018, 9:17 PM UTC

Pushing so much support to chat is an astonishingly big mistake. Not only are platforms like stackoverflow vastly better at answering questions and providing long-term documentation, it also builds broader communities. People use things like "number of stackoverflow questions tagged vue" to determine health and activity. You don't want to miss out on those metrics that other libraries are rolling with.

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

#28

Post by ElatedOwl » Thu, Jul 05, 2018, 9:18 PM UTC

We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works.

TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen.

There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design varies pretty wildly. I think this is just the reality of a young framework casting a wide net, we'll see what the future brings.

It's not perfect, but like the author, Vue was a great decision for my team.

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

#29

Post by frou_dh » Thu, Jul 05, 2018, 9:24 PM UTC

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…

It's getting bad. There are a couple of communities that I have resigned myself to not being able to make ties in, because I have absolutely zero interest in doing anything "on the Slack", as is so often casually mentioned.

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

#30

Post by buremba » Thu, Jul 05, 2018, 9:24 PM UTC

ilovecaching wrote: post #14

buremba wrote: post #9

Earlier quoted context omitted.

I wonder how you avoid writing stateful components in real-world complex SPAs.

It's quite easy, I honestly think the only roadblock is how one thinks about computation. If you think of your UI as a single computational expression you're building up from functional composition, then the issue of state never arises. It's just about defining the shape of the interfaces.

Sounds cool but I can't actually imagine the way you described. :) Any tutorials, articles?