6 ms·

I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript

by mlthoughts2018 6y ago

I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. As long as the maintainers are responsive to bug fixes and key feature requirements (since they aren’t accepting of outside contributors adding them), then this is fine, possibly even optimal in terms of quality. The trouble comes in if they both don’t allow many outside contributions and at the same time they pull the same unjustified complaint of a lot of OSS and say because they aren’t paid for their time, they will prioritize what interests them rather than what resolves painpoints or missing features users need. You definitely can’t have it both ways.

bird_monster 6y ago
> I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. Which is much easier to attain if you're comfortable with only a single person being allowed to write code. Personally, I wouldn't use Vue in any business-oriented application for this exact reason. The "bus factor", or as I would call it, "If and when Evan decides to stop caring about Vue", is enough to make Vue dead in the water as a legitimate FE library choice (to me).
- that_guy_iain 6y ago
  The org has 49 people on it. And every project that has one people who leads it can surive without that person, it's called they fork the project.
  - bird_monster 6y ago
    https://github.com/vuejs/vue/graphs/contributors?from=2016-04-10&to=2021-01-09&type=a https://github.com/vuejs/vue/graphs/contributors?from=2016-0... Here you can find the code additions Github Insight. The org can have 49 people in it, but 48 of them are not writing code for Vue.js.
- feoren 6y ago
  This is why you should always avoid every giant "do everything" framework. Use libraries that are small, focused, and do their one job well enough right now. Then it doesn't matter if it stops being maintained: it still keeps doing its job well. If you do have to replace it, it's much easier, because it doesn't do too much. Vue, Angular, React -- all of them are "build your application around our framework" libraries, not "easily incorporate our library into your workflow" libraries. That is enough for me to immediately reject all of them.
felipellrocha 6y ago
> Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question)
- that_guy_iain 6y ago
  > I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question) I am sure majority of developers have had two or more projects using the same framework/library and found the difficulty of maintaining them different.
  - edoceo 6y ago
    I manage (different) teams with Vue, RiotJS, React, Django, Slim and Rails as large components of the project stack. Maintenance of revenue generating code is a unique beast - and rarely has the framework been the magical differentiator.
- ficklepickle 6y ago
  Maybe it is a problem with the application rather than the framework?
- ttxndrx 6y ago
  What problems are you having?
- vijaybritto 6y ago
  That's not a problem with the framework itself right
- panabee 6y ago
  do you mind sharing the problems? if you could start over, would you have chosen react instead?
ng12 6y ago
I think the opposite: it's a sign that your API is too wide and users expect more special cases and edge features to solve their needs.
- mlthoughts2018 6y ago
  If a user felt that way, it would make no sense for them to choose Vue. Vue’s up-front, stated design goal is omit special cases or edge features intentionally and directly assert that’s not a good way to design a framework. Vue may be right or wrong, but nobody wishing for special case features can claim to be surprised. If you picked Vue knowing you need a bunch of special case features, that’s on you.
  - feoren 6y ago
    Everyone always needs a bunch of "special case features". Always. If you're not doing something new, why are you bothering to write code?
    - elygre 6y ago
      That's like saying that if you don't need to invent new words, why are you bothering to write books.
      - feoren 6y ago
        The abstractions a framework makes available are not analogous to words, but rather ideas. Indeed you should not bother writing a book if you have no new ideas.
    - mlthoughts2018 6y ago
      I use Vue and haven’t found it hinders me from doing this myself. Are you suggesting Vue should not just release a framework but also solve every user’s special case? Your comment isn’t making sense to me.
  - ng12 6y ago

bird_monster 6y ago

> I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. Which is much easier to attain if you're comfortable with only a single person being allowed to write code. Personally, I wouldn't use Vue in any business-oriented application for this exact reason. The "bus factor", or as I would call it, "If and when Evan decides to stop caring about Vue", is enough to make Vue dead in the water as a legitimate FE library choice (to me).

that_guy_iain 6y ago
The org has 49 people on it. And every project that has one people who leads it can surive without that person, it's called they fork the project.
- bird_monster 6y ago
  https://github.com/vuejs/vue/graphs/contributors?from=2016-04-10&to=2021-01-09&type=a https://github.com/vuejs/vue/graphs/contributors?from=2016-0... Here you can find the code additions Github Insight. The org can have 49 people in it, but 48 of them are not writing code for Vue.js.
feoren 6y ago
This is why you should always avoid every giant "do everything" framework. Use libraries that are small, focused, and do their one job well enough right now. Then it doesn't matter if it stops being maintained: it still keeps doing its job well. If you do have to replace it, it's much easier, because it doesn't do too much. Vue, Angular, React -- all of them are "build your application around our framework" libraries, not "easily incorporate our library into your workflow" libraries. That is enough for me to immediately reject all of them.

felipellrocha 6y ago

> Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question)

that_guy_iain 6y ago
> I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question) I am sure majority of developers have had two or more projects using the same framework/library and found the difficulty of maintaining them different.
- edoceo 6y ago
  I manage (different) teams with Vue, RiotJS, React, Django, Slim and Rails as large components of the project stack. Maintenance of revenue generating code is a unique beast - and rarely has the framework been the magical differentiator.
ficklepickle 6y ago
Maybe it is a problem with the application rather than the framework?
ttxndrx 6y ago
What problems are you having?
vijaybritto 6y ago
That's not a problem with the framework itself right
panabee 6y ago
do you mind sharing the problems? if you could start over, would you have chosen react instead?

ng12 6y ago

I think the opposite: it's a sign that your API is too wide and users expect more special cases and edge features to solve their needs.

mlthoughts2018 6y ago
If a user felt that way, it would make no sense for them to choose Vue. Vue’s up-front, stated design goal is omit special cases or edge features intentionally and directly assert that’s not a good way to design a framework. Vue may be right or wrong, but nobody wishing for special case features can claim to be surprised. If you picked Vue knowing you need a bunch of special case features, that’s on you.
- feoren 6y ago
  Everyone always needs a bunch of "special case features". Always. If you're not doing something new, why are you bothering to write code?
  - elygre 6y ago
    That's like saying that if you don't need to invent new words, why are you bothering to write books.
    - feoren 6y ago
      The abstractions a framework makes available are not analogous to words, but rather ideas. Indeed you should not bother writing a book if you have no new ideas.
  - mlthoughts2018 6y ago
    I use Vue and haven’t found it hinders me from doing this myself. Are you suggesting Vue should not just release a framework but also solve every user’s special case? Your comment isn’t making sense to me.
- ng12 6y ago