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

111–120 of 382 posts

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

#111

Post by octref »

voltagex_ wrote: post #93
octref wrote: post #89

Have to do some clarification here on the point of "Unclear architectural patterns", as the article is way too misleading. - The reason the API call is made at `created` lifecycle is that the video is a quick, 5 minute intro for beginners . Beginners, as in "people who are familiar building static websites using html/css/js". There is no need to bring in Vuex or vue-router yet. In fact the whole beginner example can…

>Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work. Okay, say I do the tutorial and build a simple page - how hard is it to retrofit routing or whatever to it? A lot of the time with new frameworks, if I get past the initial setup hurd…

One thing I want to say is: Don't assume only developers make websites. Don't assume everyone wants to ship a heavy and complex SPA.

Example 1: A great typographer, Wenting Zhang, author of Type Detail[0], contributing to Source Han Serif, learning Vue to do some interactive widget for variable fonts[1].

Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to build an app to track TC39 discussions[2].

I hope we can admit that many people might not need store and router[3]. Store and Router are necessary for building complex SPA, but don't make them necessary, as many don't want complex SPA. They impose learning efforts in exchange of better architecture, but the imposed effort might not be worth it for many people who just want some data-rendering, some reactivity and some interactivity on their websites.

[0]: http://typedetail.com

[1]: https://twitter.com/DesignJokes/status/1015003288528400386 and https://twitter.com/DesignJokes/status/1014260361535647744

[2]: https://twitter.com/bterlson/status/913433979239436293 and https://github.com/bterlson/tcq

[3]: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

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

#112

Post by acemarke »

jgrpf wrote: post #107
ilovecaching wrote: post #52

Earlier quoted context omitted.

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?

Apart from anecdotal experience telling me that fresh JS devs have a much easier time with Vue than React, I love to still have the option to use it through a simple embed without a build system but can switch to a Webpack/any module bundler if the requirements demand it. The JS ecosystem really has a problem with bloat in my opinion and Vue trumps React in the regard (react eject anyone?).

It's worth noting that React has _always_ been something you could add to an application with just one or two script tags, and the docs were recently updated to emphasize that use case: https://reactjs.org/docs/add-react-to-a-website.html

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

#113

Post by allover »

atombender wrote: post #97
allover wrote: post #33

Earlier quoted context omitted.

> 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? Sadly it seems that's mainly been cargo-culted. It's not the case that React+Redux is the equivalent to say Angular, but by some unfortunate accident due to Facebook's announcement of Flux, and then the hype around Redux as a 'better Flux', people started assuming Re…

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise s…

But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community.

Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened?

Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.

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

#114

Post by RussianCow »

jazoom wrote: post #98
RussianCow wrote: post #94

Earlier quoted context omitted.

But dropping support for certain browsers/clients without having data on how many of your customers would be affected is silly, IMO. You might decide to drop support for IE 11 because you want to use CSS Grid without hassle, but then it turns out that 10% of your users use that browser! As with everything, you have to weigh the tradeoff, but you can't do that if you don't have the data to begin with.

> without having data on how many of your customers would be affected is silly You're making the assumption I don't have and use data like that? That's an incorrect assumption.

Sorry, you are correct, I made that assumption. It seemed implied by your use of user complaints as a metric of success—I assumed that was the case because you didn't have hard data, so I apologize if that's not the case.

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

#115

Post by keerthiko »

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?

Our company used React when starting a new project, but we still had an existing project with a vanilla HTML/CSS/js website, which really needed a rewrite. I had a talk with my cofounder about the strengths and value of React, but hadn't dived deep yet - I wasn't working actively in the codebase of the new project. I tried to, and all the moving parts were monstrous to wrap my head around - states, redux, actions, whatever, even though I thought I understood the fundamentals of the reactive paradigm.

My cofounder suggested I check out vue for the rewrite of our legacy project, and I was able to onramp SO easily. I can easily hand off components to other team members to write, and it rarely broke stuff in the rest of the project. On the whole, vue feels a bit less powerful but a LOT simpler to wrap your head around while subscribing to the reactive UI paradigm.

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

#116

Post by ppseafield »

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?

For one: vue, vuex (centralized state library) and vue-router are stewarted by roughly the same people, which has a few benefits. The documentation is all pretty decent and uniform. I never sit for very long wondering how to do something.

Changes that break backwards compatibility are reflected across all three at the same time, and the correct versions are installed by vue-cli. I had several starts with react, react-router, and redux, and on almost every occasion something from my last attempt was broken because the api had changed, and the documentation changed with it (in the span of 3-4 months). That lead to several WTF moments. IIRC there was a period where react-router made some breaking changes from v2 to v3, and then less than a year later made more breaking changes for v4.

Vue is also a lot simpler to drop into an existing application. The .vue single-file component is very approachable, albeit a bit magic but about as magic as JSX. You can add a vue-loader for sass/less/etc. and simply specify lang="less" in these as well.

Vuex was a little easier for me to grok, although I had the advantage of trying out redux first. It has the advantage again of sharing documentation with the rest of the project.

Also, because react has worked for big companies as you mentioned, does not mean vue couldn't work for them as well. React gained a lot of momentum early among western programmers. Vue first gained traction in Asia - Evan You, the creator of vue, is from there. Also you might remember the massive amount of confusion for early React adopters regarding how to manage state. People liked react, but it only really had the view part ready out of the gate. Facebook's explanation of what the early-best-practice flux model entailed was vague, and there were several slightly different implementations.

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

#117

Post by jazoom »

RussianCow wrote: post #114
jazoom wrote: post #98

Earlier quoted context omitted.

> without having data on how many of your customers would be affected is silly You're making the assumption I don't have and use data like that? That's an incorrect assumption.

Sorry, you are correct, I made that assumption. It seemed implied by your use of user complaints as a metric of success—I assumed that was the case because you didn't have hard data, so I apologize if that's not the case.

Not a problem at all. I place high value on being available to users of my website. I reply to each and every message. Perhaps it's a bit unusual for someone to talk about that before the numbers.

It has been my experience that I've gained more valuable insight from talking with users than I have from the numbers.

But, as a little Latina girl once said, why not both?

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

#118

Post by atombender »

allover wrote: post #113
atombender wrote: post #97

Earlier quoted context omitted.

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise s…

But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, project…

Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing.

I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.

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

#120

Post by terenceng2010 »

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…

One time I have to maintain my own version of a vue plugin because it uses es6 syntax and I am not able to use it in no build process vue setup. Afterwards i switch to use vue cli.
Post reply on HN