Two proposals for Vue 3.0 have recently attracted a lot of attention and discussion from developers. One is the script-setup proposal and the other is the Ref-SUGAR proposal.
Most developers are positive about the script-Setup proposal.
Regarding the Ref-SUGAR proposal, however, a significant number of developers expressed negative views.
In Github related RFC _[0], and Zhihu Q&A [1]_, domestic and foreign developers have actively expressed their opinions. Among them emerged some views and phenomena worth chewing.
This article will select a few interesting fragments to interpret.
What does the Vue proposal actually do?
First, let’s take a look at what Vue’s two proposals are doing.
The script-setup proposal extracts options.setup to the top level.
Write the following:
Use the more concise form below instead:
And the ref-sugar proposal is going to simplify the way that ref.value is written.
As shown above, the number of lines of code becomes smaller and more concise under these two proposals.
That’s what the new Vue proposal is actually doing: providing syntactic sugar in Vue SFC files to optimize the programming experience.
What do critics think the Vue proposal is doing?
We’ve excerpted some of the interpretations of the Vue proposal from some of the developers in the discussion.
1, please don’t make more JS dialects 2, feel not very reliable, and js developers intuition is not the same, easy to fall into chaos. 3. This is a very dangerous signal because modifying JS semantics means losing touch with the ecosystem, and the Vue team is frankly not self-sufficient enough to play an entire ecosystem. At present, the modification of label semantics will not have much impact, but it will cause developers to have doubts about the ecological compatibility of VUE in the future and lose developers. In the world of the Web, no one has a good end when they break away from standards. 4. Both Vue and React have been used for some time. Vue often forgets the syntax and needs to refer to the document to know how to write react, and React rarely needs to consult the document. But only for writing surface programming, you will find that this framework has been eliminated 6, very not optimistic, for dynamic JS semantics to form dialect this solution should be extremely cautious, in order to solve the problem of. Value is worth it? 7, don’t use magic ☹️ 8, think all day did not want to understand, especially big will make such a controversial RFC. I’ve always found it easier to use a decorator than this… I don’t like it very much. It’s counterintuitive and not easy to use. Need to increase user understanding cost
Small improvement vs. big crisis?
In terms of code form alone, the Vue Ref-SUGAR proposal is an effective small improvement, expressing the same logic in shorter, more refined code.
Conceptually, however, some critics see a crisis: Vue’s attempt to challenge standards.
Critics see ref-Sugar as a red flag that Vue is about to embark on a path away from Web standards, that the tech stack is betting that Vue is no longer safe, and that Vue is betraying its previous promise.
It’s perfectly understandable that there’s a huge aversion to anti-standard behavior.
For years, front-end engineers have been frustrated by the lack of Web standards compatibility of major browsers. Whenever a browser does not actively follow the standards and lags far behind other browsers, it will be joked as: XXX is new IE.
We want all browsers to embrace Web standards, we want mainstream frameworks not to come up with their own gameplay, we want a solid, unified underlayer that focuses on product implementation and solves more valuable things, rather than getting caught up in the compatibility of low-level issues.
Defending standards, at the front end, has a natural sense of justice.
Therefore, critics argue that Vue should be improved as long as it meets the standards.
Fourth, the solutions under the standard
Here, we pick a few candidates that developers have suggested that fit the criteria and that they feel would solve the problem.
4.1 the problem does not exist or does not need to be solved
Some developers believe that ref.value is not a problem that needs to be solved.
In particular, with TypeScript, the IDE and the editor are intelligently alerted, rarely missing.value, and feel no mental burden.
The problem is that not everyone writes Vue code in TypeScript, and not everyone doesn’t see.value as a problem.
4.2 Adoption of proposal-Refs Proposal [2]
One developer searched for a proposal-refs in JavaScript and thought it might be a solution that both meets the standards and helps Vue solve the problem.
let ref count = 0;
Copy the codeIf you look closely at the proposal-refs proposal, you may find that it is not at all the same as vue-Ref. Vue-ref is reaction-ref, while proposal-refs describes Reference Binding in the traditional sense. They just use the word ref.
Moreover, this proposal-refs proposal has not made any progress for several years, and it is far from becoming a real standard. Unable to solve Vue’s immediate problem.
4.3. Adopt the proposal-decorators proposal [3]
A new decorators proposal has been proposed to support Variables Decorators.
That is, variable declarations can be decorated and placed in vue-ref scenarios, something like the following.
let @ref count = 0
Copy the codeIt looks very attractive, as if the problem has been satisfactorily solved. But:
First of all, it is so new, it is a very recent idea, it can not be expected if and when it will hit the ground. Far water does not put out near fire.
Second, it is incompatible with the semantics and usage of several current decorators proposals. Once Vue adopts the new decorator proposal, it will likely mean that the prevailing style of decorator usage, which is currently heavily used, is not available and conflicts.
Third, it only addresses the CREATE part of vuE-Ref, not the Access and update part.
What do you mean?
The decorator just helps us create a ref, but the access to the ref. Value and update the ref. Value parts are missing.
This can be overcome by combining proposal-refs with proposal-decorators. Write it like this:
let @reactive ref count = 0
Copy the codeThe order is important, first become a REF object, then add reactive capabilities; I’m afraid not if it’s the following:
let ref @reactive count = 0
Copy the codeIt becomes ref with a {value: 0}, followed by.value.
Unfortunately, the above scenario is an even gloomier scenario with two proposals with low probability of landing. It’s hard to look forward to.
4.4 Variable naming convention scheme
Some developers have proposed that we can specify the name of the ref variable to mark a variable belonging to vue-ref.
Or simplify the.value attribute.
They think it mitigates the problem, though it doesn’t solve it completely.
This may be feasible in practice, but this level of resolution may not be worth it. Developers are still reminded that the variable being manipulated is in a ref wrapper.
4.5 Comment-based scheme
A developer has proposed that a variable belonging to vuE-ref can be marked with comment.
This makes sense, as JSDoc uses annotations to mark and document function types with success.
However, there is another side to the vue-REF problem: accessing ref objects. We can’t watch a Primitive value. We need to watch Reactive value.
Therefore, the comment-based scheme, even if it does away with the sugar part of the ref: tag syntax, might want to keep another ref-sugar feature: $count.
In other words, comment-based is itself an incomplete process for solving vue-ref problems. It also introduces new problems. Developers may start forgetting to add comment markers too often, and it is a challenge to establish a new habit of writing comments first and variable declarations later.
There are other options that are not mentioned, and most of them are even more unplayable.
In general, other options under these criteria have various drawbacks and do not adequately address vuE-REF problems.
5. Composition and evolution of standards
Recall the criticism of ref-SUGAR for violating norms and standards.
The word “standard” mainly plays an unquestionable, unviolated, unnegotiable role, not a clear face.
Standards and norms are supposed to be perfect.
In fact, standards and norms are not ironclad and uncompromising. If we are willing to move closer to standards and specifications, we will see more details…
5.1 Standards and specifications are behind The Times
Standards and specifications also serve as a record and backward compatibility function. Especially things like JavaScript that actually existed before they were written to standard.
In the ECMAScript specification, there is no shortage of compilations and descriptions of JavaScript’s old, outdated, and no longer recommended language features. Arguments, with, Prototype, etc.
Therefore, even if it conforms to standards and norms, it is not necessarily good, correct and in line with the needs of The Times.
5.2 standards and specifications, not everything is equally important
Vue ref-sugar: new statement labeled statement (Vue ref-sugar) So Vue author You Xiaoright says it is still grammatical JS code.
Then, a developer found this sentence from the ECMAScript specification _[4]_ :
Provided the Static Semantics: Early Errors It is a Syntax Error if ContainsDuplicateLabels of StatementList with argument is true.
If labels with the same name appear in the same scope, it is a Syntax Error in Static Semantics.
For some developers, this strongly refutes Yoshto’s claim that the JS code is legitimate, that Vue ref-sugar is not only semantically and syntactic bankrupt, that it is completely anti-canonical and should be abandoned.
This view, too, may not hold water.
Static Semantics is also a kind of Semantics [5], but some of its rules just describe the grammatical structure. When You say that ref-sugar is still legitimate JS code, he means legitimate in strict reference to Parser level. He does not attempt to express any Static Semantics or any other level of legitimacy.
He emphasizes the legitimacy of tools like Babel, Webpack, TypeScript, ESLint, Prettiter, V8, and runtime parsing of JS code.
We cannot refute a man’s unexpressed opinions.
More importantly, Babel, Webpack, TypeScript, ESLint, Prettiter, V8, etc., all fail to implement the Static Semantics of ContainsDuplicateLabels.
As mentioned above, in the Chrome console, you can run code that contains namellabels without any problems.
That is to say, in fact, not all parts of standards and codes are of equal importance at a practical level. Some innocuous parts, many tools and JS engines, are not implemented.
So not all parts of standards and norms deserve the same toughness.
5.3 standards and specifications are evolving and semantics can be adjusted
Critics say that ref-SUGAR has modified the semantics of a labeled statement and is immoral.
In fact, however, it is perfectly natural, common, and feasible to tweak the semantics of an existing grammar in a given context.
The JavaScript language does this itself — in strict mode.
JS code in strict mode and non-strict mode, the same syntax, but also different semantic behavior.
Assigning a variable without declaring it is equivalent to assigning a global variable in non-strict mode. But in strict mode, an error is thrown.
ES3 and ES5 standards produce different semantic interpretations of the same code.
Standards are not static, standards are also evolving, evolving.
Of course, critics may continue to insist that ES5 is a new language standard compared to ES3, that only the new language standard can be adjusted, and that Vue is just one of the frameworks in the JS language that cannot do so.
So, let’s look at the following code:
For developers familiar with Node.js, this is an example of Node.js hello World code. What does that have to do with what we’re talking about here?
From a functional point of view, this is true. If we look at it from the perspective of JS syntax and semantics, the situation is different.
It is easy to see from the original semantics of the JS code that the above code should generate four global variables: HTTP, hostname, port, and server, because they are declared and used in the global scope.
However, the fact that it runs in Node.js does not generate the above global variables, they are executed wrapped in a function that is a CommonJS Module, not plain JS code.
In other words, the semantic behavior of this JS code in the context of CommonJS Module has been changed from mounting global variables to local variables in the CommonJS Module.
Node.js is a Runtime /platform, it is not an ES5 language specification, it also modifies the semantics/behavior of JS code.
Ref: count = 1: ref: count = 1: ref: count = 1: ref: count = 1
Is tweaking the semantic behavior of code something the new ES5 language specification does, the new Node.js platform does, but not the new vue.js framework?
Critics may continue to narrow the scope of their attack: View.js is naturally capable of tweaking some semantic behavior, and the script-setup proposal tweaks the top-level output to options.setup, which most developers agree with. But ES5, Node.js, and script-setup are all tweaks to the original semantics, either reporting errors or changing from global variables to local variables.
However, ref-sugar labeled statement with a new meaning unrelated to its previous meaning, which is unacceptable.
5.4 standards and specifications often lag behind practice
Assuming that developers play strictly by the standards, technology can become sluggish or even stagnant.
Standards and specifications often lag behind practice. After various explorations at the practical level, and the formation of many different forms of solutions, but not very different in nature, the need for standardization arose.
One purpose of the Babel tool is to allow developers to write new language features that have not yet been fully included in the standard in practice, adjust the stage of the proposal based on the feedback of the developer’s actual use, and finally implement the proposal into the standard.
In other words, as front-end engineers, we are allowed to use features that are not in the current stable specification.
If you feel that Babel push proposal is at least a route towards the specification, rather than the opposite of the specification as Vue’s Ref-SUGAR might be. So:
TypeScript exists, which gives JavaScript the wings of type-system, while the ECMAScript specification has no intention of incorporating Typed JS.
This means that working with TypeScript is not a path to the ECMAScript specification either. Even TypeScript itself doesn’t have a specification yet.
So does this mean, front-end engineers, that using TypeScript is a gross violation of ECMAScript?
Standards and specifications don’t necessarily give us all the tools we want, they don’t provide them yet, but they will, and they require us to work with volatile standards features. If it doesn’t, we need to find other ways and tools to meet it.
This kind of pioneering practice is happening not only in languages like Babel/TypeScript, but also in front-end frameworks.
React’s JSX extension falls outside the ECMAScript specification. However, it is currently popular in front end development and brings great value.
Sebastian, a member of the React Team, proposed a one-shot Delimited Continuations with Effect Handlers proposal in 2016 [6]. He believes that this feature, Very valuable for the UI Framework and hopefully pushes it forward. But in the end, the proposal went nowhere.
Instead of stopping and waiting for the standard, the React Team chose to refactor the React infrastructure with a Fiber Architecture that allowed the framework to take over the call-Stacks management of components, emulating algeaic Effects features through various technical means. A new react-hooks feature was introduced, which has had a positive impact on other frameworks such as Vue.
Standards are once again lagging behind practice and will continue to lag.
We should allow new platforms like Node.js, new languages like TypeScript, new tools like Babel/JSX to provide new uses, and new frameworks or versions of frameworks like React and Vue to make new explorations.
It is these new explorations that help guide the specification. Knowing which patterns have proven to be extremely valuable.
Therefore, the labelled statement syntax in Vue SFC is not as abnormal as many people think.
5.5. Norms are not the only source of authority
If we open up a little bit further, beyond JavaScript. As you can see, the ECMAScript specification is just a specification in one of the languages.
In this world, there are still many languages, and they have their own advantages. They are worth JavaScript learning. In fact, JavaScript has learned a lot from other languages.
Is Vue ref-sugar so perverse in other languages?
Isn’t.
For example, the $count infinitive variable also exists in languages such as Swift/Kotlin.
As above, computed Property in Swift supports the Shorthand Setter Declaration _[7]_, that is, set(value) {} can be omitted and Setter parameters can be accessed using the reduced form variable newValue.
Although newValue has only one variable, Vue ref-sugar can create many $refs depending on the number of Ref:. But that’s just a quantitative difference. Qualitatively, they’re the same.
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE MultiWayIf #-}
module ShellCheck.Parser (parseScript, runTests) where
Copy the codeAs mentioned above, Haskell supports adding LANGUAGE feature plugins via {-# LANGUAGE * #-} syntax.
There are even macroscope-supporting languages such as Rust that already provide standard tools for changing syntax and semantics.
As above, Rust’s serde_JSON provides JSON! Macro, which lets developers write JSON in Rust code.
As above, Rust’s typed_HTML provides HTML! Macro allows developers to write HTML tag structures in rust code.
As mentioned above, Juniper of Rust provides Derive Macros, which can mark a RUST enum corresponding to a GraphQL enum.
This approach is similar to the comment-based solution mentioned earlier. However, whether comment-based or label-based, they only have different forms. What is important is that they both modify or enhance the semantics of a particular syntax through the way of marking.
Just because ECMAScript doesn’t currently offer features like Language Extension or Macro doesn’t mean we can stop learning what has proven to be a positive value in other languages.
In the current mainstream front-end development infrastructure, there are already several Parser and Compiler, such as Babel, Webpack, TypeScript, ESLint, Prettiter, V8, etc. Vue also has its own VUE-Compiler.
Almost all of our code is compiled multiple times. In terms of toolchain capabilities, it is perfectly possible to provide transformations similar to Language Extension and Macro. Babel Plugin, Babel Macro, angualr-Compiler, vue-Compiler, etc., have done this for some template objects.
Sooner or later, front-end frameworks will drain the current JavaScript language of expression, and digging deeper will make it difficult to solve the problem. Compiler processing is required. This is exactly what Svelte is trying to do. It gives full play to the initiative of Compiler and implements the reactivity mechanism through compile-time transformation without runtime abstraction.
React has a long history of runtime abstractions and also implements complex scheduling processes such as Concurrent Mode. However, the possibility of automatically supplementing useEffect dependent arrays with compiler is still being explored.
Angular’s next-generation compilation and rendering pipeline technology, Ivy, is also optimized using compilation technology.
A few years ago, the community called out “Compilers are the New Frameworks.”
Vue is not the first to take this step. Vue, on the other hand, is probably the most prudent one with a new labeled statement syntax inspired by the similar usage in Svelte. It is a relatively mature consideration made under the achievements of predecessors’ exploration.
Vi. Label- SUGAR proposal
Vue’s caution is also reflected in the fact that ref-SUGAR is a special case of the more generic label-sugar.
The Vue Team took into account the potential for resistance to the new semantics and was determined to solve vuE-Ref’s usability problems with the least cost sacrifice.
Here, we can brainstorm what a more generic label-sugar might look like.
For example, provide more labels with different functions.
As shown above, use expose to express the output of the component, onMounted to express onUnmounted, and unmounted to express onUnmounted.
Label can be combined to express an expose and output a ref.
For example, in the React component:
As above, we useState to express useState, effect to express useEffect, and callback to express useCallback. Component code is written more neatly and succinctly.
It’s an interesting idea, and I personally don’t reject the style. In my opinion, it amounts to a refinement of the commonJS Module nature, from module level to function level. In functions, use label to enhance function expression.
Maybe we don’t get there for a while. Vue is in ref-sugar, so it’s a good thing to take a little step forward and verify that.
Seven,
The above article is not to say that Vue ref-sugar is necessarily the right approach, we should support it unconditionally.
But to emphasize that Vue Ref-Sugar’s approach and design are not as scary and dangerous as some critics make them out to be. It seems more like a small step. This kind of practice and design is also common in other languages and projects. Even on the front end, Vue is not the first to do this.
Vue ref-SUGAR is opt-in and neither forces developers to use it nor prevents developers from using their favorite, familiar patterns.
If you can find a solution that meets the requirements under the standard, it is best not to take risks.
However, until we find that perfect solution, we should not give up on the optimization within our grasp and stop doing nothing.
Even if Vue Ref-Sugar turns out to be on the wrong track, its reach and handling are not irredeemable. All Vue ref-SUGAR code can be easily converted to its original form, or newly discovered form, in batches and automatically through Codemod.
At the same time, we should be more tolerant and allow the framework to err to a certain extent. It’s hard to hope for a fault-free perfect framework, but we can hope for a self-correcting growth framework.
I had no idea that such an optional, revocable, prudent proposal, which had been successfully explored before, would be so vehemently opposed and criticized.
I feel that at the root of this is probably a difference in understanding of the relationship between language standards and frameworks.
Perhaps in the minds of many developers, frameworks <= languages.
For example, Vue, React, Angular, and Svelte are frameworks in the JS language. They are subsets of the JS ecosystem, and they are constrained by the JS category.
Vue Ref-Sugar, in this case, is challenging authority and committing suicide.
This view is not entirely wrong, but rather one-sided.
Frameworks are bigger than we think, as big as: frameworks > languages.
Frameworks are for domain-specific solutions, and all languages and tools are available to them.
Sometimes, it chooses a single language as its main tool, even if all related software is implemented in the same language. But that doesn’t mean the language is above the framework.
From a Vue perspective, JS is just a runtime language selection. In fact, the programming language of choice for Vue 3.0 is TypeScript. In the future, Vue can be written in other languages, run on Web/Node.js platforms, and run on other Native platforms via compile-to-JS or WASM.
Vue also uses HTML, CSS, and custom Template syntax. Web development itself is a multi-language collaboration model, and it is hard to say that any one language is superior to any other.
JavaScript is just one of the languages. Vue chooses JS to write code when it works well for the problem. Vue chooses TS when it can better solve a problem.
Vue chose to keep the original JS semantics when they would have served the problem well. Vue chooses to enhance the semantics of a statement labeled with JS while doing a good job of solving the problem.
Vue is facing the domain problem of UI development, it is not JS’s subsidiary, but JS is one of its tools and means to solve the domain problem.
The Vue Ref-SUGAR proposal, from this perspective, is a natural thing to do.
All techniques and tools, including JS/TS/Template, are adjustable to solve the problem. The key is to look at costs and benefits.
As long as the benefits, in the long run, are greater than or far greater than the costs, the scheme is workable.
If critics are willing to read you xiaoyou’s explanation and reply carefully and understand it from the cost-benefit perspective, it is easy to find that choosing label Statement is a practical choice that fully considers the cost of tool chain adaptation, learning cost, use cost and other aspects.
Framework authors, who are closer to developers than those who write standards and specifications, care more about what developers want.
Developers’ demands are first absorbed by framework authors, and then those who write standards and specifications have to communicate and collaborate with framework authors to provide new features that can meet the framework’s subsequent development needs.
The framework even contributes code upstream for features it desperately wants (Facebook contributed code to Google Chrome to implement the isInputPending API required by the React framework).
It makes more sense for us to trust honest, responsible framers than to idolize standards and norms.
Now, look at the Vue ref-SUGAR proposal again and wonder if there is a different experience:
[0] New script setup and ref sugar New script setup and ref sugar by YYx990803 · Pull Request #222 · vuejs/ RFCS [1 Vue’s REF syntax sugar proposal? [2] proposal-refs rbuckton/proposal-refs [3] Decorators: A New Proposal Decorators: A New Proposal [4] ECMAScript® 2021 Language Specification TC39. [5] Wiki: Static Semantics en.wikipedia.org/wiki/Progra… [6] One-shot Delimited Continuations with Effect Handlers One-shot Delimited Continuations with Effect Handlers [7] Swift: Shorthand Setter Declaration The Swift Programming Language
@ from www.zhihu.com/question/42…