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

61–70 of 382 posts

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

#61

Post by tarellel »

fiatjaf wrote: post #6

It is good just for the simple stuff, the world of webapp examples, todo lists and so on. For all that, Elm is much better. For all things more complicated and that require intelligence to think about good architecture and how to structure state, the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations. Also, the community on Discord is not friendl…

Care to explain how complicated apps are a no go? I've used Vue for about a year and half now. Some of my apps have been very simple some of them have been extremely complex. I can say I've had very few issues along the way. VueJS is absolutely amazing. You just need to throw-in some mixins, Vuex, Vue-Router, and whatever else you may need and you should be golden!

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

#62

Post by ElatedOwl »

ilovecaching wrote: post #52
ElatedOwl wrote: post #28

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

I'm curious to know, what about Vue makes it easier to learn than React? It's just a function that takes in data and returns a piece of html. React also just works, and unlike Vue, it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering. What did you really buy with Vue over React?

Netflix, Walmart, etc. solve a much different set of problems than most shops. I'm proud to work for a small company with simple (but rapidly changing) requirements. :)

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

#63

Post by duxup »

condescendence wrote: post #7

>You’ll be adding similar boilerplate for computed properties, component state, watchers, etc. Pretty much everything in Vue has its own special syntax with more boilerplate. I kinda like this syntax, when I first learned vuejs I knew immediately that some magic was going on in the background. If I saw marko's syntax I'd be wondering how this shit is getting done. It also makes it easier when searching for issues or…

What are some of those good communities? Seriously asking, no sarcasm.

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

#64

Post by kevin_thibedeau »

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 am never a fan of two way data binding as an alternative.

The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.

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

#67

Post by drb91 »

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…

State management seems like inherently a different problem to solve than the problem React solves. What front-end framework out there has a single state management pattern that works for all sizes?

It’s easy to point out frustrating things or hard problems; it’s not easy to point to a way out.

Personally I love the explicit state flow react forces, and I would hate to move to a framework where I spend time figuring out how data goes from point A to point B.

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

#68

Post by RussianCow »

jazoom wrote: post #55
carusooneliner wrote: post #38

Earlier quoted context omitted.

Our site does't work with js disabled. Serious question: is it common for folks to disable js? vue is used only for the web app. No js frameworks used in the chrome app.

It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no…

Without hard data, this is pretty meaningless. If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint.

> I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see.

Maybe existing users (and even for that, I'm skeptical), but how many potential users did you lose because they couldn't even open your app?

I'm not saying you are wrong, just that "users didn't complain" != "users weren't affected".

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

#69

Post by andrewstuart »

I don't get the thing about ReactJS boilerplate where he says "Moving from React to Vue seems like a breath of fresh air. No more bind(this) or setState() everywhere. Yay! "

Surely there's better ways of doing ReactJS rather than lots of setState? Of course I use setState but try to avoid it generally.

And I almost never, ever use bind() - don't es2015 fat arrows make it obsolete?

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

#70

Post by shakna »

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…

Version with debug enabled:
Production version:
If you need something more complex, vue-cli has webpack inbuilt:

    vue init webpack my-project
    cd my-project
    npm install
    npm run dev
Or if you need webpack, but not the complexity, swap the word 'webpack' in the above command to 'webpack-simple'.

... Vue has already done the hard work of getting the build apps configured for you.

Post reply on HN