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

131–140 of 253 posts

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

#131

Post by michaelchris »

eximius wrote: post #111
treelovinhippie wrote: post #47

Well that's enough to reinforce my switch to https://svelte.dev I want a JS framework simple enough that even hobbyist devs can understand in an afternoon. React syntax is an overly complicated mess; like reactivity forcing itself onto HTML. Current Vue syntax is neat, simple and clear; like HTML with added reactivity.

Is Svelte 3 production ready? I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2? I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...

On what I've read, Sapper is still v2. Understandable I guess since Svelte has a small community.

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

#132

Post by avinium »

To be honest, I don't actually mind these changes. Grouping all exposed members together makes for a cleaner API and the functional style makes reuse a lot easier, so that should trim down code length.

But.....that's not a sufficiently compelling reason to change. Even with backwards compatibility, it still adds confusion to the mix, requires a huge effort in new/updating documentation, etc.

I can't really see how the benefits justify the effort.

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

#133

Post by Scarbutt »

snaky wrote: post #98
Sir_Cmpwn wrote: post #51

Quick reminder that you can still write complex and useful form-driven web applications with no JavaScript at all.

Sure, but are there any people or companies who would willingly pay for this kind of web applications?

Sure, why not? highly depends on the product of course.

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

#134

Post by pests »

pier25 wrote: post #59
zwily wrote: post #34

Earlier quoted context omitted.

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.

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

#135

Post by root_axis »

akhilcacharya wrote: post #128
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.

True, but realistically you need some kind of build pipeline for production quality JS anyway so adding it in is pretty painless.

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

#136

Post by alexbanks »

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

How do people get over the issue of Evan You being the only code-writing contributor to Vue?

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

#137

Post by jrs95 »

pier25 wrote: post #88
Vinnl wrote: post #46

Earlier quoted context omitted.

> this would be a disaster similar to how Angular suddenly changed everything. To be fair to Angular, if they'd stuck with what they had, it'd have faded into obscurity far more than the current version has. Angular.js was great for its time, but lost most of its advantages as the web caught up, and what used to be its advantages started to become kludges.

The problem with Angular 1 is that it was slow and bloated, relatively speaking. Google could have improved on that instead of starting from scratch, or ok, start from scratch but use a different name.

Restarting was honestly the best decision, they just had the wrong abstractions in AngularJS

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

#138

Post by ng12 »

pier25 wrote: post #122
ng12 wrote: post #105

Earlier quoted context omitted.

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.

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

#139

Post by ng12 »

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.

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.

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

#140

Post by root_axis »

pier25 wrote: post #122
ng12 wrote: post #105

Earlier quoted context omitted.

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.

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.

Post reply on HN