• Time: 2020-05-18
  • Categories: Web

Original text: davidflanagan.com/2020/05/12/…

By David Flanagan

The first demo version of JavaScript was created almost 25 years ago.

If MEMORY serves, 25 years ago today, Wednesday, May 10, 1995, I was just halfway through my “10 Days in May” sprint to create JavaScript (codenamed “Mocha”). I’m working on a demo that will be delivered next Monday to show deep browser integration of JS with Netscape (as opposed to Java applets).

In the fall of 1995, the language was released as LiveScript in a test version of Netscape Navigator. By the end of that year, the name was changed to JavaScript. Also in that year, David Flanagan began writing The first edition of JavaScript: The Definitive Guide, which WAS published by O’Reilly in August 1996. Now, 24 years later.

The seventh edition of the Rhino Book will be out in a few weeks. To that end, David takes a look back and tells you what JavaScript features you can safely forget. One reason is that the seventh edition is much thinner than the sixth. And that’s mainly because there’s a lot of stuff that 2020 developers don’t care about anymore. Web compatibility will always be here (it has been for at least 25 years), and browser vendors may still need to support old, hard-to-understand languages and platform features for a long time. But for us, there’s no need to be distracted by these features anymore.

That said, a number of JavaScript and Web platform features are dead in release 7. Suffice it to say, it’s nice to say goodbye to these features. Here are David’s list of features to forget from memory.

  • argumentsThe object has been created by ES6. argsGrammar completely supersedes. To explainargumentsThe relationship to named parameters, and the constant attention to its impact on performance, is not easy. You may still see it in legacy front-end code. In strict mode, if you want to name local variables or function arguments asargumentsThe browser will also alert you to its presence. But now that there are residual parameters, it should be quietly forgotten.
  • There was a time when we worried about performance issues caused by repeated concatenation of strings. For a while, everyone learned to push strings into arrays first and use them lastjoin()Let’s put them together. Later, JavaScript got faster and we forgot about this pattern. Now that you have template literals, who wants to concatenate strings?
  • document.write()It used to be the most important feature in JavaScript long ago, before DOM, to be exact. (If you didn’t write JavaScript in the 20th century, you can’t imagine the pre-DOM days, but they really existed.) If memory serves, people can even use itdocument.write()Insert the script into the document. Be careful, though, because you have to put the end</script>The label is split into two strings. This way the HTML parser won’t interpret it as the end tag of the currently running script.
  • Not in the early days of HTML<iframe>Yes, but there is<frameset>and<frame>.window.framesProperty is an array containing nestedwindowObject that represents a pane in a document. In fact, you can call the document’s in the paneopen()Method, and then usedocument.write()The entire document is dynamically generated in this pane. Anyway, it’s kind of cool. Because panes can be nested within other panes, eachwindowObjects all have oneframesThe array contains its own child panes, oneparentThe property reference contains the window and onetopProperty references the top-level window. Early editions of the Rhino book devoted several sections and complex illustrations to explaining these.
  • The technique of referring directly to specific elements in a document is largely obsolete. I mentioned earlierframesThe array is one, if I remember correctly, andlinksandimagesArray that contains all the links and all the images in the document. IE (version 4, I think) came in one step and introduced itdocument.all, which is an array containing all the elements in the document. (This was also the origin of “DHTML,” or dynamic HTML, and later DOM, a bit like the first fish on land in human evolution.)document.allWith all sorts of fancy features, the array itself has many methods for querying elements by name or by other criteria.document.allIt didn’t end up in the standard, but even if it was standarddocument.getElementById(),document.getElementsByName(),document.getElementsByTagName()anddocuemnt.getElementsByClassName()The method, in today’s view seems to have not many people use. Because of the jQueryThe $()And those inspired by it to introduce standardsdocument.querySelector()anddocument.querySelectorAll()The crowd out. Using the power of CSS selectors, these two methods simply nullify the previous ones.
  • One of the things I hate most about Internet Explorer is that they insist on using itattachEvent()To register the event handler. In my impression, they are already stipulated in the standardsaddEventListener()After the method, this is really disgusting. Events and their handlers have long been one of the biggest incompatibilities in Web development. For years, JavaScript programmers (and JavaScript book authors) have had to deal with various differences between the IE event model and the standard event model. To do this, the code to handle the event must be written twice, once for IE and once for Firefox. The chapter on events is correspondingly twice as long, because there are two very similar but completely incompatible event handling mechanisms. One of the main features of jQuery is that it implements its own event compatibility layer, so you only need to master one way to handle events. I suspect this is also a big reason for its rapid popularity.
  • The original DOM API was defined in the days of XML mania. (At the time, people really believed that within a few years, XML would solve all data problems. It’s an incredible time. In part, it was the W3C’s endorsement that led to the DOM API being influenced by those in Java who felt it was best to define a single API that JavaScript programmers could use to manipulate HTML documents and Java programmers could use to manipulate XML data. This is why there is such a weird thing as an Attr node (preferably if it doesn’t exist). One of the biggest things I didn’t understand in the DOM Level 3 API was removing element E from the document. Instead of writing it as e.emove (), as you do today, you had to write it as e.parentNode.removechild (e).

Anyway, it’s 2020. The seventh edition of the Rhinoceros book will not be devoted to describing these antiquated traits, which are best forgotten.