A brief history of javascript. Part 2
Continuing to translate the article A Brief History of JavaScript , prepared by the Front Types front-end development department. The first part ended with the fact that in November 1996, the JavaScript language began to lead to ECMA standards. Since then, the language passes on the papers as ECMAScript, but in everyday life everyone calls it still. Read in the second part: ECMAScript version, the emergence of AJAX technology, ActionScript and its impact on Flash and the path to Harmony.
A brief history of javascript. Part 1
The first ECMAScript standard was based on the JavaScript version that was included in Netscape Navigator 4 and did not include important features such as regular expressions, JSON, exceptions, and important methods for embedded objects. However, it worked much better in the browser. Version 1 was released in June 1997.
')
Please note that our simple prototype and function test works correctly. Netscape 4 did a great job, and JavaScript got its benefit. Our example works exactly the same as it will work in any modern browser. This is a very important achievement for the first version of the standard.
The second version, ECMAScript 2, was released in June 1998 to correct inconsistencies between ECMA and the ISO standard for JavaScript (ISO / IEC 16262) and did not include any changes to the language itself.
An interesting feature of this version of JavaScript was that the interpreter had to decide for itself what to do with unrecognized errors (and in most cases left as unclassified). The reason for this was that exceptions were not yet part of the language at that time.
After ECMAScript 2, work continued and the first big language changes were released. The new version included:
ECMAScript 3 was released in December 1999.
This version of ECMAScript is very widespread. All the major browsers of the time supported it and continued to support it for many years. Even today, many transpilers may specify this standard as an output language. This made ECMAScript 3 a foundation for many libraries, even when later versions of the standard were released.
Although JavaScript was used almost everywhere, it was still a client-side programming language. Many of his innovations allowed him to move closer to escaping from this cell.
Netscape Navigator 6, released in November 2000, supported ECMAScript 3. Almost a year and a half later, Firefox, a browser based on the Netscape Navigator code base and also supporting ECMAScript 3, was released. Side by side with Internet Explorer, these browsers did everything possible to further grow and the development of javascript.
AJAX (asynchronous JavaScript and XML) is a technology that was born in ECMAScript 3 years. Although it was not part of the standard, Microsoft built in some JavaScript extensions in Internet Explorer 5. One such extension was the XMLHttpRequest function as an ActiveX control XMLHTTP . This feature allowed the browser to perform asynchronous HTTP requests to the server, thereby allowing pages to be updated on the fly. Although the AJAX name itself was coined much later, the technique itself was actively used at that time.
The use of XMLHttpRequest was successful, and years later was standardized by the WHATWG and W3C groups.
The constant evolution of functionality, developers who contribute something new to the language and embed these innovations in their browsers, are still fundamental factors in the development of JavaScript and related standards such as CSS and HTML. Communication between individual groups in those days was very weak, leading to delays and fragmentation. Frankly, JavaScript development is much better organized these days, thanks to procedures that allow interested groups to make suggestions.
This version supports exceptions - the main feature, without which all previous versions suffered, which is clearly seen when trying to open Google. Incredibly, even today, Google, open in this version, is a readable working page. For contrast, we tried to open Google using Netscape Navigator 4 and received incomplete rendering and go markup. Even in those days, the web developed rapidly.
Internet Explorer 5 also handled the modern version of Google. However, there are a number of known differences in terms of the implementation of certain features between Internet Explorer and other browsers . These differences have been a real disease for many years, bringing web developers to white-hot, as they had to modify the code every time specifically for Internet Explorer users.
For example, to get access to the XMLHttpRequest object in Internet Explorer 5 and 6, you had to access ActiveX. At the same time, other browsers handled it as a native object.
Undoubtedly, the very idea of ​​using this object appeared in Internet Explorer 5. However, only in Internet Explorer 7 did Microsoft begin to follow the standards. Some legacy sites still require older versions of Internet Explorer to work properly.
Unfortunately, the next few years did not bring JavaScript any good. Together with the beginning of work on ECMAScript 4 in the community, divided into groups, disagreements began. One group argued that JavaScript needs to be made the language for developing large applications. This group offered many new large volume options that required major changes. Another group found a similar development vector unacceptable. The lack of compromise and the complexity of some of the proposed improvements pushed the exit of ECMAScript 4 farther and farther.
Work on ECMAScript 4 began soon after the release of the third version in 1999. A large number of interesting innovations were discussed in Netscape. However, interest in them eventually dried up, and in 2003, work on a new version of ECMAScript stopped. An interim report was released, and some developers, such as Adobe (ActionScript) and Microsoft (JScript.NET) used it as the basis for their own engines. In 2005, AJAX and XMLHttpRequest were able to rekindle interest in the new version of JavaScript and TC-39 resumed work. Years passed and a set of innovations grew more and more. In the midst of its development, ECMAScript 4 included such options as:
ECMAScript 4 project documentation describes this version as intended for large programming. If you are familiar with ECMAScript 6/2015, you may notice that it embodies many of the features listed above.
This table can serve as an interesting addition to the story. It displays the status of various add-ons and discussion groups involved in the development.
The committee that developed ECMAScript 4 included Adobe, Mozilla, Opera (unofficially) and Microsoft. Yahoo entered the game when most decisions on standards and capabilities were already made, sending Douglas Crockford, an influential JavaScript developer who immediately criticized most of the innovations, receiving strong support from a Microsoft representative.
What started out as doubts quickly grew into a strong opposition to JavaScript. Microsoft flatly refused to approve any part of ECMAScript 4 and was ready for any action, including litigation, to prevent the standard from being approved. Fortunately, the committee members were able to avoid litigation. However, due to disagreements, ECMASCript 4 continued to stagnate.
Crockford came up with the idea of ​​creating a simpler, smaller set of options for a new standard, one that everyone could agree with: no new syntax, only practical improvements based on the experience of using the language. The result of this proposal was a standard known as ECMAScript 3.1.
As a result, the simultaneous work on two standards began, for which two informal committees were created. ECMAScript 4 was still too complicated, the debate around it did not subside, and it was not possible to finish it in the near future. ECMAScript 3.1 was much simpler and, despite the differences in ECMA, the work on it was successfully completed.
The final point in ECMAScript 4 was set in 2008, in Ike's e-mail in which he summarized the meeting in Oslo, where the future of ECMAScript and the future of versions 3.1 and 4 were discussed.
Decisions made at this meeting:
As a result, it took almost eight years to complete the development of ECMAScript 4. A hard lesson for all who participated.
The word "Harmony", which appeared in the listed solutions, became the name of the project in future versions. Harmony will be an alternative with which everyone will agree. After the release of ECMAScript 3.1 (as version 5, as discussed below), ECMAScript Harmony has become the place where all new ideas about JavaScript are discussed.
ActionScript became a programming language based on an earlier version of ECMAScript 4. Adobe included it in the Flash development toolkit, and it was the only scripting language supported by this package. Thanks to this language, Adobe has expressed its position on ECMAScript 4, subsequently releasing its open-source version (Tamarin) in the hope of speeding up the development of ECMAScript 4. Mike Chambers, an Adobe employee, expressed his position on this:
The developers of ActionScript hoped that the innovations used in this language would later become part of ECMAScript. Unfortunately, no one paid any attention to them and ECMAScript 2015 was mostly incompatible with ActionScript.
Some considered this move to be Microsoft’s attempt to retain control of the language and its implementations. The only viable ECMAScript 4 engine at that time was Tamarin, so Microsoft, which occupied 80% of the Internet browser market, could continue to use its own engine without having to spend an expensive adaptation to the new standard or use a competitor engine . Someone thought that Microsoft’s objections were purely technical, like Yahoo’s. Microsoft's JScript engine, at that time, had a lot of differences from other implementations .
ActionScript to this day remains the language for Flash, which began to lose popularity due to the arrival of HTML5.
ActionScript remains a prime example of what ECMAScript 4 could look like if it were implemented in popular JavaScript engines:
E4X is the name that received the ECMAScript extension, released in the years that ECMAScript 4 was developed (2004). This name, standardized in ECMA-357, stands for ECMAScript for XML. E4X has added support for and displaying XML content in ECMAScript. In E4X, XML is treated as a primitive data type. At first, E4X received support from large engines, such as SpiderMonkey, but was then abandoned due to its low popularity and removed from 21 versions of Firefox.
In addition to the number 4 in the title, the E4X has absolutely nothing to do with ECMAScript 4.
A small example of using E4X:
Other data formats, such as JSON, were much more popular in the JavaScript community, so E4X appeared and disappeared, leaving almost no trace.
In 2008, after long fights around ECMAScript 4, the community focused on working on ECMAScript 3.1, sending ECMAScript 4 to a landfill. In 2009, ECMAScript 3.1 was fully completed and approved by all committee members. Since ECMAScript 4 was considered a kind of ECMAScript despite the absence of at least any release, it was decided to rename ECMAScript 3.1 to ECMAScript 5 to avoid misunderstandings.
ECMAScript 5 has become one of the most supported versions of JavaScript, also becoming the goal of compiling many transpilers. ECMAScript 5 received full support in browsers Firefox 4 (2011), Chrome 19 (2012), Safari 6 (2012), Opera 12.10 (2012) and Internet Explorer 10 (2012).
ECMAScript 5 was a fairly modest improvement to ECMAScript 3, which included:
None of these changes required syntax changes. Getters and setters were already unofficially supported by some browsers at that time. New methods of objects should have improved large programming, giving programmers more tools to verify compliance with certain invariants (Object.seal, Object.freeze, Object.createProperty). Strict mode has also become a powerful tool in this area, making it possible to avoid a large number of errors. Additional array methods have improved certain functional patterns (map, reduce, filter, every, some. Another great innovation is JSON: a JavaScript-based data format that is now natively supported thanks to JSON.stringify and JSON.parse. Other changes are minor improvements. based on practical experience. In general, ECMAScript 5 was a slight improvement that joused JavaScript in terms of usability for both small scripts and more voluminous projects. However, a large number of good ideas were proposed for ECMAS The cript 4 was never implemented and was waiting for its return to ECMAScript Harmony.
ECMAScript 5 received an update in 2011 called ECMAScript 5.1. This release clarified some ambiguous points of the standard, but there were no new features in it. All new features were planned for the next big release of ECMAScript.
A brief history of javascript. Part 3
A brief history of javascript. Part 1
ECMAScript 1 and 2: Towards Standardization
The first ECMAScript standard was based on the JavaScript version that was included in Netscape Navigator 4 and did not include important features such as regular expressions, JSON, exceptions, and important methods for embedded objects. However, it worked much better in the browser. Version 1 was released in June 1997.
')
Please note that our simple prototype and function test works correctly. Netscape 4 did a great job, and JavaScript got its benefit. Our example works exactly the same as it will work in any modern browser. This is a very important achievement for the first version of the standard.
The second version, ECMAScript 2, was released in June 1998 to correct inconsistencies between ECMA and the ISO standard for JavaScript (ISO / IEC 16262) and did not include any changes to the language itself.
An interesting feature of this version of JavaScript was that the interpreter had to decide for itself what to do with unrecognized errors (and in most cases left as unclassified). The reason for this was that exceptions were not yet part of the language at that time.
ECMAScript 3: The First Big Changes
After ECMAScript 2, work continued and the first big language changes were released. The new version included:
- Regular expressions
- Do-while block
- Exceptions and try / catch blocks
- More built-in functions for strings and arrays
- Formatting Numerical Output
- In and instanceof statements
- Improved error handling
ECMAScript 3 was released in December 1999.
This version of ECMAScript is very widespread. All the major browsers of the time supported it and continued to support it for many years. Even today, many transpilers may specify this standard as an output language. This made ECMAScript 3 a foundation for many libraries, even when later versions of the standard were released.
Although JavaScript was used almost everywhere, it was still a client-side programming language. Many of his innovations allowed him to move closer to escaping from this cell.
Netscape Navigator 6, released in November 2000, supported ECMAScript 3. Almost a year and a half later, Firefox, a browser based on the Netscape Navigator code base and also supporting ECMAScript 3, was released. Side by side with Internet Explorer, these browsers did everything possible to further grow and the development of javascript.
AJAX Birth
AJAX (asynchronous JavaScript and XML) is a technology that was born in ECMAScript 3 years. Although it was not part of the standard, Microsoft built in some JavaScript extensions in Internet Explorer 5. One such extension was the XMLHttpRequest function as an ActiveX control XMLHTTP . This feature allowed the browser to perform asynchronous HTTP requests to the server, thereby allowing pages to be updated on the fly. Although the AJAX name itself was coined much later, the technique itself was actively used at that time.
The term AJAX was first used by Jesse James Garrett in his article .
The use of XMLHttpRequest was successful, and years later was standardized by the WHATWG and W3C groups.
The constant evolution of functionality, developers who contribute something new to the language and embed these innovations in their browsers, are still fundamental factors in the development of JavaScript and related standards such as CSS and HTML. Communication between individual groups in those days was very weak, leading to delays and fragmentation. Frankly, JavaScript development is much better organized these days, thanks to procedures that allow interested groups to make suggestions.
Games with Netscape Navigator 6
This version supports exceptions - the main feature, without which all previous versions suffered, which is clearly seen when trying to open Google. Incredibly, even today, Google, open in this version, is a readable working page. For contrast, we tried to open Google using Netscape Navigator 4 and received incomplete rendering and go markup. Even in those days, the web developed rapidly.
Games with Internet Explorer 5
Internet Explorer 5 also handled the modern version of Google. However, there are a number of known differences in terms of the implementation of certain features between Internet Explorer and other browsers . These differences have been a real disease for many years, bringing web developers to white-hot, as they had to modify the code every time specifically for Internet Explorer users.
For example, to get access to the XMLHttpRequest object in Internet Explorer 5 and 6, you had to access ActiveX. At the same time, other browsers handled it as a native object.
var xhr = new ActiveXObject("Microsoft.XMLHTTP"); Undoubtedly, the very idea of ​​using this object appeared in Internet Explorer 5. However, only in Internet Explorer 7 did Microsoft begin to follow the standards. Some legacy sites still require older versions of Internet Explorer to work properly.
ECMAScript 3.1 and 4: years of struggle
Unfortunately, the next few years did not bring JavaScript any good. Together with the beginning of work on ECMAScript 4 in the community, divided into groups, disagreements began. One group argued that JavaScript needs to be made the language for developing large applications. This group offered many new large volume options that required major changes. Another group found a similar development vector unacceptable. The lack of compromise and the complexity of some of the proposed improvements pushed the exit of ECMAScript 4 farther and farther.
Work on ECMAScript 4 began soon after the release of the third version in 1999. A large number of interesting innovations were discussed in Netscape. However, interest in them eventually dried up, and in 2003, work on a new version of ECMAScript stopped. An interim report was released, and some developers, such as Adobe (ActionScript) and Microsoft (JScript.NET) used it as the basis for their own engines. In 2005, AJAX and XMLHttpRequest were able to rekindle interest in the new version of JavaScript and TC-39 resumed work. Years passed and a set of innovations grew more and more. In the midst of its development, ECMAScript 4 included such options as:
- Classes
- Interfaces
- Namespaces
- Packages
- Optional type annotations
- Optional static type checking
- Structural types
- Type declarations
- Multimethods
- Parameterized Types
- Tail recursions
- Iterators
- Generators
- Introspection
- Parsing the type for exception handlers
- Constant binding
- Correct overview of blocks
- Destructuring
- Compressed functional expressions
- Array support
ECMAScript 4 project documentation describes this version as intended for large programming. If you are familiar with ECMAScript 6/2015, you may notice that it embodies many of the features listed above.
Despite the flexibility and apparent power, in practice ES3 is completely unsuitable for the development of large-scale programs. Programs written in ECMAScript become larger and more complex through the use of Ajax and the widespread use of ECMAScript in applications as a scripting language. Development of large programs can significantly benefit from such innovations as static type checking, hiding names, early bundle and other optimization techniques that are missing in ES3. - ECMAScript 4 draft
This table can serve as an interesting addition to the story. It displays the status of various add-ons and discussion groups involved in the development.
The committee that developed ECMAScript 4 included Adobe, Mozilla, Opera (unofficially) and Microsoft. Yahoo entered the game when most decisions on standards and capabilities were already made, sending Douglas Crockford, an influential JavaScript developer who immediately criticized most of the innovations, receiving strong support from a Microsoft representative.
It turned out that the representative of Microsoft had exactly the same doubts - he also believed that the language was getting too big and getting out of control. He did not say anything before my joining the group, as he was afraid that if Microsoft tried to express this point of view, she would be accused of anti-competitive behavior. Considering Microsoft’s behavior in the past, it can be said that he had reasons to fear, and as it turned out, not groundless. However, I convinced him that Microsoft should do the right thing, and he, in turn, was able to convince Microsoft to change his position regarding ES4.- Douglas Crockford - The State and Future of JavaScript
What started out as doubts quickly grew into a strong opposition to JavaScript. Microsoft flatly refused to approve any part of ECMAScript 4 and was ready for any action, including litigation, to prevent the standard from being approved. Fortunately, the committee members were able to avoid litigation. However, due to disagreements, ECMASCript 4 continued to stagnate.
Microsoft wanted to play big. People at Microsoft were going to overwhelm the committee with paperwork and start filing complaints to various authorities. I did not want anything like that. My differences with ES4 were purely technical, and I wanted them to remain so. I wanted to figure out how to do everything right, so I tried to reduce stress. Nevertheless, Microsoft took an uncompromising position, flatly refusing to take any part of ES4, because of which the committee split into two camps. Although it seems to me personally that this happened because the ES4 team did not want to consider alternative points of view. At that moment, the committee was torn apart by contradictions, and this was very bad, since the standards group must be in a state of complete agreement. Standards should not be inconsistent. - Douglas Crockford. - The State and Future of JavaScript
Crockford came up with the idea of ​​creating a simpler, smaller set of options for a new standard, one that everyone could agree with: no new syntax, only practical improvements based on the experience of using the language. The result of this proposal was a standard known as ECMAScript 3.1.
As a result, the simultaneous work on two standards began, for which two informal committees were created. ECMAScript 4 was still too complicated, the debate around it did not subside, and it was not possible to finish it in the near future. ECMAScript 3.1 was much simpler and, despite the differences in ECMA, the work on it was successfully completed.
The final point in ECMAScript 4 was set in 2008, in Ike's e-mail in which he summarized the meeting in Oslo, where the future of ECMAScript and the future of versions 3.1 and 4 were discussed.
Decisions made at this meeting:
- focus on working on ES3.1 with the full cooperation of all participants and release two compatible versions early next year;
- start work on the next step after ES3.1, which will include syntactic extensions, but more modest than those proposed for ES4 both in terms of semantic and syntactic innovations;
- for the common good, it was decided to abandon some of the ES4 offerings: packages, namespaces, and early bundles. They were considered useless for the web. This decision is the key to Harmony;
- Other ideas and goals of ES4 were rephrased in order to reach consensus within the committee, for example, the concept of classes based on existing ES3 concepts, combined with the proposed improvements of ES3.1.
As a result, it took almost eight years to complete the development of ECMAScript 4. A hard lesson for all who participated.
The word "Harmony", which appeared in the listed solutions, became the name of the project in future versions. Harmony will be an alternative with which everyone will agree. After the release of ECMAScript 3.1 (as version 5, as discussed below), ECMAScript Harmony has become the place where all new ideas about JavaScript are discussed.
ActionScript
ActionScript became a programming language based on an earlier version of ECMAScript 4. Adobe included it in the Flash development toolkit, and it was the only scripting language supported by this package. Thanks to this language, Adobe has expressed its position on ECMAScript 4, subsequently releasing its open-source version (Tamarin) in the hope of speeding up the development of ECMAScript 4. Mike Chambers, an Adobe employee, expressed his position on this:
ActionScript 3 will not go anywhere, and we will not remove anything from it. We will continue to follow the development of ECMAScript, doing everything possible for the further development of the Internet, as before. - Mike Chamber's blog
The developers of ActionScript hoped that the innovations used in this language would later become part of ECMAScript. Unfortunately, no one paid any attention to them and ECMAScript 2015 was mostly incompatible with ActionScript.
Some considered this move to be Microsoft’s attempt to retain control of the language and its implementations. The only viable ECMAScript 4 engine at that time was Tamarin, so Microsoft, which occupied 80% of the Internet browser market, could continue to use its own engine without having to spend an expensive adaptation to the new standard or use a competitor engine . Someone thought that Microsoft’s objections were purely technical, like Yahoo’s. Microsoft's JScript engine, at that time, had a lot of differences from other implementations .
ActionScript to this day remains the language for Flash, which began to lose popularity due to the arrival of HTML5.
ActionScript remains a prime example of what ECMAScript 4 could look like if it were implemented in popular JavaScript engines:
package { import flash.display.Sprite; public class MyRectangle_v3 extends Sprite { private var _outlineWeight:Number; private var _color:uint; private var _xLocation:int; private var _yLocation:int; private var _rectangleWidth:int; private var _rectangleHeight:int; public function MyRectangle_v3(outlineWeight:Number, color:uint, xLocation:int, yLocation:int, rectangleWidth:int, rectangleHeight:int) { _outlineWeight = outlineWeight; _color = color; _xLocation = xLocation; _yLocation = yLocation; _rectangleWidth = rectangleWidth; _rectangleHeight = rectangleHeight; } public function draw():void{ graphics.lineStyle(_outlineWeight); graphics.beginFill(_color); graphics.drawRect(_xLocation, _yLocation, _rectangleWidth, _rectangleHeight); graphics.endFill(); } } } What is E4X?
E4X is the name that received the ECMAScript extension, released in the years that ECMAScript 4 was developed (2004). This name, standardized in ECMA-357, stands for ECMAScript for XML. E4X has added support for and displaying XML content in ECMAScript. In E4X, XML is treated as a primitive data type. At first, E4X received support from large engines, such as SpiderMonkey, but was then abandoned due to its low popularity and removed from 21 versions of Firefox.
In addition to the number 4 in the title, the E4X has absolutely nothing to do with ECMAScript 4.
A small example of using E4X:
var sales = <sales vendor="John"> <item type="peas" price="4" quantity="6"/> <item type="carrot" price="3" quantity="10"/> <item type="chips" price="5" quantity="3"/> </sales>; alert( sales.item.(@type == "carrot").@quantity ); alert( sales.@vendor ); for each( var price in sales..@price ) { alert( price ); } delete sales.item[0]; sales.item += <item type="oranges" price="4"/>; sales.item.(@type == "oranges").@quantity = 4; Other data formats, such as JSON, were much more popular in the JavaScript community, so E4X appeared and disappeared, leaving almost no trace.
ECMAScript 5: JavaScript rebirth.
In 2008, after long fights around ECMAScript 4, the community focused on working on ECMAScript 3.1, sending ECMAScript 4 to a landfill. In 2009, ECMAScript 3.1 was fully completed and approved by all committee members. Since ECMAScript 4 was considered a kind of ECMAScript despite the absence of at least any release, it was decided to rename ECMAScript 3.1 to ECMAScript 5 to avoid misunderstandings.
ECMAScript 5 has become one of the most supported versions of JavaScript, also becoming the goal of compiling many transpilers. ECMAScript 5 received full support in browsers Firefox 4 (2011), Chrome 19 (2012), Safari 6 (2012), Opera 12.10 (2012) and Internet Explorer 10 (2012).
ECMAScript 5 was a fairly modest improvement to ECMAScript 3, which included:
- Getters / Setters
- Comma delimiters in arrays and objects
- Ability to use reserved words as object properties
- New object methods (create, defineProperty, keys, seal, freeze, getOwnPropertyNames, etc.)
- New array methods (isArray, indexOf, every, some, map, filter, reduce, etc.)
- String.prototype.trim and access to properties
- New Date methods (toISOString, now, toJSON)
- Function binding
- Json
- Unchangeable global objects (undefined, NaN, Infinity)
- Strict regime
- Other minor changes (parseInt ignores leading zeros, functions in throw have a value, etc.)
None of these changes required syntax changes. Getters and setters were already unofficially supported by some browsers at that time. New methods of objects should have improved large programming, giving programmers more tools to verify compliance with certain invariants (Object.seal, Object.freeze, Object.createProperty). Strict mode has also become a powerful tool in this area, making it possible to avoid a large number of errors. Additional array methods have improved certain functional patterns (map, reduce, filter, every, some. Another great innovation is JSON: a JavaScript-based data format that is now natively supported thanks to JSON.stringify and JSON.parse. Other changes are minor improvements. based on practical experience. In general, ECMAScript 5 was a slight improvement that joused JavaScript in terms of usability for both small scripts and more voluminous projects. However, a large number of good ideas were proposed for ECMAS The cript 4 was never implemented and was waiting for its return to ECMAScript Harmony.
ECMAScript 5 received an update in 2011 called ECMAScript 5.1. This release clarified some ambiguous points of the standard, but there were no new features in it. All new features were planned for the next big release of ECMAScript.
A brief history of javascript. Part 3
Source: https://habr.com/ru/post/324506/
All Articles