Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31110

Re: filter queryselectorall

Show all headers | View raw

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> [...]
>> Indeed, unless determining support is the goal, it is usually
>> better to “polyfill” and use the polyfill so that the polyfill can be
>> removed once all target environments support the native feature.  (This
>> recommendation does not apply to host objects.)
> 
> Assuming what you "polyfill" can be done 100% of course. If you can't, I'd
> point towards the decorator pattern instead.

ACK.
 
>> > I take the position that one should write in the latest standard
>> > version and compile to the lowest common denominator instead. Web
>> > Developers aren't quite there yet in their personal workflow though and
>> > many common libs may not be prepared properly for use (using global
>> > variables and fake namespaces vs. modules).
>> We have discussed this elsewhere and disagree about this.  I do not think
>> it is a good idea to use the latest/an extended version of a programming
>> language just for the sake of it.
> 
> "just for the sake of it"? I think there is something behind this you
> could expand on.

Because it’s “cool” to use it, not because there is considerable *tangible* 
benefit in using it.
 
> I never really understood the fascination with the word "transpiler" I see
> it as yet another buzzword like "polyfill" I wish didn't exist due to all
> the baggage associated.
> 
> I'd rather people kept with "compiler".

There is a difference.  “Transpiler” is in fact a not-so-new [1] portmanteau 
standing for “transcoding compiler” which in turn stands in for “translating 
source-to-source compiler”.  The difference is that a compiler usually does 
not generate source code, but *machine* code.
 
<https://en.wikipedia.org/wiki/Source-to-source_compiler>

[1] 
<https://www.google.com/search?q=transpiler&safe=active&source=lnt&tbs=cdr%3A1%2Ccd_min%3A01.01.1960%2Ccd_max%3A31.12.2000&tbm=>

(The Google Books Ngram Viewer at <https://books.google.com/ngrams> did not 
have “transpiler”, so I tried a time-based Google Search.)

> Which of these counts as "transpilation" vs. "compilation"?
> 
> ES6 -> ES6 (minified)

That does not count either as transpilation or compilation in my book 
because the underlying programming language stays the same.  Therefore the 
proper term is, obviously, “minification” or “minifying”, which I would 
categorize as a form of automated refactoring, and define as refactoring in 
order to generate equivalent source code that is as small as possible.

> ES6 -> ES5
> ES6 -> ES3

It is debatable whether that alone can be called transpilation because one 
could argue that the underlying programming language stays the same 
(ECMAScript), only that the resulting source code is executable by an 
implementation of an earlier specification of it.  However, usually the 
software that does this conversion does more than just that (I am thinking 
of the TypeScript compiler as an example).

> ES6 -> asm.js

Is there such a thing?  If yes, see above, as asm.js is “an extraordinarily 
optimizable, low-level subset of JavaScript”, according to its Web site, and 
“a strict subset of JavaScript” according to its Specification (August 
2014[!] Working Draft).

BTW, I recently noticed that the 7th Edition of the ECMAScript Language 
Specification, ECMAScript 2016, has been published in 2016-06.  The HTML 
version is available at <http://ecma-international.org/ecma-262/7.0/>.
It should be noted that

| [that] ECMAScript specification is the first ECMAScript edition released 
| under Ecma TC39's new yearly release cadence and open development process. 
| A plain-text source document was built from the ECMAScript 2015 source 
| document to serve as the base for further development entirely on GitHub. 
| Over the year of this standard's development, hundreds of pull requests 
| and issues were filed representing thousands of bug fixes, editorial fixes 
| and other improvements. Additionally, numerous software tools were 
| developed to aid in this effort including Ecmarkup, Ecmarkdown, and 
| Grammarkdown. This specification also includes support for a new 
| exponentiation operator and adds a new method to Array.prototype called 
| includes.

>> > I would rather defer to Array.from, but yes, if I wanted to
>> > micro-optize:
>> > 
>> > var filter = (xs,fn) => Array.prototype.filter.call(xs,fn)
>> 
>>   [For example, I found the advantage of that syntax over
>> 
>>     var filter = function (xs, fn) {
>>       return Array.prototype.filter.call(xs, fn);
>>     }
>> 
>>   to be negligibly small.  The latter is even clearer than the former: I
>>   do not have to look closely to know that .filter() is not .call()ed
>>   before the anonymous function is called.]
> 
> If you dislike it as being too terse, fair enough. I assume you know that
> the semantics of "function(){...this...}" differ from "() => {...this...}"

No, I was unaware that “this” would be the “undefined” value with the arrow 
function syntax with braces when the defined function is called.  I find it 
even more disturbing that “arguments” is not defined with either arrow 
function syntax.  (Tested in the Chrome DevTools console in Chromium 
“51.0.2704.79 Built on 8.4, running on Debian stretch/sid (64-bit)”.)
 
>> In any case, this is not a good idea because it requires resolution of
>> “Array.prototype.filter” along the scope chain every time the filter
>> function is called.  It is not micro-optimization, but *de*optimization.
> 
> Assuming the Tracing JIT doesn't do its job... [1]

That argument is based on wishful thinking.  There does not have to be a 
Tracing JIT in the first place.
 
>> […] Language binding was specified [in DOM Level 2 and 3 Core] so that
>> in certain programming languages features of the DOM were easier to use. 
>> For example, if “list” refers to an object implementing the NodeList
>> interface, you can write “list[1]” instead of “list.item(1)” in
>> ECMAScript implementations because the language binding section of the
>> DOM Specification says so.
>> […]
>> The aforementioned simplification is no longer specified by language
>> binding in DOM4 but simply as alternative syntax (with no reference to
>> “JavaScript” whatsoever).  (From this we can assume that inheritance
>> from Array.prototype was not possible if the DOM was to be kept
>> language-indepent.)
> 
> JavaScript isn't expressive enough (Yet?) to define the constraints and
> intent  properly anyway. (interfaces and such)

That depends on what you call “JavaScript”.  But from ECMAScript Edition 3 
on you can certainly implement interfaces in all ways that matter:

- You can define an interface as an object (of a user-defined type) that has
  certain no-op methods;

- You can define that a user-defined type implements an interface, meaning
  that its prototype must implement the methods of the interface that
  the type implements;

- you can subject an object to an interface test (it must inherit or 
  implement certain methods) and throw an exception if it does not pass
  that test.

It is possible to improve on that by defining an interface as an object that 
(additionally) has a description of required properties and property types 
as as properties, and work with that in the same way.  One can define 
setters and getters so that the initial type of a property is preserved, or 
one can use language extensions (e.g. for strict typing).

> Frankly, after 20 some odd years of me living/developing in this web
> world, I don't care too much anymore about the evolution of these standard
> bodies. The passion is gone and there's nothing new under the sun AFAIC.
> No more archaeology, and no more bazaars as far as I can manage. The
> cathedral is where I trek. [2][3]

That may be so, but you are missing the point: the problem is not with the 
standards bodies but intrinsic in the relevant, evolutionally grown APIs.  
It can only be solved satisfactorily by foregoing all attempts at 
compatibility (backwards *and* forwards), and that would be unwise at best.

Please trim your quotes from now on.  Also, you should not repeat the 
attribution lines in each section.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

filter queryselectorall Andrew Poulos <ap_prog@hotmail.com> - 2016-08-06 14:25 +1000
  Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-05 22:23 -0700
    Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-06 08:16 +0200
      Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-06 15:49 -0700
        Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 07:08 +0200
          Re: filter queryselectorall Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-08-07 07:17 +0200
            Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 07:58 +0200
          Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-07 10:30 -0700
            Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 21:16 +0200
              Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-09 21:18 -0700
                Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-15 22:02 +0200
                Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-15 23:16 -0700
  Re: filter queryselectorall "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-08-06 10:28 +0200

csiph-web