291–300 of 382 posts
> 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.
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.
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…
So e.g. if you want to have a Leaflet map i.e. `this.map = L.map(...);`, Vue will automatically add reactivity to this property. Sometimes I had big problems with this behavior (or it was simply annoying), so I wrote vue-static based on ideas of the core developers:
https://github.com/samuelantonioli/vue-static
Now I can have big objects in the Vue component which don't get automatically tracked using the reactivity system.
- - -
A problem for many beginners:
Another problem with the reactivity system is that sometimes you have a route like `/employees/:id` and edit an object. But on abort, you want to rollback. One thing you always have to do is to copy the object you want to edit (I use lodash's `_. cloneDeep(obj)` for this). If you use Vuex, it's not such a big deal because it works using immutable state, but when you work with a plain javascript object this will definitely generate some headaches.
- - -
But otherwise, I think Vue is definitely the way to go. `v-model` can be seen as syntactic sugar while you have to add it to react inputs and textareas manually (using onchange and setState).
You can write stateless Vue code just fine and use JSX. On the other hand, React misses some of the cool features like the Vue component files (.vue files) and its templating language. And the best is: The framework doesn't say that you have to use it. It's not so opinionated but still feature-complete with the official plugins.
Earlier quoted context omitted.
Vue reminded me so much of Ember that I could not understand how people could think of fresh air...
Embed is more complicated than vue to use. Vue has components. Updating the dom is mostly mutating your component attributes. That's it. Nothing else. With ember you got controllers, models, inheritances, many special methods... The VueJS documentation also makes it easier to get in. The Ember beginer tutorial starts with a full fledge app with a cli to install and use and features routing and addons O_o
All that templating and two-way-binding stuff.
Sure, Vue goes a bit more in a lean direction, because it doesn't offer as much out of the box as Ember, but the idea behind the components seem to be similar.
React or Angular (>2) have entirely different approaches, from one another and from Ember/Vue.
They felt fresh to me.
I'd say today, there is little to no reason for small to medium sized websites to use React instead of Vue.js
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?
I'm curious whether Facebook actually have any endpoints where exceedingly fast rendering is necessary because it'd be the bottleneck. Facebook tends to be really slow for me but I figure that's down to it being really slow fetching data.
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…
Mithril.js is a framework that is truly "magical" in my opinion. I mean its 8kb, includes routing and XHR Utilities out of the box. Faster render times than Angular, Vue and React. You can write HyperScript or JSX. The syntactic variants allow you to write your components as ES6 Classes or closures. Lifecycle methods, a render and mount option and the list goes on and on. People tend to dismiss Mithril because it's a lesser known framework but it has a vigorously thought through programmatic approach and you've got a direct line with the maintainers, you cannot match that.
Sure, each to their own but calling Vue "Magical" is an incorrect assessment.
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…
I've felt the same way. Vuex, Redux, MobX, or other application state libraries, all help in the event when passing data down through components that don't care about the data they are passing along becomes tedious. I like the general idea of "data down, actions up", but when it comes to separation of concerns, what is the point of a component taking parameters that it is just going to pass to a subcomponent? When co…
There's your problem I think, as other sibling comments pointed out.
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…
I wonder how you avoid writing stateful components in real-world complex SPAs.