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..
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.
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.
All those are fine not to have for an existing project, but they're what make people choose other frameworks (such as Angular 2+) for new projects. Angular.js wouldn't have been as big as regular Angular is today if they'd have kept focusing on that - let alone as big as React.
It's not be dismissive of what you currently do. But perhaps you might see new efficiencies that allow you to do more with less, with these newer solutions.
jQuery did it right. They decided on a methodology and stick with it changing the internals and gradually adding features.
> “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.”
One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function would require quite a bit of refactoring.
This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style.
It’d probably cause as much confusion as it helps.
Rust went through that around version 1 where a massive number of answers were updated to match new release and many got "this is not how it works anymore" comments.
That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.
That was overplayed in my opinion by Python 3.2 or so a large percentage of Python 2 code could be made Python 3 code with the addition of: from __future__ import print_function at the top of the file (provided your libraries also went to 3 that is) most people didn't use any of the stuff that was removed.
Edit: Because my comment will probably age poorly, the old headline used to be: "Vue 3 set to change in a big way – Current Syntax to be deprecated"
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 tooling available makes development much more pleasant, and I generally feel like it is harder to write code that is buggy, because a large amount of potential errors are avoided through use of the type system.
Whether or not they've made the right decision with this split is a different question that I can't answer.
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 burnt on refactoring to the “function based” API.
Everyone roles their eyes and the bad wrap Javascript has continues.
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.
What the hell.
Anyway, when it comes to programming, I've found that a single person can often (not always) do a better job than committee rule.
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.
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.