Vue RFC: Expose logic-related component options via function-based APIs instead • Hacker News Board

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

#111

Post by eximius » Thu, Jun 20, 2019, 11:28 PM UTC

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

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

#112

Post by HatchedLake721 » Thu, Jun 20, 2019, 11:28 PM UTC

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.

Try Ember :-) like a breathe of fresh air in the ever changing JavaScript ecosystem

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

#113

Post by karmakaze » Thu, Jun 20, 2019, 11:30 PM UTC

If it's going to break compatibility anyway, go big. I would welcome something like what Svelte did for v3.

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

#114

Post by seancoleman » Thu, Jun 20, 2019, 11:34 PM UTC

It seems like a distant dream where Evan You promised 99% syntax backwards compatibility: https://medium.com/the-vue-point/plans-for-the-next-iteratio....

About a year ago, my team rebuilt a large solar power plant prediction modeling Angular 1 application with Vue.js 2.0. It was the only big bang rewrite I've heard of that was a massive success. I work in Vue.js everyday and swear by it. Mr. Evan You, don't do this to us.

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

#115

Post by BigJono » Thu, Jun 20, 2019, 11:40 PM UTC

pier25 wrote: post #104

ng12 wrote: post #94

Earlier quoted context omitted.

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

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.

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

#116

Post by numbsafari » Thu, Jun 20, 2019, 11:42 PM UTC

I personally feel like I need some time to play with this in the context of my own projects before truly passing judgement. My initial reaction “seriously, wtf?” Personally, for me, if Vue can remain the simple, compact, non-dependency hell that is React, I’ll take whatever they do.

My big question is how does this approach scale, and does it need a more fleshed out set of helpers, a la the mappers they have in the current API. Won’t really know until I work with it. Would also love to see how this approach works into, for example, Vuex.

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

#117

Post by numbsafari » Thu, Jun 20, 2019, 11:43 PM UTC

numbsafari wrote: post #116

I personally feel like I need some time to play with this in the context of my own projects before truly passing judgement. My initial reaction “seriously, wtf?” Personally, for me, if Vue can remain the simple, compact, non-dependency hell that is React, I’ll take whatever they do. My big question is how does this approach scale, and does it need a more fleshed out set of helpers, a la the mappers they have in the c…

Also, this seems like the kind of change that would greatly benefit from some automatic code rewriting tools a la go.

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

#118

Post by quickthrower2 » Thu, Jun 20, 2019, 11:46 PM UTC

davnicwil wrote: post #68

quickthrower2 wrote: post #37

Earlier quoted context omitted.

Even better avoid using a framework if you can. Vanilla JS is reasonable for a lot of things.

This is completely true, but in my opinion there's no overlap of usecases where either one of these frameworks or vanilla js are both reasonable solutions. If you have a usecase that vanilla js is reasonable for, using a framework in the first place was just a plain bad choice, most likely.

I'm not sure everyone makes that consideration. I reckon many developers would chuck a JQuery or React dependency in without thinking about whether it is the right thing to do, because they are used to it.

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

#119

Post by Roboprog » Thu, Jun 20, 2019, 11:47 PM UTC

Androider wrote: post #101

Not a Vue programmer, but looking at the code, why is the example code using {{ count }} instead of standard JS interpolation like ${count}, and using an App.template block instead of just returning the template with the count and other params. E.g. why not just make it plain JS, and minimize framework surface? I could rewrite that example removing almost all of the "Vueisms", and it wouldn't be a single line longer.

Output encoding

Js template strings insert any text as is, rather than encoding HTML special characters to avoid injection exploits

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

#120

Post by Roboprog » Thu, Jun 20, 2019, 11:55 PM UTC

Sorry about the breaking changes, but glad “this” will be going away.

Thinking about transitioning (from AngularJS) to Vue, but prefer FP to OOP, and I’m glad that these new value wrapper things can be passed or used as partially applied arguments, as well as the other functional composition support changes.