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

311–320 of 382 posts

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

#311

Post by anderspitman »

tnolet wrote: post #292
ixtli wrote: post #291

One of the gems in this that i think might be getting overlooked: > This trend of using chats for questions is plaguing open source projects and I think it needs to end. There is no collective learning anymore. This is a very important notion not least of all from an archival pov.

Yes! Also things like Gitter and Slack are really messy for storing knowledge. Questions get lost, answers are interspersed with more questions. Maybe I'm getting old, but give me a forum based, one-thread per topic any time of the day.

I prefer forums as well, at least for technical questions/discussions. It seems to me the biggest advantage of chat apps over forums is that you can use a single account to join many rooms. Are there any forum platforms designed around that idea?

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

#312

Post by boubiyeah »

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…

You wrote "React take the strongest stance" but you meant redux right?

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

#313

Post by shados »

_bxg1 wrote: post #186
shados wrote: post #169

Earlier quoted context omitted.

> 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? The entire UI is specific to the UI. Trying to separate "entities" or "server data" from "UI concerns" is IMO a waste of time and just confusing. At the end of the day, you have a state tree, and you project it to a UI. Where…

That level of abstraction sounds nice, but isn't really practical. A dropdown menu and a modal have wildly different use cases and relationships with the rest of the app. The only way the former would directly translate to the latter is if the latter contains nothing but a set of radio buttons, in which case you should hire a new designer. In fact, the reason we have the particular toolbox of standard GUI elements th…

> That level of abstraction sounds nice, but isn't really practical

The only thing not practical about it is that in these days and age, the amount of people with data modeling experience is low. But it totally does work in practice and is, IMO, the only way to really be productive with Redux. Otherwise any change you make or any new feature requires modifying components, actions, AND reducers. At that point you're just doing 3 times the work for everything.

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

#314

Post by shados »

pcstl wrote: post #204
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…

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.

> People mainly use Redux because they don't understand that React isn't Angular

Ironically, Redux came out around the time Angular popped. While not everyone, a significant portion of early adopters came in because they were rejecting the Angular 1.X way of handling state, and Redux was the polar opposite.

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

#315

Post by shados »

heyoni wrote: post #275
aylmao wrote: post #41

Earlier quoted context omitted.

> as soon as you're in the real world, you hit its limitations very quickly. Isn't a good chunk of AirBnB, Facebook, Instagram, Netflix, The New York Times and Dropbox written in React? The built-in state management has limitations, of course. I see it best for keeping state relevant to display-- React is supposed to be a "view" library, not a state management one.

Is there a way to tell or are we going by what these companies disclose?

Use the react devtools when looking at those websites.

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

#316

Post by sne11ius »

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…

I haven't used nuxt, but this vuejs component "hides" the wrapped component during server render:

https://github.com/egoist/vue-no-ssr

Regarding the "client/server render results do not match" issues: Fixing these is mostly easy in my experience, especially since vue will log the offending dom nodes to the dev console.

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

#317

Post by shados »

exwizzard wrote: post #216
sheeshkebab wrote: post #190

Earlier quoted context omitted.

And that will probably be the end of vue...

Why? The page clearly states: Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users.

I haven't used Vue (and definitely not TS with Vue), but considering how easy it is to create type definitions for libraries written in ES6, if using Vue + TS is awkward (assuming its not because no one wrote a type definition for it), the only way it could make things better for TS users is with some refactorings to make sure types "follow along", and that totally would affect ES6 users. Anything that does not affect ES6 users would not affect TS users either.

An example of this is how in Redux, anything that uses the state in TS needs to add an annotation to type the store, because its completely decoupled (and thus theres no way for the state type to "follow"). Any way to make it follow requires some API changes (eg: creating mapStateToProp functions by calling a method on the store)

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

#318

Post by mmargerum »

ilovecaching wrote: post #73
ElatedOwl wrote: post #62

Earlier quoted context omitted.

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…

I evaluated react/redux and vue/vuex for a project . I wrote a small poc in both. This is why I chose vue

1. Js doesn’t support immutable data structures so trying to return a deeply nested model using spread and other things was ugly. The answer seems to be “flatten your data”. I didn’t have to flatten my model with vuex. Vuex uses mutations when I can keep a flat model of observable but also keep my pristine model that I can send back over the wire with no changes . I suspect mobx may do the same sort of thing for vue. I feel like the react pattern would work better with a language like clojurescript that actually has immutable data structures.

2. Prefer html to Jsx although vue does support jsx. Admittedly this is just a preference thing.

3. Less boilerplate. I felt like I was writing more code that didn’t really do anything useful in react/redux. Vue seemed to have the smallest ceremony to code ratio.

4. Vuetify seemed a lot easier to use and was more polished than the react counterparts. I know it’s just a widget library but I found it fantastic and the docs were great. Vue slots are a great idea

5. Documentation . Vue has second to none documentation and this is important when you are starting out

I build a medium sized app in vue and was astounded that I literally did not run into one issue. That has never happened to me in 30 years. Kudos to that team.

6. React router was on its 4th rewrite. I can’t deal with constant breaking changes

7. Router and vuex felt more cohesive and integrated into vue

Whatever you choose please do support these guys on patreon!

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

#319

Post by nogridbag »

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…

>>The reactivity system will only track changes under certain conditions. Don’t expect to throw anything you wish at it

>This is the one part I hate about vue.

Haven't used Vue for a while, but if I recall correctly it will only track changes on keys defined in the original data object. Is that what you and the parent are referring to?

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

#320

Post by nightski »

octref wrote: post #111
voltagex_ wrote: post #93

Earlier quoted context omitted.

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

This will probably be downvoted but I have come to appreciate frameworks which are opinionated and target a specific use case than very general and trying to please everyone.
Post reply on HN