JavaScript has long been criticized for being created in 10 days by Netscape in 1995. Nothing is perfect in 10 days, but once certain features are released, bugs or imperfections quickly become essential features and are almost impossible to change.

Javascript moves so fast that there is no time to tweak the design. A year and a half after its introduction, the international standard came out. Design flaws were standard before they were fully exposed.

Left over from history

Examples of common historical design flaws:

  • nullundefinedIt’s easy to confuse the two
  • = =Type conversion problems
  • varDeclare create global variable
  • Automatic insertion of end-of-line semicolons
  • The plus sign can indicate the sum of numbers or the concatenation of characters
  • NaNStrange properties
  • More…

There are many loose features of Javascript that we can add esLint to get around. For example, disabling var and == became a prerequisite for most people to write code.

Present/future

Today the CSS, DOM, and HTML specifications are written by the W3C, and the JavaScript specification is written by TC39. Those historical flaws are in the past, but there are now some unsatisfactory norms.

CSS variable

When declaring a variable, the variable name is preceded by two conjunction lines —

body {
  --foo: #7f583f;
  --bar: #f7efd2;
}
Copy the code

The var() function is used to read variables.

a {
  color: var(--foo);
  text-decoration-color: var(--bar, #7f583f);
}
Copy the code

Why choose two conjunction lines (–) to represent variables? Because $is used by Sass and @ is used by Less. _, -, compatible with Internet Explorer and Chrome. There are no characters in CSS that can replace variable declarations. To avoid conflicts, the official CSS variables are replaced with two conjunction lines.

As an official standard specification, time to influence the development of the industry behind. It’s amazing to be swayed by a third party plugin. Some developers ridicule: Microsoft’s architect is also weak enough.

Many applications are abandoning Sass and less in favor of PostCSS. Component-oriented programming doesn’t use some of the complex features found in Sass and Less. Well, the two-character complexity will be a permanent pain for developers.

Class private attributes (proposal-class-fields)

The class in JavaScript is no stranger to everyone, and it is exactly the same as the Java class.

Basic usage:

class BaseClass {
  msg = 'hello world';

  basePublicMethod() {
    return this.msg; }}Copy the code

Inheritance:

class SubClass extends BaseClass {
  subPublicMethod() {
    return super.basePublicMethod(); }}Copy the code

Static properties:

class ClassWithStaticField {
  static baseStaticMethod() {
    return 'base static method output'; }}Copy the code

Asynchronous methods

class ClassWithFancyMethods {*generatorMethod() {}
  async asyncMethod() {}
  async *asyncGeneratorMethod(){}}Copy the code

The proposal for class private attributes, which prefixes a class’s attributes with the # keyword, is now standard.

class ClassWithPrivateField {
  #privateField;

  constructor() {
    this.#privateField = 42; }}Copy the code

You read that right, not the private keyword in typescript.

class BaseClass {
  readonly msg = 'hello world';

  private basePrivateMethod() {
    return this.msg; }}Copy the code

However, the grammatical ugliness of # itself has caused controversy in the community:

“The Class Fields proposal provides a highly controversial syntax for private field access — and manages to do the only thing right that has the community focused all the controversy on this syntax.”

The TS capitulationism has been forced into reality.

No dynamic access, no destructuring is a deal breaker for me

We made an ESLint plugin no-private-class-fields and used download counts to illustrate community objections

‘#’ as part of the name can cause confusion because this.#x! == this[‘#x’] too strange

Front-end architect and TC39 member Shijun He also wrote several articles on Zhihu poking fun at Class Fields

The private side: johnhax.net/2017/js-pri…

Proposal address: github.com/tc39/propos…

globalThis

Retrieving global objects in different JavaScript environments requires different statements. On the Web, global objects can be retrieved by window, self, but only self can be retrieved by Web Workers. In Node.js, you must use global. In non-strict mode, we can return this in a function to get the global object, otherwise undefined is returned

Hence a proposal called Global. The global variable was used to unify the behavior above, but was changed to globalThis in a roundabout way, causing a lot of discussion.

The globalThis name makes this even more complicated.

  1. thisHas always been a topic of frustration for programmers, especiallyJavaScriptNewbie, blog posts about it are endless
  2. ES6Makes things easier because you can tell people to prefer the arrow function and only use itthisInternal method definition
  3. In the modernJS (modules)In, there is no real big picturethis, soglobalThisThey don’t even refer to existing concepts

It’s all futile to say now that it’s stage 4

Proposal address: github.com/tc39/propos…

conclusion

There’s a lot of crap left over in JavaScript. Now many new proposals have had to be compromised under the influence of this dross. In the future, it will become extremely complicated.

Maybe someday, a subset of JavaScript with no historical baggage will come along to replace it.

Articles exported this year

I just started writing in the last two months. I hope I can help you, or I can join groups to learn and progress together.

  • How to write a more elegant React component
  • How to write a more elegant React component – code structure
  • 2021 year-end summary, an 8 – year – old front-end where to go
  • […undefined] what is the result of the implementation?
  • React Boutique component: Mac-ScrollBar
  • We migrated from UmiJS to Vite
  • Forget useCallback, we have a better way
  • How to write more elegant code – JavaScript text
  • React Hooks performance optimized for correct posture