Live data from Hacker News

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

medium.com

11–20 of 382 posts

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

#11
I can vouch for the author's points on the good parts of vue.js.

We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- https://checkoutclip.com. We were able overcome most of the stumbling blocks by looking up https://vuejs.org/v2/guide/, https://github.com/vuejs/vue/issues and https://forum.vuejs.org.

For server side rendered (SSR) pages, we're using nuxt.js, which is working out great as well. E.g. SSR page: https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K

I would recommend vue.js for anyone building their first SPA even if they don't have prior experience building one...it's easy to pick up.

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

#13
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/

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

#14
post #9

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.

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.

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

#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 the list of libraries I use for bootstrapping projects:

Vue-class-component - Vue-loader - Vue-property-decorator - Vue-template-compiler - Vuex - Vuex-class - Vue-router - Vuex-router-sync.

The ecosystem just keeps getting larger and larger and for a beginner it can seem pretty daunting. I don't complain though - UI's have become a lot more technical and complex the last 10 years - and of course that'll increase the learning curve of learning how to program them.

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

#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 completely ditch Vue for its complete and utter garbage with respect to build/debug configuration.

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

#17

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 complex web app, a component nested twenty levels deep may need to display pieces of information, like the user's date of birth and the current temperature on Mars, that none of its parent controls cares about.

At that point, you can either bite the bullet and pass state through layer upon layer of props, completely eliminating any semblance of separation of concerns in your component layering, or inject state into your components via some other mechanism, like Redux/MobX/Context. At which point, JSX is basically just another fancy HTML templating library.

"Idiomatic" React is a fun game to play when doing basic examples, using something like a todo manager, but as soon as you're in the real world, you hit its limitations very quickly.

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

#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 clients and servers, has integrations with all sorts of bots and git and ticket trackers and such, there are dozens of libraries for working with it, and networks dedicated to open source projects. It's a no brainer.

The particular issue called out in this article is trivially solved on IRC. There are a half dozen ready-to-roll public IRC log softwares, and most of your users have clients which are automatically keeping logs that can be restored from if there's ever a service outage on your logger. Hell, if you send me an email I will put my IRC client in your channel and publish public logs for you for free.

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

#19

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…

Do you have any suggested resources for learning React in this way?

My recommendation is to read through this: https://github.com/reactjs/react-basic
Post reply on HN