Hacker News Reader

Comment by mlthoughts2018 | Hacker News Reader

mlthoughts2018

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.

View on HN

> 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)

Maybe it is a problem with the application rather than the framework?

What problems are you having?

That's not a problem with the framework itself right

> 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.

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.

do you mind sharing the problems? if you could start over, would you have chosen react instead?

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.

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.

Everyone always needs a bunch of "special case features". Always. If you're not doing something new, why are you bothering to write code?

That's like saying that if you don't need to invent new words, why are you bothering to write books.

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.

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.

Right, I think this is evidence that they're not doing as well at that stated goal as they could be.

Exactly, the users are not doing well because they’re expecting to be able to misuse Vue and demand special case features, while Vue itself is doing good by resisting this and sticking to the plan in terms of framework design.

> 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).

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.

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.

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.

Reply on news.ycombinator.com