• JavaScript is a fixed point

    Friday, October 11, 2013

    10/11/2013— Tim Ryan

    Since JavaScript was publicly announced in 1995, there have been an enormous amount of manhours put into retaining its backward compatibility. Barring some false starts (<layer>s and document.all are so fresh) your middle school GeoCities website from 1999 might even still run today.

    Lost in the noise of cross-browser compatibility is how significant this is to JavaScript’s history: since 1996, there have been at least two mainstream implementations of JavaScript. Of the top programming languages, many of those released in the mid-90’s didn’t start seeing multiple implementations until much later, and many stil only have one major distribution. (Python, Ruby, and especially Perl are much different today, with many exciting research and production VMs available)

    This approach to change shapes the community in interesting ways. The transition from Python 2 to 3 to usher radical changes in the language was designed to take five years, a change that took a lot of manpower from the community to make happen (including tons of massive codebases). This type of radical restructuring never worked with JS. Changes made in JavaScript 1.2 (1997) were undone once IE3 was released, so Netscape could retain compatibility. In the 2000’s, the major restructuring that was JavaScript 2.0 collapsed after failing to reach consensus (surprisingly spinning off ActionScript 2.0, Flash’s programming language, in the process).

    Since 2008, ECMAScript Harmony has been the new direction for JavaScript, and it takes the same path the web always has: incremental improvement. We’ll have yield operators and new collections in every engine rather soon, all without breaking legacy code.

    After announcing Tessel (our development board programmable in JavaScript), one of the biggest questions we’ve received is why we didn’t pick Python, a language that’s very popular in the OSHW community already. Our first motivation was more technical than ideological: Node’s package manager made it easy to install modules for a single project, and the majority of Node modules are written in JavaScript itself, rather than in C.

    In “The Future of Programming in Node.js”, Isaac places a strong emphasis on Node’s backward compatibility and how code written today should work years from now. At the same time, the V8 API changed significantly between Node 0.10 and 0.12, requiring changes to the binary API.

    We’re definitely paying attention to the questions of running other languages on Tessel, as well as supporting native modules. But for now (to steal from Jeff Atwood) we think any application that can be written in JavaScript, will continue to work. We’re pretty excited by the choice to use JavaScript at a low level, for devices that run today and those that need to run for the next ten years.

    —Tim Ryan

    #javascript #Tessel #programming #programming language #web development #web developers #oshw #tim ryan #python

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013