> 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

It was! The new result just isn't all that much better. They got trapped in their own bubble of complexity.

I think it's a lot better than AngularJS 1.x was, the problem is that it isn't really better than it's competitors.

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.

You may not like it as a technology, but one search on recruitment sites will show you that it's far from dead.

Seems almost completely relegated to .Net shops though, at least where I live.

Im still om angularjs. Cant bother to learn new frameworks every other month. Also using Angularjs in recent projects i never ever thought I was hobbled. Angularjs,jquery,vue - doesnt matter which tool one use. If you know any of these at advanced level you can create anything

The initial release was 8 years ago. Surely, you've had at least an ounce of curiosity about how the front-end ecosystem has changed since then? Even if you didn't adopt it, just to maybe poke around and look at what React, Vue, et. al. are up to?

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.

Absolutely; I was a very satisfied user of Angular.js, and if you have a project in it currently, I'm sure it works just fine. But you're also missing out on a whole lot if you're restricted to their now-clumsy module system, their now-clumsy unit testing setup, their custom syntax with no editor support, its limited ability to work with type checking...

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.

Totally agree. Once you have millions of users you have a great responsibility since they depend on you.

jQuery did it right. They decided on a methodology and stick with it changing the internals and gradually adding features.

The page mentions providing a compatibility build:

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

Maybe just call it Nue.js or something

I don’t see how changing the name helps over a version number.

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.

Because it's essentially a different project at that point. All stackoverflow answers become confusing instead of helpful for example.

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.

Making it two separate project means the library authors have to write two separate libraries using two separate API - the more flexible and easier to maintain (written among others with library authors in mind) function API and the object API that they often have to fight against right now.

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.

I see, I don’t help people often with programming problems so I’ll defer to you guys.

You would get Google answers that are specific to your current version vs wondering if it applies to Vue 1, 2, or 3.

>the whole Python 2 vs 3 distinction

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.

A few months ago I had to decide between Vue and React/Redux for porting over a very large Angular 1.x app at work (I decided against Angular2+ - mostly because I feel pretty burned by Angular). Seeing this headline made me very glad that I picked React.

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"

Why you didn't considered Ember.js? It is modern, great community support, opinionated and easy to use.

More community support than Vue? I’m also confused about the hostility towards Vue by the parent.

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

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 burnt on refactoring to the “function based” API.

Everyone roles their eyes and the bad wrap Javascript has continues.

> 99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world.

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.

Couldn’t agree more, this is the reason I bailed on Angular. Not smart.

If I remember correctly it wasn't just that angular broke stuff but also that they no longer supported older versions and the wanted to bump major versions multiple times a year. Breaks are one thing, promising constant instability is quite another.

AngularJS had it's last major release in 2018 and is in LTS from Google until 2021.

“Yes but I’m only considering Vue because Angular already screwed the last project I used it on”

What the hell.

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

I don't see how it is much different from how Linux, Git, Ruby, or Python were created.

Anyway, when it comes to programming, I've found that a single person can often (not always) do a better job than committee rule.

One bus away from the end of the framework.

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.

It's pretty much become the rule of thumb with frameworks. They come and go. Favoring one concession over the other.

I've used:

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.

Staying static just gives space to complacent, politics playing technology "elders".