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

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

#51

Post by strken » Thu, Jul 05, 2018, 9:50 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…

React isn't about JSX and passing foo/onUpdateFoo down 20 levels of props. It's about data flowing in one direction down a tree of diffable virtual components, then being passed back up. The single most important idiom is that all data for a component should come from state or props, and that when you need to break this rule you should do it inside a single component or a handful of components that will then handle your global state management.

I understand that such an open-ended product is frustrating to use because redux is insanely overengineered, mobx reintroduces data binding, and context is buggy and terrible, but I don't think what you're calling "idiomatic React" is actually considered idiomatic by anyone, including the core development team.

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

#52

Post by ilovecaching » Thu, Jul 05, 2018, 9:50 PM UTC

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?

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

#53

Post by Tade0 » Thu, Jul 05, 2018, 9:51 PM UTC

>To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples.

Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex?

One more thing I think deserves mention: Vuetify - Vue's material design component set. It's being used in the project I'm currently in and I worked with Angular's material design component set and I have to say the former is way better built.

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

#54

Post by zmmmmm » Thu, Jul 05, 2018, 9:54 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…

Such a strange comment to read ... quite literally, the reason I first started using Vue over other frameworks was I wanted to put it into legacy apps and did not want to use a build tool. It's one script tag. Not in a half lying way like people say about React, for real. It falls down if you start throwing in components and libraries that presume webpack based setups (which is annoying), but Vue itself is completely and trivially usable with zero build step.

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

#55

Post by jazoom » Thu, Jul 05, 2018, 9:56 PM UTC

carusooneliner wrote: post #38

ppiuser wrote: post #31

Earlier quoted context omitted.

Have you looked at your site with javascript disabled? Additionally, was vue used just for the website or the chrome app as well?

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 complaints. This one is more "brave" but I use Modernizer and show a clear message outlining all the required features the user's browser doesn't support and why they would want that feature in a browser. There's a link to a website to help them find a modern browser on their platform.

Edit: I realised that based on what I said you could argue that users are annoyed but I'm just not aware. 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. The last time this had to do with browser support was one message 3 years ago about IE9 not supporting the TLS certificate or something. They were forced to use IE9 at work.

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

#56

Post by qudat » Thu, Jul 05, 2018, 9:58 PM UTC

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…

It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML.

At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`.

Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when React was first created in order to ease people into transitioning to HTML in JS, but I feel like we can move passed that now.

I highly recommend `react-hyperscript`: https://github.com/mlmorg/react-hyperscript

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

#57

Post by RussianCow » Thu, Jul 05, 2018, 10:01 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 most important thing is to be consistent, instead of having a mix of API logic that originates from components and from the store. And since there are certain types of higher-level logic that are very difficult to house inside components, I have found that having your store be the origin for _all_ API-related logic is the best way to go, even if it seems overkill for simple things. It's better to be globally consistent than to try to have the simplest solution for every individual case.

(Disclaimer: I use React/Redux and not Vue/Vuex, but I think the above applies equally to both.)

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

#58

Post by tambourine_man » Thu, Jul 05, 2018, 10:03 PM UTC

carusooneliner wrote: post #38

ppiuser wrote: post #31

Earlier quoted context omitted.

Have you looked at your site with javascript disabled? Additionally, was vue used just for the website or the chrome app as well?

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.

Graceful degradation:

https://en.wikipedia.org/wiki/Fault_tolerance

Progressive enhancement:

https://en.wikipedia.org/wiki/Progressive_enhancement

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

#59

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

carusooneliner wrote: post #38

ppiuser wrote: post #31

Earlier quoted context omitted.

Have you looked at your site with javascript disabled? Additionally, was vue used just for the website or the chrome app as well?

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.

> Our site does't work with js disabled.

Then please have a noscript tag.

> Serious question: is it common for folks to disable js?

That's not the only reason you'll find for JS being unavailable.

Windows Updates has managed to disable JS in various situations across both Edge and IE over the years due to tightening security policies.

Chrome has had V8 crashes over the years, as has Firefox.

The browser might be misbehaving, but rarely will the user attribute it to the right place - your site will get the blame.

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

#60

Post by pier25 » Thu, Jul 05, 2018, 10:06 PM UTC

Tade0 wrote: post #53

>To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples. Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex? One more thing I think deserves mention: Vuetify - Vue's material design component set. It's being used in the project I'm currently in…

> Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex?

(Author here. I didn't really expand on that because the article was getting pretty long already.)

For example, think about authentication logic.

It involves more than just calling the API. Eg: extracting the JWT, saving it to localStorage, decoding it, maybe checking user roles, etc.

If you do that kind of logic on Vuex actions then these will start being responsible for a lot of your application. If you are fine with that, by all means, use Vuex actions to do (a lot of) stuff not really related to managing state.

Personally I don't think it makes any sense to delegate that kind of logic to Vuex in the same way I won't use Axios for anything other than making HTTP requests.

There are also practical aspects. Vuex actions need to have a very particular signature, since you never really call them yourself. To me that was the final reason for moving a lot of logic to their own modules.

In my latest projects I've almost stopped using Vuex actions altogether and it feels really good. Authentication is not managed by some parts of Vuex, but by my own auth module.