Observation: after removing comments, replacing consecutive spaces with single spaces, and removing remaining spaces from line starts, your old-style code example is 640 characters, and your new-style code example is 854 characters, an increase of about a third.
Yes, it's just one example, code size is highly dependent on choices such as variable naming, longer code may be justified by greater clarity, etc. But it's a hint.
Frankly, I don't find your new-style code example any easier to understand. You seem to think there's no value in "organising components by option type", but knowing what's a datum, what's a computed property, what's a method, etc. is, in fact, part of understanding a component, and in old-style code, these things are obvious, whereas in new-style code, they're less so - not deeply obscure, of course, but it takes a little more effort to grasp them. That the code is somewhat longer doesn't help.
But for purposes of discussion, let's suppose many people do or would find new-style code easier to understand. My advice would be to make it available as a new, separate framework - call it Nue.js. As other commenters have already remarked, those of us who've been around for awhile - and I've done many kinds of programming for over 30 years - have seen this kind of situation before. Inevitably, the new style will become the de facto standard. Ironically, Evan You himself has seen something like this kind of situation before, when he worked for Meteor Development Group, and MDG deprecated Blaze in favor of React. It was highly controversial, and for good reasons. (I and a few others urged MDG to adopt Vue, if they didn't want to maintain Blaze, but to no avail.)
As Yogi Berra may or may not have said, if it ain't broke, don't "fix" it. Every time you change the rules of a programming language or framework, you impose a significant burden on the people who use it, most of whom typically have many other things on their minds and would really like your language or framework to just keep working in the way they're familiar with. Accordingly, it's something to do only with great care and for compelling reasons. "Things would/might be a little clearer this way" is not a compelling reason.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Observation: after removing comments, replacing consecutive spaces with single spaces, and removing remaining spaces from line starts, your old-style code example is 640 characters, and your new-style code example is 854 characters, an increase of about a third.
Yes, it's just one example, code size is highly dependent on choices such as variable naming, longer code may be justified by greater clarity, etc. But it's a hint.
Frankly, I don't find your new-style code example any easier to understand. You seem to think there's no value in "organising components by option type", but knowing what's a datum, what's a computed property, what's a method, etc. is, in fact, part of understanding a component, and in old-style code, these things are obvious, whereas in new-style code, they're less so - not deeply obscure, of course, but it takes a little more effort to grasp them. That the code is somewhat longer doesn't help.
But for purposes of discussion, let's suppose many people do or would find new-style code easier to understand. My advice would be to make it available as a new, separate framework - call it Nue.js. As other commenters have already remarked, those of us who've been around for awhile - and I've done many kinds of programming for over 30 years - have seen this kind of situation before. Inevitably, the new style will become the de facto standard. Ironically, Evan You himself has seen something like this kind of situation before, when he worked for Meteor Development Group, and MDG deprecated Blaze in favor of React. It was highly controversial, and for good reasons. (I and a few others urged MDG to adopt Vue, if they didn't want to maintain Blaze, but to no avail.)
As Yogi Berra may or may not have said, if it ain't broke, don't "fix" it. Every time you change the rules of a programming language or framework, you impose a significant burden on the people who use it, most of whom typically have many other things on their minds and would really like your language or framework to just keep working in the way they're familiar with. Accordingly, it's something to do only with great care and for compelling reasons. "Things would/might be a little clearer this way" is not a compelling reason.