Quick reminder that you can still write complex and useful form-driven web applications with no JavaScript at all.
Vue RFC: Expose logic-related component options via function-based APIs instead
51–60 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#52I switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.
> the direction they were going with hooks
I'd be really interested in your thoughts on this. What about hooks don't you like so much that it made you abandon React?
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#53I used to be a huge Vue proponent for about 3 years and stopped using it at the end of 2018.
I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use.
MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do.
After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive.
A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects.
(Actually what converts JSX to DOM instructions is a babel plugin from the same author)
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#54I 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..
> 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.
I don't know. I prototyped with Angular and it just seemed like one of those approaches that sorta made sense verbally but not at all on paper.
Like trying to take jQuery and make it a framework like React. But in their attempt to make it "simple" they made it useless. And then the next generation of frameworks like React came out and basically killed it.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#55I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
I feel like I'm shilling a bit for React over here, but they are nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#56@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.
Isn't this half the fun of using JavaScript frameworks?
No, this is the OTHER half of using them. :/
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#57I 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.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#58I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
This change is large enough that’ll be looking at the alternatives after more than two years of defaulting to vue, I mean I may still pick vue but I’ll be looking now where before I wouldn’t have. Change isn’t a bad thing but nor is change for changes sake.
> Change isn’t a bad thing but nor is change for changes sake.
I can understand that the changes here might not be worth it to some, but to call them "for change's sake" is disingenuous and unfair to the Vue team, I think. The linked page clearly motivates the changes. Whether those motivations weigh strong enough for you is a different matter.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#59Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#60Well 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.
A JS framework that a hobbyist can understand in an afternoon is frequently, but not always, not a framework that works at cloud scale.
I support all the choices you make, but there are those of us who have good reason to value useful complexity. <3