milesrout · January 24, 2017 00:20
diff --git a/Russell Stuart b/Russell Stuart
    I was proudly shown some production "web code" yesterday.  Cutting 
    edge stuff, apparently.  A single file contained HTML, css, and JS.
 
    The first thing that hit me is JS didn't contain any semicolon's - 
    something I found disquieting.  I was told "no, we don't use them 
    any more".  But what about the problems with that pointed out by 
    "Javascript - The Good Parts", I asked.  The reply was, "oh, no 
    one does this stuff without running it through an aggressive 
    linter, so its completely safe - mostly strictly type safe in 
    fact".  (That was nice - evidently at least some of the scars
    carried by the C using forbears had been noticed.)

    But how could a linter process that, I asked - it was some  unholy 
    mess of 3(? maybe more) intermixed languages.  It gently explained 
    this was the source code form.  A large tool chain would digest 
    it, turning it into something no sane human would look at.  It was 
    broken into single language modules that were digestible by a 
    browser, downloaded by some dynamic linker created by the tool 
    chain that GET's the requisite parts as the running code links to 
    it while executing.  It was complete with debugging symbols packed 
    into separate files, so they were there if needed.  From the 1000' 
    view it was not unlike the m4 / cpp / gcc / ld / ldd GNU tool 
    chain - but created in some parallel universe.

    Then I noticed some JS/Typescript/? syntax I hadn't seen before.  
    Not wanting to let any more grey show through I decided to chase 
    it down myself.  It took a while - it was some variant of the 
    new JS spreader syntax - but it wasn't in ECMAScript 2015 and 
    wasn't recognised by any shipping browser.  I knew this new 
    generation of our profession didn't share my aversion to 
    releasing production code developed in a language that hasn't been 
    standardised yet - but it wasn't in ECMAScript 2017 either.  
    Turned out it was a proposed addition to ECMAScript 2017 
    implemented by a grand total of 2 transpilers.  In production 
    code!  (The mere existence of those bloody transpilers makes the 
    statement "written in Javascript" near inscrutable.)
	I was proudly shown some production "web code" yesterday. Cutting
	edge stuff, apparently. A single file contained HTML, css, and JS.

	The first thing that hit me is JS didn't contain any semicolon's -
	something I found disquieting. I was told "no, we don't use them
	any more". But what about the problems with that pointed out by
	"Javascript - The Good Parts", I asked. The reply was, "oh, no
	one does this stuff without running it through an aggressive
	linter, so its completely safe - mostly strictly type safe in
	fact". (That was nice - evidently at least some of the scars
	carried by the C using forbears had been noticed.)

	But how could a linter process that, I asked - it was some unholy
	mess of 3(? maybe more) intermixed languages. It gently explained
	this was the source code form. A large tool chain would digest
	it, turning it into something no sane human would look at. It was
	broken into single language modules that were digestible by a
	browser, downloaded by some dynamic linker created by the tool
	chain that GET's the requisite parts as the running code links to
	it while executing. It was complete with debugging symbols packed
	into separate files, so they were there if needed. From the 1000'
	view it was not unlike the m4 / cpp / gcc / ld / ldd GNU tool
	chain - but created in some parallel universe.

	Then I noticed some JS/Typescript/? syntax I hadn't seen before.
	Not wanting to let any more grey show through I decided to chase
	it down myself. It took a while - it was some variant of the
	new JS spreader syntax - but it wasn't in ECMAScript 2015 and
	wasn't recognised by any shipping browser. I knew this new
	generation of our profession didn't share my aversion to
	releasing production code developed in a language that hasn't been
	standardised yet - but it wasn't in ECMAScript 2017 either.
	Turned out it was a proposed addition to ECMAScript 2017
	implemented by a grand total of 2 transpilers. In production
	code! (The mere existence of those bloody transpilers makes the
	statement "written in Javascript" near inscrutable.)