esailija

The native API calls such as createElement are pretty expensive (in V8 it's like 10 function calls to finally reach the target C++ function) and you are making a lot more such calls when not using innerHTML.

I don't think any of this concerns desktops anyway.

So what's your excuse for the popularity of Java, C++ etc?

But there is no motivation to use alert. There is a huge reward for spammers to get a yes to a notifications prompt, you can then create them even when the browser is closed or when the user is not even on the website. However even so, they are so necessary for applications that this is probably worth it.

Notifications are necessary for many applications, they are not for traditional websites although sadly that doesn't stop them from requesting permission. Imo the notification feature really should require at least https, like many other intended-for-applications browser features like service worker and location. On mobile you could replace most native apps (twitter, facebook, mail etc) with a web app if they supported notifications and save gigabytes of space for stuff that actually needs to be native.

The code needs to pass threshold of originality to be copyrightable, otherwise you don't need to care about the license. For example `(new Array(n+1)).join(padChar)` is definitely not copyrightable.

Unpublish isn't that bad. He could have just as easily made patch updates to each of his modules with malicious install scripts and/or malicious runtime behavior.

Depending on 200 tiny modules, you have 200 different risks vs just having 1 risk.

It is extremely trivial, just not intuitive. It's much harder to actually come up with a case where you know you even need it.

Async/await doesn't only work on promises, it works on any object that has a method named `then`. What's problematic is that you have no control or extension points in the runner so you cannot implement something like Go's defer statement. With generators (which can be made work like async/await, only you say yield instead of await) you can implement the defer statement and more.

I think if you don't even know the basics of something, you should go learn them before discussing it.

fizzbuzz npm edition:

    var zero = require("number-zero");
    var hundred = require("number-one-hundred");
    var isDivisibleBy5 = require("is-divisible-by-5");
    var isDivisibleBy3 = require("is-divisible-by-3");
    var isDivisibleBy5and3 = require("is-divisible-by-5-and-3");
    var numberToString = require("number-that-is-between-one-and-hundred-to-string");
    var fizzbuzz = require("string-fizz-buzz");
    var fizz = require("string-fizz");
    var buzz = require("string-buzz");
    var incrementByOne = require("increment-by-one");
    var forLoop = require("for-loop");
    var ifCondition = require("if-condition");
    var elseIfCondition = require("else-if-condition");
    var elseCondition = require("else-condition");
    var lessThan = require("less-than");
    var print = require("print-string");

    forLoop(zero, lessThan(hundred), incrementByOne, function(i) {
        condition(isDivisibleBy5and3, print(fizzbuzz),
            elseIfCondition(isDivisibleBy3, print(fizz),
                elseIfCondition(isDivisibleBy5, print(buzz),
                    elseCondition(print(numberToString(i))))));
    });

The complaint was that JavaScript doesn't have 64-bit integers but only 53.

Yes it can https://github.com/rollup/rollup. Webpack 2.x can also do this.

It doesn't handle edge cases, it doesn't perform well and it isn't well tested. There is also no documentation. Obviously 30 seconds wasn't enough for you to verify anything at all about this module (namely that it's complete garbage).

And just because some random guy didn't get something as trivial as this right the first time, doesn't mean nobody else can. Also the de facto standard library lodash already has padding utilities, made by people who have a proven track record.

Yes it does: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?

Firstly, these powerful features are not available unless your site is properly (I.E. fully, absolutely nothing can be plain HTTP) protected by HTTPS. You cannot even create service worker without working HTTPS so any kind of PWA is out of question without HTTPS. Secondly, any browser that supports these capabilities also supports Content Security Policy which makes your site trivially immune to XSS and I expect that it will sooner or later become required to get access to the powerful features, on top of HTTPS. Thirdly, any powerful feature is behind a permission that is basically as hard to obtain as the consent to install an app in the first place.

How is it fast? (obviously it was not trustable or well-tested) It is the slowest possible way to implement string padding without any optimization effort whatsoever. This is what I hate about npm, every module claims to be fast even though they have made no effort to be fast.

Even getting a response just so you can know what the original author desires can take a long time and there is no warranties or guarantees that you will even get any response. To me, all the downsides that come with dependencies are not even close to worth it for saving 15 seconds.

I didn't say it shouldn't be part of standard library, I am saying that there is always something that isn't part of the standard library. My point is: if this module was something that shouldn't be part of standard library, what argument would you then use?

The possibility of having bugs in code you don't control (that usually has a clause for no warranties) is an argument for implementing it yourself, not against it. Don't forget how hard it is to get a maintainer even agree on whether something is 1. a bug 2. that needs to be fixed.

I don't understand the standard library argument at all. Standard library is always limited, there is always something that's not included - then what?

This has nothing to do with the JavaScript standard library but the insanity of NPM. There are modules that have even more dependents than `pad-left` despite being included in the standard library (e.g. https://www.npmjs.com/package/date-now, https://www.npmjs.com/package/is-positive, https://www.npmjs.com/package/is-lower-case)

Yes. With dependency you are giving up control and in return you save time in not having to implement the dependency. If the LoC is small you get practically nothing in return and so the only reason to do it is ideological.

Many times it is even faster to write a trivial "module" yourself than even discover it on npm, let alone reading and verifying it. Hell, NPM 3.x is so slow that it's literally faster to write any 1 liner "module" than it is just to install it.

"Reuse" is just a means to an end, it doesn't make sense to do it only for its own sake.

That shouldn't work since syntactically you are in a middle of a function call where you can only have expressions. This is funny because one of the author's point was that JSX makes that confusing because you would never think to write `callFunction(for (var i = 0; ...))` normally.

GC is only a small part of a high level language runtime.

I think what they meant is that they could use python without having to also ship the implementation like CPython. I mean, that thing is huge. How is it feasible to serve 10mb for a website?

The format is just an AST in general, nothing to do with JavaScript. You can even see all the possible instructions here to confirm [1].

1. https://github.com/WebAssembly/design/blob/master/AstSemanti...

There was an experiment ("strong mode")[1] of a subset of JavaScript that is way higher level than asm.js but it failed [2].

1. https://developers.google.com/v8/experiments#strong-mode

2. https://groups.google.com/forum/#!msg/strengthen-js/ojj3TDxb...