are there metrics on how es6 and future proposals affect javascript load-time for webpages?

and should future proposals take load-time performance into account? hi, i’m a new subscriber, and apologies if this seems like a newbie question. a bit of trivia - i remember long ago (maybe 2010?) a website called “great computer language shootout” or something had d8 consistently having the f

Re: Allowing object field name shorthand

-1 this is a terrible idea in terms of debugging and code-maintennance. when debugging someone else's unfamiliar code, i now have to add an extra-check for quotes around the key. On Jun 23, 2017 1:36 AM, "T.J. Crowder" wrote: > If you know it's already valid syntax, then why suggest it mean some

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

owsers in the first place. > > Aside from that, a great deal of "load time" (?) will likely consist of the > time needed to parse the source code. Anything else is mostly implementation- > specific and thus varies from engine to engine. > > Could you state your question more prec

Re: Pattern matching?

-1. will pattern matching code written by the vast number of beginner javascript programmers be readable/maintainable? i personally think not. yet another duplicative feature (that can probably be done more maintainably by switch statements or the all-powerful String.prototype.replace) to further

Re: Syntax for non-writability and non-configurability

-1 as far as i'm concerned, const is a wart with surprising behavior that should have never been introduced. best leave the wart as is rather than add more surprises. On Jul 8, 2017 3:09 PM, "Raul-Sebastian Mihăilă" wrote: > I'd like to propose the following syntax: > > ```js > const obj = { >

Re: Syntax for non-writability and non-configurability

legitimate Object.defineProperties use-case is low and obscure enough it can stay verbose. most of the time it causes more code-maintainability issues / tech-debt than it solves. On Jul 8, 2017 7:51 PM, "T.J. Crowder" wrote: > On Sat, Jul 8, 2017 at 8:09 AM, Raul-Sebastian Mihăilă < > raul.miha.

Re: JSON5

any significant degradation in json parsing-performance would impact the world wide web. can anyone knowledgeable on js engines comment on parsing performance? On Jul 11, 2017 15:39, "Dong Nguyen" wrote: > @Jordan: I think that's just work-around, not official feature. > > Dong > > On Tue, Jul 1

Re: Functional Operators

-1 i can see this becoming a debugging nightmare in math libraries where its confused with arithmetic expressions. yet-another-alien-syntax to remember when debugging other people's code. On Jul 11, 2017 03:35, "Vihan Bhargava" wrote: > As JS/ECMAScript gains more and more of a functional use, I

Re: JSON5

On Tue, Jul 11, 2017 at 3:48 AM, kai zhu <mailto:kaizhu...@gmail.com>> wrote: > any significant degradation in json parsing-performance would impact the > world wide web. can anyone knowledgeable on js engines comment on parsing > performance? > > I wouldn't expe

Re: Operator overloading proposal

-1 javascript operator-overloading is a solution in search of a problem. there is virtually no real-world use-case where this feature would would not cause surprises and code-bloat (from bloated and unmaintainable polymorphic classes dealing with all the edge cases). just imagine all the “fun

Re: Operator overloading proposal

> No. It is a solution to a problem I have today: arithmetic on decimal values. would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithm

Re: Operator overloading proposal

r): > > {1, 2, 3} ⊕ {1, 2, 4} = {3, 4} > > I'd strongly prefer an operator variant over any method version, because it > matches the math notation much better. You shouldn't actually need to learn > some naming idiom just to add two things. > > On Fri, Jul 14, 2

Re: Recent language addition suggestions

+1 > On Jul 17, 2017, at 7:24 PM, Isiah Meadows wrote: > > I've noticed lately that a lot of heavy syntax proposals [1] [2] [3] > have lately started appearing here that would only appeal to a small > niche audience (and not likely garner general use), and are more like > a "it'd be nice if we c

Re: Recent language addition suggestions

> I would like to note that JavaScript is already starting to > feel a bit large, and we should definitely take greater care on > realizing the added complexity of new language features my personal opinion is that es6 was a net-negative creating chaos in the world of frontend-development (making

Re: Removal of language features

+1 On Jul 20, 2017 6:36 AM, "David White" wrote: > Hi, > > I’m just curious as there are a lot of proposals for the addition of > features to the ES specification, is there any scope for requests to remove > language features? Going via the same means of writing a proposition that > would attempt

Re: Removal of language features

pragmas although not great and should be used sparingly, are still the most feasible way forward to limiting excessive features. that being said, es6 is such a different beast from es5, that i think a backwards-compatible “use es5” text pragma would be appreciated by the significant number of v

Re: Removal of language features

all but uses these features. there are many of these managers in asia who copy whatever they perceive is trending in silicon valley, with very little care about the technical-risks they bring to projects. > On Jul 22, 2017, at 5:14 AM, T.J. Crowder > wrote: > > On Fri, Jul 21

Re: Removal of language features

> On Jul 22, 2017, at 11:37 PM, Maggie Pint wrote: > > Having been a delegate to tc39 from the JS foundation for only about six > months, I can't claim authority to speak to all of the history here. That > said, I can very assuredly tell you there is a significant amount of respect > for ever

Re: JavaScript Versioning

> On Jul 23, 2017, at 4:47 PM, Dante Federici > wrote: > > The bottom line here is that browsers aren't a place for a type safe and > correct language (well, thy could have been but hey, such is history). > They're a medium to consume information over the internet. +1 __

Re: Removal of language features

> On Jul 23, 2017, at 10:58 AM, Vinnymac wrote: > > Above Steve mentions that many people are mixing language additions with > framework fatigue. I have to agree with him. In my case I am not overwhelmed > by any of the additions TC39 has chosen to make to ECMA. In fact it is > something I lo

Re: JavaScript Versioning

ntial > "+1" or > "-1" emails if they contain no meaningful contribution to the conversation? > > If you want to make a point, make your point. If not, don't. > > Much obliged! > > On Sunday, July 23, 2017 11:58:34 PM CEST kai zhu wrote: > > >

Re: Removal of language features

On Jul 27, 2017, at 5:43 PM, Andreas Rossberg wrote: > > That is not always true. For example, ES6 has caused some notable performance > regressions for ES5 code initially, due to extensions to the object model > that made it even more dynamic. The new @@-hooks were particularly nasty and > so

Re: Stream + async await

so that everyday programmers can relate, can someone give a code-snippet of the proposal equivalent to the common-use nodejs example below? ```javascript function consumeReadableStream(stream, consumeChunk, callback) { /* * stream - readable stream * consumeChunk - has signature - function (chu

Re: Stream + async await

the timeout handler will not work as advertised, e.g. what if io / db issues causes a network stream to intermittently respond in intervals far greater than 3ms or not at all? > On Jul 31, 2017, at 7:26 AM, James Browning wrote: > > It'll look something like this: > > ```javascript > > a

Re: an operator for ignoring any exceptions

-1 in my real-world experience, JSON.parse and nodejs fs.readFileSync are the only 2 common use-cases that would benefit from this. its more practical to use helper-functions for those 2 use-cases rather than change the javascript language yet again (besides, returning an empty string is commonly

Re: import.meta and TC39 process as a whole

the rushed speccing of es6 modules is partly the reason people like me decided to join this discussion to voice opposition and provide inertia against such hugely disruptive changes in frontend programming. i see this as a feature that primarily benefits companies with large code-bases and fronten

Re: import.meta and TC39 process as a whole

> I’m curious what the concerns were. You mentioned disliking the syntax, but > I’m guessing there’s more to it than that? the concern is that es modules are starting to look like a solution in search of a problem. its redundant and unnecessary on the server-side. and it continues to fail to

nits on BigInt Proposal

looking at the use-cases for this feature @ https://github.com/tc39/proposal-bigint#use-cases , i'm not convinced it improves everyday programming, or outweigh the benefit and simplicity having a single number type. my nits are: - will this b

Re: Proxy performance: JIT-compilation?

of course Proxy is going to cause deoptimization problems when you start breaking assumptions about Object builtins (which obviously have more aggressive and specialized optimizations than generic methods). in v8, i understand the common-case optimization for builtin getters to be a direct pro

Re: Guidelines and General Direction for Standard Library Proposals

my thoughts are the opposite. javascript (similar to perl and php) already has a huge number of specialized builtin functions and methods accumulated over its 20+ year evolution that pretty much solves every practical problem encountered in frontend programming (and effectively backend as well). th

Re: Guidelines and General Direction for Standard Library Proposals

fined interfaces etc. > > All of them are missing in JavaScript. PHP have extremely bloated standard > library - and JS have very minimal one. > > On Sun, Aug 6, 2017 at 4:32 AM, kai zhu <mailto:kaizhu...@gmail.com>> wrote: > my thoughts are the opposite. javascript (sim

Re: Guidelines and General Direction for Standard Library Proposals

rdware/bare metal, where > package dependency considerations are real. Keep that in mind. :) > > Thanks, > > Eli Perelman > > > On Sun, Aug 6, 2017, 6:44 AM kai zhu <mailto:kaizhu...@gmail.com>> wrote: > inline > >> WeakReferences, > -1 footgun

Re: Guidelines and General Direction for Standard Library Proposals

docs.python.org/3/library/index.html> > Big part of it isn't relevant to JavaScript (interactions with external world > are left to vendor), but even then Python have everything that have JS and > much more. > > On 6 Aug 2017 2:45 pm, "kai zhu" <mailto:kaizhu

Re: nits on BigInt Proposal

no, just use one BigInt padded with a bunch of zeroes (e.g. instead of $12.34, use 123400, and round to nearest integer for division). this is what i meant by “fixed point” decimal. for current javascript double-precision numbers, you can do integer arithmetic up to around 9,007,199,254,000

Re: Guidelines and General Direction for Standard Library Proposals

; > .. Don't you think, that's a bit arrogate? > yes it is arrogant of me. partly its because i care alot about javascript and am upset at how fast and loose people play with its language spec. you have to expect eventual pushback against things moving so fast (if not m

Re: Proposing a conditional assignment (or equals) operator

this proposal is not as useful as you would think. when integrating with api's and modules not written by yourself, you will always be self-doubting whether the "other" guy who wrote their code used null/undefined/false/0/ values, causing you to avoid using this feature in general. the is common

Re: Re: Defer expression

setTimeout is still the best solution in my mind. none of the promise or async code examples presented are as immediately obvious as setTimeout that the code is to self-run at a later time (and you don't need the 1ms argument). ```js // self-comment that this code will self-run // after the main

Re: Re: Defer expression

i can give you a specific solution to one of my async init problems (done entirely in vanilla es5 code). in this use-case, i want to run integrated tests, but have to wait for the server to listen on a port, and the db to be seeded first. to keep complexity at a manageable level, i find its worth

Re: A few module ideas

for the forseeable future, the only practical solution i see to these frontend performance issues is to avoid using es modules, and revert to the simple, old-fashioned method of assigning libraries to the window namespace. On 8/20/17, James Browning wrote: > These are just some ideas I've had for

Re: Picking (deconstructing) properties into object literals

-1 and agree with isiah furthermore, i see javascript deconstruction as a never-ending can-of-worms that too-often devolves into ruby-esque confusion / arguments over the “best” way to do assignments. NO AMOUNT of language-spec changes will resolve all these arguments, so forget about it. p.s.

Re: Re: Native Function Composition

-1 composition and pipeline-operators are both INCOMPATIBLE with javascript's async-programming style, and will likely result in tech-debt when used. its fairly common for blocking-code to evolve into async-code as features are added, e.g. ```js result = arg |> operator1 |> operator2 |> operator

Re: Lazy evaluation

inline > On Sep 1, 2017, at 1:03 AM, Isiah Meadows wrote: > > It'd solve a problem similarly to Kotlin's `by lazy { ... }` delegate, > .NET's `System.Lazy`, Swift's `lazy var`, among many other > languages. It's very useful for lazy initialization [1], such as > lazily setting up a database, req

Re: Mixing grammars

i tend to agree with peter that function-composition and pipe-operators are likely footguns that don't solve anything new, and that you should be careful what you wish for. like es6, its all fun when you're writing your own code, but not so much when you "inherit" someone else's orphaned web-proje

Re: Mixing grammars

o debug other people's unreadable code like i do. On Sep 6, 2017 06:40, "Jordan Harband" wrote: > > If operators are in JS, then code using them reads like JS by definition. > > On Tue, Sep 5, 2017 at 4:38 PM, kai zhu wrote: >> >> i tend to agree with pe

Re: Mixing grammars

s mature, and prefer something with minimal sugar, like es5 was. On Sep 6, 2017 11:20, "Michael Kriegel" wrote: > > Quoting kai zhu: "more people like me might look at es9/10 code that may have this feature and think "this looks nothing like javascript" anymore, and

Re: Lazy evaluation

ks. > > We were discussing patterns here, nothing to "please don't" and IMO, dogma > oriented rules are over-engineered anti-pattern too. > > Let's not make this ML an awkward place for who wants to just learn or > explore JS language features, thanks. &g

Re: Math.minmax

:xav...@stouder.io>> wrote: > JDecker: Just added your solution on the benchmark, it beats every > others solution and it's a elegant solution. > > Kai Zhu: We can't see the screenshot. But please take in consideration > that it's been a long time that ECM

Re: September meeting notes?

just noticed the notes are up now - https://github.com/tc39/tc39-notes/tree/master/es8/2017-09 -kai > On Oct 9, 2017, at 9:46 AM, Jordan Harband wrote: > > Typically, the notes are published after a week or two, so that all TC39 > m

Re: Make comma at the end of line optional

-1 for code-maintainability. i don’t see the benefits justifying the extra complexity and rules it adds to javascript style-guides and linters (and those who follow them). > On Sep 26, 2017, at 3:27 AM, Alexander Jones wrote: > > IIFEs start with a (. Putting line breaks before certain expressi

styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

there are several factors for the current javascript-fatigue. one factor which tc39 could help mitigate is to provide a narrative on how to consistently apply proposed language-features (over existing-practices and interfacing with legacy-code). i feel too many new and old javascript-programme

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

ieves es6 was a mistake and a step in the wrong-direction for javascript and frontend-development. -kai On Oct 18, 2017 3:02 PM, "T.J. Crowder" wrote: > > On Wed, Oct 18, 2017 at 6:44 AM, kai zhu > wrote: > > > > there are several factors for the current javascr

Re: Shorter syntax for arrow function assignment

-1 this fails styleguide sanity-check. we currently have 3 common styles of declaring functions: 1. foo = function () {...} 2. function foo () {...} 3. foo = () => {...} does this extra 4th style offer anything new to justify making the javascript language even less consistent than it already is?

Re: Since we're discussing arrow functions and syntax...

-1 this is user-hostile to c++ programmers writing wasm / node-native modules, when they context-switch c++ <-> javascript On 10/25/17, Michael Rosefield wrote: > I like arrow functions, and sometimes the only reason I don't use them is > because I need this-binding. > > So I, personally would li

Re: How it feels to learn JavaScript in 2016

tc39 is partly to blame for promoting the perception of javascript language instability, which promotes tooling instability. generators, es modules, destructing, let, fat arrows have caused tremendous harm to tooling stability, which has made frontend-development hell for everyone. On 10/27/17,

Re: How it feels to learn JavaScript in 2016

Mark wrote: > kai, what do you think would've been a better alternative? (Honestly > curious) > > On Fri, Oct 27, 2017 at 1:27 AM kai zhu wrote: > >> tc39 is partly to blame for promoting the perception of javascript >> language instability, which promotes tool

Re: How it feels to learn JavaScript in 2016

n don't use > them. > Meanwhile, other people will be using them to build reliable, > well-engineered, large-scale, performant applications. > Bob > > On Fri, Oct 27, 2017 at 10:57 AM, kai zhu wrote: > >> tc39 is partly to blame for promoting the perception of

Re: How it feels to learn JavaScript in 2016

e same for 2018. if you're a product manager and your priority is to ship a frontend product, then your safest bet is to avoid es6 altogether. On 10/27/17, Naveen Chawla wrote: > kai zhu, it sounds like you have a bad manager who is over eagerly pushing > for a disruptive transition in a

javascript vision thing

any thoughts? i'll break the ice with a quora question i recently answered quora question: > Why is JavaScript so hated? answer posted: >the primary reason is because traditional oop skills gained from >c#/c++/java/python/etc translate poorly to javascript. > >in javascript, class-instantiated o

Re: Definition mixins

the problem is that you chose to write the chess program in javascript, instead of say, python or c#. why did you choose javascript? probably because you intend the chess program to be an online webapp. mixins, like classes, are inferior to plain json-objects for webapps. how do you intend to s

Re: Web Docs

fyi, mozilla recently created a webpage to publicize its position on open Web and Web-related specifications submitted to standards bodies like the IETF, W3C, and Ecma TC39 @ https://mozilla.github.io/standards-positions/ the process to ask them for a position is to file a github issue @ https://g

Re: Question of the Day: What about all this asynchrony?

criticizing tc39 for the current problems in frontend-development is fair-game. many of theses issues wouldn't exist if tc39 had responsibly gatekeeped es6 with a more modest feature-set of languages-changes, instead of creating an entirely new language. On 11/9/17, Michael Lewis wrote: > On Wed

Re: Shorthand for "function" keyword

the *this* in fat-arrows is irrelevant to frontend-developers who prefer to use static functions to manipulate json-data, rather than class instantiated-objects which are difficult to serialize / reconstruct when baton-passing between frontend <-> backend. On 11/14/17, Naveen Chawla wrote: > Arro

Re: How it feels to learn JavaScript in 2016

On 10/28/17, Frederick Stark wrote: > I'd just like to thank TC39 for not breaking compatibility. All the niche > old libraries I use that were written in ES5 still work in my ES6+ projects > with no issues. introducing the new typeof Symbol() === 'symbol' does break backwards compatibility with

Re: FW: javascript vision thing

over the >> existing prototype-based model, just with easier native subclassing. >> You could in theory replicate this in the rest of the language with a >> combination of `Object.defineProperty`, `Object.setPrototypeOf`, >> `new.target`, and existing ES5. >> - &

Re: How it feels to learn JavaScript in 2016

i disagree. you can write more maintainable and cleaner code with the premise typeof's will never change again (and give a one-time pass for symbols), instead of over-engineered paranoid code that it *may* change again in the future. On 11/25/17, Oriol _ wrote: > It was kind of obvious that che

Re: How it feels to learn JavaScript in 2016

then we wouldn't have that problem, and the current undefined behavior when its encountered in db drivers. On 11/26/17, Claude Pache wrote: > >> Le 25 nov. 2017 à 16:03, kai zhu a écrit : >> >> i disagree. you can write more maintainable and cleaner code with the >

Re: How it feels to learn JavaScript in 2016

s are primitives, they don't have persistent >> properties, for example). >> >> Code that's written as if things will never change is brittle; "paranoid" >> code isn't over-engineered, it's simply *engineered* to handle change >&g

Re: A way to prevent properties to be added to an object if they are null or undefined.

@rodrigo, you can achieve most of what you want with a simple helper function. my suspicion is there are too many variations for this to be practical as a language proposal (e.g. you often want the empty string "" to be considered nullish as well for the special nodejs object process.env, which sil

Re: async/await -> await/async: a simpler, less error-prone async syntax

- > > Isiah Meadows > m...@isiahmeadows.com > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > > On Tue, Dec 5, 2017 at 8:49 PM, kai zhu wrote: >> you can avoid this entire debate b

Re: async/await -> await/async: a simpler, less error-prone async syntax

> On Dec 7, 2017, at 5:50 PM, Isiah Meadows wrote: > > The real solution to that would be stackful coroutines, but those are tricky > to implement and are substantially slower at lower nesting levels. (Go's > goroutines are built from this under the hood.) There's tradeoffs to be made. that i

Re: Identifying pure (or "pure within a scope") JavaScript functions?

> This led down a long, rambling path [1] where I then realized: if the > callback function is a pure function, then for the purposes of that callback, > the arguments probably do not need to be wrapped in proxies at all. The big > catch is that the callback can't store any of the arguments in

Re: Identifying pure (or "pure within a scope") JavaScript functions?

But I'm writing a library for developers to use, and if I can > provide advice on the best way to use that library, I think it's worth the > time to think about how that library works, and how to be nice to the > machines that it will run on. So I'd better think a lot

Re: Allow specify numbers with suffixes

> On Dec 13, 2017, at 2:15 AM, Sam Goto wrote: > > + rick that co-authored numeric separators too and may have thoughts on this. > my first impression is that this (if kept purely as something that gets > ignored by the VMs) shares a lot of the sentiments with numeric separators …. -1 the dif

Re: import { foo, bar } as obj from 'module

> I don’t know how much of a factor this is in language design, but I think > this addition could have a nice side effect — it might help encourage > patterns that happen to play well with "tree shaking". tree-shaking is incompatible with class-inheritance and meta-programming in javascript.

Re: Re: import { foo, bar } as obj from 'module

we're talking about the same thing. class-based libraries like backbone.js for example cannot be tree-shaken. i've done manual tree-shaking for the entire frontend-stack for swagger-ui, by writing tests and doing deadcode-elimination from code-coverage. the takeaway from that was most of its libr

Re: Allow any quoted string to be multiline?

c#L6> ``` "auto remove trailing whitespace" autocmd BufRead,BufWrite * if ! &bin | silent! %s/\s\+$//e | endif ``` not every problem in javascript demands a tc39 language-proposal-hammer. use some common-sense. > @Kai Zhu: As has been done in the past, I, too, would like to

Re: javascript vision thing

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#? also, is another part of the vision to add features to javascript to solve special engineering-pro

Re: javascript vision thing

On Dec 19, 2017 01:36, "Naveen Chawla" wrote: > > Using static methods with plain objects can be cool if you don't want method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish. @naveen, have you tried adding asynchronous features (e.g. typeahead

Re: javascript vision thing

the one that's simpler to implement based on what your app is doing! > > To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever. > > > On Wed, 20 Dec 2017, 8:44 am kai zhu, wrote: >> >> On Dec 19, 2017 01:36, &qu

Re: Proposal: Optional Static Typing (Part 3)

rant warning > The demand for types as a different approach to code has been so strong in > the past few years that separate languages have been created to deal with the > perceived shortcomings. where is this demand coming from? newcomers from c# / java who don't know anything about how javasc

Re: Proposal: Optional Static Typing (Part 3)

in your code. these are the kinds of bugs that keep javascript-developers awake at night, not some kiddie string-instead-of-number type-error. > On Jan 14, 2018, at 12:48 AM, Pier Bover wrote: > > I strongly disagree with kai zhu. > > where is this demand coming from? newcomers

Re: Native Tensor support

for stuff like machine-learning, using web-assembly / asm.js on an existing c/c++ library is probably more practical than trying to roll your own in javascript. here are some pre-compiled (in asm.js) binaries using fann you can download and run directly in nodejs: https://github.com/kaizhu256/n

Re: Native Tensor support

> On Jan 28, 2018, at 10:58 PM, kai zhu wrote: > > for stuff like machine-learning, using web-assembly / asm.js on an existing > c/c++ library is probably more practical than trying to roll your own in > javascript. > > here are some pre-compiled (in asm.js) binari

Re: nits on BigInt Proposal

@bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754 standard) is good enough for accounting (with 34 decimal-digit precision)? like existing database drivers, you can only get/set strings, but infix / inplace operators wouldn’t have that restriction. e.g.: ```javascript a

Re: nits on BigInt Proposal

y interface :( [1] https://github.com/tc39/proposal-bigint/issues/120#issuecomment-364521444 <https://github.com/tc39/proposal-bigint/issues/120#issuecomment-364521444> > > On Fri, Feb 9, 2018, 08:51 kai zhu <mailto:kaizhu...@gmail.com>> wrote: > @bruno, i'm wonderi

Re: Suggestion: Destructuring object initializer.

inline counter-rant. > On Feb 8, 2018, at 9:04 PM, Bob Myers wrote: > > It does make one stop and wonder why the group will endlessly entertain > trolls debating whether or not ES6 (or ES5) portends the end of civilization > as we know it, while relentlessly ignoring literally dozens of > sim

Re: Proposal to add symbol: "hasInstanceStrict"

java-programmers. > On Feb 20, 2018, at 3:47 PM, T.J. Crowder > wrote: > > On Tue, Feb 20, 2018 at 8:34 AM, kai zhu <mailto:kaizhu...@gmail.com>> wrote: > > > > @aleksander, javascript was not designed to validate functions and > > class-instances passe

Re: Proposal to add symbol: "hasInstanceStrict"

es from java/c# that are mosty irrelevant to the kinds of programming-tasks done in the browser/webview. > > > On 2/20/2018 2:47 AM, T.J. Crowder wrote: >> On Tue, Feb 20, 2018 at 8:34 AM, kai zhu > <mailto:kaizhu...@gmail.com>> wrote: >> > >> > @a

Re: Function composition vs pipeline

my vote is for neither. exactly what industry painpoint or problem-space do either of these proposals solve? rather, they compound an existing industry painpoint; where ocd-programmers have problems in deciding-and-choosing which es6 style/design-pattern to employ and stick with before coding eve

Re: Function composition vs pipeline

yntax that's very useful for many people. If you > want too simplify syntax yourself you can use a linter to disable > alternatives. > > On Mar 10, 2018 22:56, "kai zhu" wrote: > >> my vote is for neither. exactly what industry painpoint or >> problem

Re: Function composition vs pipeline

ly, I'd probably structure your example more as an async function... > > -- > Michael J. Ryan - http://tracker1.info <http://tracker1.info/> > > On Thu, Mar 15, 2018 at 9:22 AM, kai zhu <mailto:kaizhu...@gmail.com>> wrote: > >> On Mar 15, 2018, at

Re: JSON.canonicalize()

stepping aside from the security aspect, having your code-base’s json-files normalized with sorted-keys is good-housekeeping, especially when you want to sanely maintain ones >1mb in size (e.g. large swagger json-documentations) [1]. and you can easily operationalize your build-process / pre-com

Re: Proposal: if variable initialization

this is why let and const should *never* have been introduced. if we had stuck with just var, none of these petty-arguments and bickering among team-members/shops on scoping-styles that ultimately have *zero* productivity or benefit to web-projects would be possible. and there's nothing wrong

Re: Proposal: if variable initialization

@thomas, no. i'm serious in my opinion that let and const were mistakes. -kai > On Mar 21, 2018, at 9:01 PM, Thomas Grainger wrote: > > Is this sarcastic? > > On 21 Mar 2018 12:58, "kai zhu" <mailto:kaizhu...@gmail.com>> wrote: > this is why let and

Re: Proposal: if variable initialization

how is any of this less-confusing than a simple style-guide of pre-declaring all variables @ the beginning of a function? again, there’s zero legitimate reason why javascript even needs block-level scoping of variables (and arguing because other languages have it is not a reason). you're just c

Re: Proposal: if variable initialization

domain in examples without prior coordination or asking for permission. http://www.iana.org/domains/example";>More information... */ }()); ``` > On Mar 22, 2018, at 2:31 AM, Christopher Thorn wrote: > > This is just trolling that seems intended to derail the discussion

Re: Proposal: if variable initialization

@mike yes that’s true, but issues with blocking-code javascript data-structures/algorithms are rarely the reason web-projects fail. they fail largely due to unresolvable integration-level io/workflow issues (that are unique only to javascript). block-scoping fixes the insignificant former, wh

Re: Proposal: if variable initialization

unlike all other popular c-derivatives, javascript is the only one that's *not* a blocking-code language by design. maybe tc39 should do some outreach to educate the many language-designers and polyglots who only know blocking-code patterns of this simple fact. as i've said before, adding thes

Re: Proposal: Static sort method on Array

if you want to adhere to the python/jslint philosophy of “there should be one and preferably only one common design-pattern to do it”, then array.from is the most suitable candidate for copying/coercing lists. it can generalise to common pseudo-lists like function-arguments and frontend-query-s

Re: EcmaScript Proposal - Promised functions

or ... you could bypass these low-level promise-abstractions altogether, and elegantly solve the actual integration-level task asked by your pm - with a single, easy-to-debug, throwaway recursive-callback (which will likely work exactly the same 10 years from now, while god-knows how the magic w

  1   2   3   >