Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue RFC: Expose logic-related component options via function-based APIs instead

github.com

Post reply on HN
Print view View original

121–130 of 253 posts

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#121

Post by BigJono »

intothemild wrote: post #109
c487bd62 wrote: post #62

I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.

I just left frontend, and I’m the maintainer for express-vue. Vue is great in its current iteration. But the whole JS ecosystem is just horrible right now. Looking at these changes, it’s not for the better.

I'm almost done with it as well.

I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly.

Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke.

All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#122

Post by pier25 »

ng12 wrote: post #105
pier25 wrote: post #104

Earlier quoted context omitted.

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.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#124

Post by andrewprock »

bartimus wrote: post #57
tnolet wrote: post #16

I might be totally and completely wrong, but changing everything does not help anyone except scratch the itch of the framework's designers. I'm pretty sure this is all with the best intentions, but this would be a disaster similar to how Angular suddenly changed everything . Not against change, but the API is fine. Just iterate and evolve it. disclaimer: Big fan of Vue, early user and conference attender..

It's pretty much become the rule of thumb with frameworks. They come and go. Favoring one concession over the other.

I've used:

logo win32 tk latex opengl mfc html wxwidgets awt swing fltk glut android ios tapestry play templates hugo static site generator vue.js scratch

I'm sure I've forgotten a few.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#125

Post by mharroun »

elwayman02 wrote: post #33
mharroun wrote: post #30

Why don't they just call it a new framework if its undergoing such a major overhaul. This only makes me feel better about picking react at my current company as now I view this framework as dangerous for building anything long lasting.

The React ecosystem introduces huge breaking changes and paradigm shifts literally all the time... coughreactroutercough

Reactrouter is a 3rd party npm package... the core react framework has been very stable and backwards compatible.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#127

Post by root_axis »

c487bd62 wrote: post #62

I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.

Yeah. It's so annoying how developers open source so much of their work. It's as if they just throw things up on the internet and expect people to use it only if it solves their specific problems. What they fail to consider is how inconvenient it is for their fellow developers who are dazzled by everything that hits front page of HN.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#128

Post by akhilcacharya »

enlyth wrote: post #25

The whole html template is one long string literal. I prefer JSX, where the XML is treated as code rather than a long string that needs to be parsed.

I prefer this because it doesn’t require a build step.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#129

Post by thatswrong0 »

BigJono wrote: post #115
pier25 wrote: post #104

Earlier quoted context omitted.

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

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.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#130

Post by mekoka »

Mixed feelings.

I decided to pick up front-end JavaScript a year ago and chose Vue. Although I'm a fan of that specific framework, one thing that I found annoying about the ecosystem (and the great JavaScript family in general) is the "unsteadiness". When I go on StackOverflow and look at questions related to, say, Flask and I see answers dated 2012, I have a sense that although Python has mostly migrated to version 3 now, the answers that I get are likely still relevant today. It's not because Flask has always made the right design choices. But the maintainers stick to their decisions, because people have already invested time to learn to do stuff that way. It's not the best approach, it's not the worst either. You just learn it like this and when you have a problem, you ask on StackOverflow and someone will tell you what hoops to jump through. You'll scratch your head for a minute, but then be on your way to get shit done.

When I look for an answers related to Vue, everything seems to have an expiry date attached to it. Anything dated 2017 raises flags in my mind. Things seem in a constant state of flux. It's like trying to learn to walk on quicksand.

I saw the list of improvements/simplifications/deprecation. Not bad. If Vue was a fresh new framework these changes might have had more value, but it's not. A lot of time and efforts have already been invested to learn to do things the Vue 1 way and the Vue 2 way (not to count the accessory libraries and tooling). So I don't know if after tallying up all the pros and cons (which go beyond the technical concerns listed in the specs) whether this change might actually be more costly than helpful.

Post reply on HN