Hacker News Reader

Comment by chupa-chups | Hacker News Reader

@Vue team if anyone should read this: I'd recommend to rename vue in the process (for example vueNG or whatever) in order to reduce the amount of false/outdated information when searching for a topic.

View on HN

Yes it becomes a nightmare to search Stackoverflow too.

I still get answers for Vuejs 1.0, with suggestions to use 'partials' for example, only to find out that there exists no such thing in Vue 2.0.

This would be very bad for developers if they still call it Vue with another version number.

Even if they call it VueThree, VueNext or similar then the problem can be easily mitigated I think.

This. I like that the Vue team thinks of ways to improve on the current state of the art and welcome new ideas, but please under a different name. It needs to be succinct enough so that search engines can distinguish the two. Otherwise, there is a big risk of things becoming confusing and frustrating quickly.

Isn't this half the fun of using JavaScript frameworks?

No, this is the OTHER half of using them. :/

AngularJS/Angular split community still have this problem, although less so this year than last.

If they won't, the community could always decide to adopt a tagging or naming standard.

Being able to find answers quickly is a big win for beginners.

How about Vue 3.0?

Yes, that's what the React team should have done when they implemented hooks.

Why? Hooks are completely backwards compatible.

What about books, talks, blog posts, SO answers, etc?

Is everyone going to rewrite all React literature with hooks?

No rewriting needed. Hooks are just another way to do what was already possible in a more well-defined way. All the content written is still applicable. Now there is just a new way to do things too.

The developers and documentation even advises against rewriting old components with hooks unless you need to.

> All the content written is still applicable.

Technically yes, but what if someone only uses hooks and has never used classes?

And, viceversa, since there is now a lot of people moving to hooks and producing React literature for hooks what if you only have used classes?

So now, to be able to read all the React literature one has to understand both methodologies.

> The developers and documentation even advises against rewriting old components with hooks unless you need to.

It doesn't matter. A big chunk of the JS community is hype-based.

So don't listen?

You're gonna have to learn it eventually to work with other code bases and so on. But the point was it doesn't change existing knowledge, just something new to learn.

Hooks are additive.

Well, with React you can "opt in" when searching by simply adding "hooks" to the search term. Such wasn't possible with Angular back then

Since the majority of the community will probably be using hooks from now on it will be assumed that is the default React methodology which will break books, talks, blog posts, SO answers, etc.

You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.

That's not the point.

The point is that most of the React literature available today will become obsolete.

How? It's still perfectly valid, usable, idiomatic React.

If you learned React with hooks the class notation won't make sense, and viceversa.

So they should have renamed the whole framework when they added a single a new feature so people know they need to learn it before reading the examples?

It's not a new feature it's a complete new methodology.

That's quite hyperbolic. Functional components have existed in React for a long time, hooks are just adding existing concepts (state and lifecycle operations) to them.

We will have to agree to disagree. IMO the compositional paradigm of hooks is radically different than using classes for example.

The point is that you don't have to use it. If you can't be bothered to learn a simple new feature then just keep doing it the old way; your code will still work. I don't even understand the complaint; are they never supposed to change anything? It's totally optional; even if most of the community goes down that direction you don't have to.

Beyond that, hooks are super simple and the complainers are just making a big deal out of nothing. They are just callback functions that you implement outside of a class instead of overloading arbitrary method identifiers like "componentDidUpdate".

You also don't have to use it.

This is what I don't get about hooks. Remembering Markbages great talk on 'Minimal API Surface Area'? How is having multiple ways of doing the same thing minimal API surface area?

React is losing sight of what made it great when it came out. Do one thing, do it well, and do it the simplest way possible.

That sort of absolutist logic will never allow a framework to progress and become better. Sometimes good ideas come around (IMO like hooks) that are worth increasing the API surface area for.

I for one loathe using class components now and not being able to share logic compositionally via hooks when I work with them. I feel more productive and I feel like my components are smaller and more focused, and I don’t repeat myself as much. It’s been a net win for me, and I think it’s well worth having two supported APIs that do roughly the same thing.. because despite this, React is still a small and focused library API-wise.

They've increase the surface to reduce it over time, if that makes sense. Hooks are much more natural, simplistic way to write stateful components.

Reply on news.ycombinator.com