7 ms·
Evan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set
by lwansbrough 7y ago
Evan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set up to a bait and switch in Vue 4.
Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI development (and to this day, still is.)
If you've got a team that's super focused on performance and loves FP, React is always going to be the better choice. Facebook continues to invest heavily into performance improvements. I can appreciate that you guys care about performance too, but you're now stepping on the toes of the guys who really only care about that one thing.
Performance is not the selling point of Vue, nor is functional programming or any of the other weird changes that have been introduced in this RFC. Nobody looked at Vue and was like, "wow, thank god Vue is 2ms faster than React when you render this benchmark component a thousand times."
The people who adopted Vue are the ones who had first rejected the complexity introduced by React. And now your team is saying "well, this approach is for more advanced users" -- what an insult, honestly. Many of us had the foresight to recognize that the complexity introduced in React was not worth it for our teams, or we had already experienced the problems that such complexity introduces, and we chose Vue because it managed in general to be as effective as React without the fuss.
What Vue 3 seems to be is an answer to the question: how can we beat React at its own game? And congratulations if you've done it, but that's not what your users are here for. That's not what we pitched to our teams, our bosses, our stakeholders, etc.
My question to you is: honestly, how am I supposed to manage this? The long term answer seems to be that I have to change my code base to this new syntax (beyond or during Vue 3), at which point I'll be right back where I started when I decided to leave React for Vue. Do you think this is fair to ask of your users? Are you sure this is what we want?
- EvanYou 7y agoFirst of all, this new API has relatively little to do with performance. The main performance gain in Vue 3 comes from a new template compilation strategy invisible to users. Second, I think it is over-simplifying the issue by equaling the new API with Complexity. The RFC can be tough to grok because it is dense; but actually looking at some examples will probably show you that the new API really isn't about "complexity": https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f8af555 https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f... Vue has a wide range of users. I honestly don't quite get how introducing an optional API can be an insult - because we clearly see some use cases we ran into can be more elegantly solved with the new API. Maybe you haven't run into them personally, but that doesn't mean your use case is "inferior" - we are all dealing with different types of applications. However, I think it would be a real insult if you think Vue will never have a use case that is complex enough to warrant these advanced APIs. Regarding your question: feel free to stay with the current API for as long as you wish. As long as the community feels there's a need for the old API to stay, it will stay. The only one that can make the decision to switch to the new API is yourself.
- brylie 7y agoI also appreciate Vue's simple elegance. It is a breath of fresh air, amidst all the dust and commotion of the JavaScript ecosystem's tooling bloat and constant reinvention, that Vue can just be dropped in to ant standard HTML page. Meteor.js, another project with which you are familiar, started with a similar promise of developer simplicity, but it was subsumed and abandoned in favor of the "Facebook-level scalability for all apps and at all costs" mantra that has swept through the JS community. Regardless of the nuances of this RFC, please remember the value of simplicity as Vue evolves.
- brylie 7y agoAnother article, currently trending on HN, describes how we should strive to reduce cognitive load and simplify the development process: > A good platform acts as a force multiplier for [development] teams, helping them to focus on core domain functionality through attention to the developer experience, ease of use, simplicity of tooling, and richness of documentation. > https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters https://techbeacon.com/app-dev-testing/forget-monoliths-vs-m...
- tuesdayrain 7y agoIn my opinion the old API looks significantly better in every every example here. I really hope you guys figure out a way to better preserve that original simplicity. It was what drew me to Vue as a clear winner in the sea of JS frameworks.
- kabes 7y ago> The people who adopted Vue are the ones who had first rejected the complexity introduced by React I dont know if that's true, I think react is super easy, but I prefer the template approach of vue. I think a lot of people are just searching for a modern angularjs that's not the monstrosity angular 2+ is.