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

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

#71

Post by RussianCow » Thu, Jul 05, 2018, 10:14 PM UTC

ElatedOwl wrote: post #62

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?

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. :)

That doesn't really answer the question. :) How does Vue let you deal with "simple (but rapidly changing) requirements" better than React?

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

#72

Post by acemarke » Thu, Jul 05, 2018, 10:16 PM UTC

DougBTX wrote: post #35

stupidcar wrote: post #17

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

React was advertised from the start as the V in MV-whatever, so that seems like an overly restrictive definition of "idiomatic". > At which point, JSX is basically just another fancy HTML templating library. JSX is optional syntax sugar; my team uses React and Redux heavily, but we've opted not to use it. HTML templating is great actually, all the rendering is data -> UI. If you go back to the early Rethinking Best P…

Out of curiosity, what are you using instead of JSX? Plain `React.createElement()` calls, `createElement` aliased to a shorter variable like `e`, or something like the `react-hyperscript-helpers` library?

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

#73

Post by ilovecaching » Thu, Jul 05, 2018, 10:16 PM UTC

ElatedOwl wrote: post #62

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?

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. :)

That doesn't answer my question. What about Vue actually made it a better choice for those requirements? In my experience, the fact that React is a simple view library makes it the perfect choice for small shops. You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested, the API was completely broken in a rewrite). Smaller frameworks also suffer from a lack of sustained development.

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

#74

Post by k__ » Thu, Jul 05, 2018, 10:16 PM UTC

mmcnl wrote: post #66

The ugly in this article isn't really the ugly, it's the good. Nobody's holding you back from writing a simple ES6 module that handles API requests for you. Vue is a view layer, nothing more and nothing less.

People aready hated on this with React, why should they stop with Vue? :D

I guess Ember and Angular are more of one-stop-shops in that way.

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

#75

Post by mmcnl » Thu, Jul 05, 2018, 10:17 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 think the answer is that there is no right or wrong answer. Something that has worked well for me was to put my API calls in a seperate module and call this module whenever I need it (either in Vuex or a Vue component). Very simple.

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

#76

Post by linkmotif » Thu, Jul 05, 2018, 10:17 PM UTC

ElatedOwl wrote: post #62

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?

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. :)

Not really. It’s all the same set of problems.

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

#77

Post by jazoom » Thu, Jul 05, 2018, 10:18 PM UTC

RussianCow wrote: post #68

jazoom wrote: post #55

Earlier quoted context omitted.

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

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

And I wouldn't miss you.

I can make the service better faster if I don't support the lowest common denominator. I'm sure I'd lose more users if the website was bloated with fallback code and my development speed was such that features are a year behind where they are now.

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

#78

Post by acemarke » Thu, Jul 05, 2018, 10:18 PM UTC

andrewstuart wrote: post #69

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?

Sort of. The nicest-looking approach is to use the Stage 3 Class Properties syntax to write class methods using arrow functions, which auto-binds them to the component instance as it's created (the equivalent of calling `.bind()` in the constructor).

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

#79

Post by _bxg1 » Thu, Jul 05, 2018, 10:18 PM UTC

I've used React full-time at work for a year and a half now, and I did a personal project in Vue for a while to try it out, before converting it to React.

There are some things I really, really hate about React. It is not kind or accommodating (Vue is both of these things), but it gives you control. I was head-over-heels for the first few days of using Vue; "breath of fresh air" is exactly the phrase I'd use. But the project I was using it for was an IDE of sorts, and eventually I just needed more control than it allowed for.

If someone told me they were going to build a basic website - not a web app - with React instead of Vue, I would laugh at them. Vue truly is a successor to jQuery for the reactive age. But for really complex applications, it's too "magical" in my opinion.

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

#80

Post by k__ » Thu, Jul 05, 2018, 10:18 PM UTC

andrewstuart wrote: post #69

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?

Funny thing is, React uses that API because two-way-binding is considered bad practice.

But I guess old habits die hard...