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

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

#221

Post by bryanrasmussen » Fri, Jul 06, 2018, 7:14 AM UTC

erikpukinskis wrote: post #210

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…

> 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. It took me many years to realize this. I think very few front end developers understand this. And more problematically: very few framework devs seem to understand it. Stated another way.... Your tree of UI widgets, and Your tree of data which feeds those widgets ... are two orthogona…

>Your tree of UI widgets, and

>Your tree of data which feeds those widgets

Not with a well-designed XML format and XSL-T! But hmm, nobody seems to use that anymore either.

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

#222

Post by hvidgaard » Fri, Jul 06, 2018, 7:20 AM UTC

Vinnl wrote: post #213

hvidgaard wrote: post #212

> Vue is really fast. Maybe not the fastest, but its performance is overkill for the vast majority of web projects. When was the last time you needed to render and update thousands of DOM elements per second? Rubs me the wrong way. Better performance is always a net gain, and a high performance website provides miles better UX than the same website with waiting all the time.

> Better performance is always a net gain, I think that's easily disputed: it's always a trade-off. A 0.001 ms improvement in performance is a net loss if makes code 10x less readable, because that means programmers are more likely to introduce bugs, which would be a net loss. For example, I one worked with someone who changed all i++'s in a codebase to ++i's, even though they were not in performance-critical codepat…

I was speaking in the context of two different frameworks, not code, but I suppose the clarification is nessesary.

> I one worked with someone who changed all i++'s in a codebase to ++i's

Did you use the previous value of i, or did you just intent to increment it? ++i communicate that I'm not interested in the old value, where as i++ does the opposite. I actually use it as such, because my intent to a future reader of the code is more clear.

That said, for complex types, and with "stupid" compilers ++i can absolutely be significantly faster.

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

#223

Post by breakingcups » Fri, Jul 06, 2018, 7:25 AM UTC

sharpercoder wrote: post #22

dsco wrote: post #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 th…

I would highly recommend against this setup. While Vue is already very challenging to get right with any build tool, it's especially terrible regarding typescript and much more so with typescript decorators. You need to enable hardly documented configuration switches in multiple dependencies. Then, you must wrestle through a plethora of error messages coming from a diverse set of build tools/libraries/scripts. After…

Just to provide a different point of view. We're using Vue + Typescript + ASP.NET Core in about 4 mid-sized projects now and it's working really well. The only thing which was excruciating to get set up right was Webpack, but that's not Vue's fault nor Typescripts.

Granted, the reason it works well for us is because we started out right by looking at existing templates using Vue + Typescript which probably saved us a lot of hassle. The wrestling with configuration switches was by and large already done for us, but having used this combination extensively now I can say I'm familiar with all configuration matters in our projects and I find none of them particularly poorly documented or obscure.

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

#224

Post by breakingcups » Fri, Jul 06, 2018, 7:26 AM UTC

rajangdavis wrote: post #177

I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities. For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues wh…

With Nuxt, use the component: https://nuxtjs.org/api/components-no-ssr/

All my similar issues went away after discovering that.

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

#225

Post by aylmao » Fri, Jul 06, 2018, 7:31 AM UTC

_bxg1 wrote: post #106

aylmao wrote: post #95

Earlier quoted context omitted.

> most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled I think this is what the Flux model is all about, making UI code actually be a pure function of state. By that, I mean literally a function, where state is the argument, and where all you render depends solely on said argument. If you want to change what is rendered, you send a message and a St…

Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store). Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, an…

> Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function).

Wait, they don't though. That's the whole point of functional components. They are of the form:

    const Component = (props) =>

Where are said "literally passed" actions here?

> So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store).

This isn't bi-directional binding. state determining UI, UI sending queued actions and actions determining state is one-way data flow. Bi-directional coupling would be tying a reference in the state to a UI element.

> Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed?" and "what's the current string value of this input (which isn't meaningful until the form is submitted)?"

This is architectural, and is why components have their own state. Its up to you wether you want to keep this as application state or local volatile state.

> In Flux, those things tend to add a ton of boilerplate in terms of change actions, and split tightly-related concerns into separate corners of the codebase (if I remove this menu component I have to remove its open/closed state variable and the corresponding action).

Which is why I don't put it in the main application state (:

> To be sure, there's not really a great way to decouple things in the reactive architecture.

I mean, not if you're dumping everything on your application state, no.

> I personally lean towards stateful components that are decoupled at their boundaries instead, which does carry its own downsides.

Curious to learn what you mean by "decoupled at their boundaries". You mean components that are de-coupled from each other? You can make re-usable, functional or stateful components that are de-coupled from application state.

I think the main takeaway here is that not all state is the same, there's state that's part of your core application logic and state the component needs for its display only. Treating them as the same thing does limit the re-usability of your code and make dealing with your application state tedious.

> The only solution I've ever seen that truly felt right was two-way databinding, which Vue (sort of) still has...

There's other solutions (: I don't think Netflix, Facebook or AirBnB have all the state of their menus tied up with the state of their user data and and have all components be use-once because of that. Good state management can make things scale, and functional components very useful!

> but which has fallen out of fashion in general because it requires "magic" and because it tends to come with performance costs.

Yup. It's also hard to know where or how certain state is changing. It definitely allows you to build small applications very quickly, but it doesn't scale all that well.

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

#226

Post by aylmao » Fri, Jul 06, 2018, 7:36 AM UTC

_bxg1 wrote: post #191

danwilsonthomas wrote: post #149

Earlier quoted context omitted.

I've seen this idea a lot from members of my team that when you use a state management library then absolutely everything has to go through that state management library. This results in some of that pain you describe with state that's specific to the UI. If you're still working with React, try keeping that menu or input state in the component with setState instead of putting it in the global state store. I've found…

That seems like a good approach. Still, it doesn't seem like the rendering code or the Store code could ever really be worked with in isolation. As I said above, picking a coupling boundary is like picking a poison. They all seem to suck for different reasons; I just personally tend to choose component boundaries.

I'd recommend starting with the application as an abstract entity: start with the state and not think about the UI. Once you build a data-model and action scheme from there, working a de-coupled UI is usually simpler.

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

#227

Post by Moter8 » Fri, Jul 06, 2018, 7:43 AM UTC

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…

AFAIK, with vue-cli 3.0 (that now includes a browser GUI) you can just add plugins to your existing project, and a router plugin should exist.

Previously on vue-cli 2.x, it was just a question on the project initialization step.

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

#228

Post by pcstl » Fri, Jul 06, 2018, 7:47 AM UTC

Vinnl wrote: post #214

pcstl wrote: post #204

Earlier quoted context omitted.

People mainly use Redux because they don't understand that React isn't Angular. React is meant to care only about UI state. Your application state should be kept separately, and React should just be a function from app state to UI. Redux is what you get when people try to use React as a "full-app" framework instead of what it's meant to be: a view layer.

> Your application state should be kept separately, Is Redux not exactly that?

It can be used for that, but it quickly becomes cumbersome. Redux, in my opinion, should be used for complex UI state in applications with complex interfaces where interactions with one part of the UI can change very different parts ("spooky action at a distance", so to say). But it shouldn't be used to keep all your application's state.

Your application's state should live outside of React, and be passed in as the root's props.

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

#229

Post by pcstl » Fri, Jul 06, 2018, 7:48 AM UTC

WA wrote: post #205

pcstl wrote: post #204

Earlier quoted context omitted.

People mainly use Redux because they don't understand that React isn't Angular. React is meant to care only about UI state. Your application state should be kept separately, and React should just be a function from app state to UI. Redux is what you get when people try to use React as a "full-app" framework instead of what it's meant to be: a view layer.

So how do you manage your application state? I‘m curious, because a search for such a phrase always brings up Redux, Thunks and Saga.

You keep it out of React, manage it however you want to and is most convenient for your application's data model, and pass in the parts that are relevant to UI as props to React's root.

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

#230

Post by mos_basik » Fri, Jul 06, 2018, 7:54 AM UTC

laichzeit0 wrote: post #218

davidmurdoch wrote: post #166

Earlier quoted context omitted.

I hadn't heard of laracast until starting Vue development a few weeks ago. The quality of answers were so low I found myself longing for the days of expertsexchange.com. Why did laracast get so popular for Vue? What was wrong with Stack Overflow?

What does gender reassignment have to do with Vue?

It's hard to identify sarcasm in text, so either I'm walking into your joke or you're walking into his (much older) joke. Oh well.

Experts Exchange was a tech QA site with a comically misinterpretable domain name that was popular in the late nineties and suffered in the dotcom bust.