Earlier quoted context omitted.
This. I've used React and to my surprise even liked it, but if you have to start all over every 3 years, you've got to ask whether pulling your model ... whatever over to the client is actually worth it in the vast majority of cases. What was wrong with SSR and a bit of jquery and Ajax again?
Note that I said "no JavaScript at all", not "a bit of jquery and ajax"
Vue RFC: Expose logic-related component options via function-based APIs instead
151–160 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#152There is a theory which states that if ever anyone discovers exactly what a JavaScript framework is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#153Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#154Mixed 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…
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#155I 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?
Anyway, when it comes to programming, I've found that a single person can often (not always) do a better job than committee rule.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#156I 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?
I think it cuts both ways. As a sole developer he can push Vue quickly into new directions. It has been part of Vue's success and will be the cause of its downfall.
Vue has a history of rough upgrades, version 1 to 2 wasn't fun.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#157Earlier quoted context omitted.
Svelte?
Even better avoid using a framework if you can. Vanilla JS is reasonable for a lot of things.
Doing things in vanilla js just means I end up duplicating a lot of the framework code. Vue really was very simple and minimalist. Just pass it your object and it's reactive and very easy to get started. Fairly unobtrusive as well.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#158@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.
Being able to find answers quickly is a big win for beginners.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#159Earlier quoted context omitted.
While I don't disagree about the fact it will likely cause a split similar to Angular, they seem quite explicit about the reasons (not to scratch the itch of the framework's designers). For me, working in a large project with TypeScript vs one in vanilla JavaScript makes all the difference in terms of how maintainable it is. The number and the nature of the tests I need to write for such project changes, the IDE tool…
My quip about scratching the designer’s itch is mostly about the following. 99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world. Changing the syntax will almost certainly yield zero benefits to the folks out in the field running apps for their businesses. They will end up with the same app, with the same functionality, just $100k lighter due to hours bu…
Can't say I agree. Lots of people became aware of vue/seriously evaluated it around the time of the 1.0/2.0 breakage, myself included. Vue IME has caused more breakage than react has, though I would note that React best/common practices have evolved somewhat more radically; it's just that backwards compat has (mostly) been maintained.
I think a better/more common reason why people use it is that vue does a better job than react of forcing a separation of logic/styling/rendering, which react components have a tendency to intermix eventually.