vimslayer

"Text is easy to read" wasn't in their guidelines.

I think pretty much everyone agrees with you on that, I haven't seen anyone advocate that students _should_ be treated all alike. It's just that providing individual guidance requires more teachers and thus more money...

And then someone comes in and suggests that we don't need so many new teachers if we "use technology" to help fill the need, like some learning app could be the silver bullet that revolutionizes teaching. Maybe it will some day, but seeing what we've had so far I'm not exactly holding my breath waiting to see that happen.

This talk gained some controversy because the comparison with AngularJS wasn't very fair, IIRC they weren't using some basic optimizations like $index with ngRepeat, which would've been the best practice. React requires the key property for similar purposes and actually displays a console error if you forget it, unlike AngularJS for $index.

If you are interested in finding possible security holes, you could try finding prototype pollution bugs in basically any library that somehow handles user input. Utility libraries like lodash and underscore, argument parsers like yargs, minimist, others like moment, handlebars, DB/ODM tools like Mongoose, Knex, etc.

You'd look for code where input would be able to modify Object.prototype (or I guess some other constructor's prototype) unintentionally (and it's basically always unintentional).

Example of such vulnerability found in Minimist https://snyk.io/vuln/SNYK-JS-MINIMIST-559764

These issues are a constant pain in the JS ecosystem and you wouldn't be the only one using fuzzing to try to find them.

For what it's worth, in your "all other programming languages" example you don't need the second null check

    null != james.car.colour

It's redundant when we know the first two are true.

AFAIK it's possible to use native controls too with Qt these days. I don't know if this project is doing so (probably not).

Telegram is a QT app, btw. Still can take quite a bit of RAM, but much less than, say, Signal or Slack.

They were supposed to give out free buckets in the opening of a new shopping mall, but that was canceled due to the virus situation. According to Iltalehti, the opening had about as much people coming in as any other store that day.

This is totally offtopic but since bunch of people are talking about torrenting here I figured I'd ask - are you getting subtitles from somewhere?

I think my English is pretty good but still watching shows without subs feels like it takes more work and doesn't let me focus on the content.

I used to use opensubtitles.org but it's gotten from difficult to use to impossible to use due to all the popups and crap like that.

Problem is that dollar cost averaging becomes nigh impossible if you loose your job because of the situation.

Though most tools that use "JSON" as the config format actually use some superset of JSON, like JSON5, and do support comments. eslintrc, babelrc, vscode config... pretty much every JS tool configuration apart from package.json.

I don't know why people would prefer that over YAML or others but at least you can actually add comments in them and the reason for their popularity doesn't seem to be baked in parser support because these tools are adding their additional "JSON" parsing anyway.

That could work, but note that there are other libraries that are purpose-built to do diffing without the rest of git's many features. We are using jsondiffpatch [1] and quite happy with it. It also has builtin formatters to output e.g. html view of the changes.

[1] : https://github.com/benjamine/jsondiffpatch/blob/master/READM...

Your implementation is missing features like capture-based substitions

     // Remove repeated characters
     'foobar'.replace(/(.)\1+/g, '$1')
     "fobar"

and overriding behaviour with Symbol.replace

Also, Custom Elements is in the area of W3C, not TC39, I believe. There could be different rules and people involved. Although I'm sure they'd like to avoid breaking the web too.

Plain text is not guaranteed to function in the far future.

Can you really consider Deno to be a "TypeScript runtime engine" when it compiles TypeScript to JavaScript and runs it in V8, a JavaScript engine.

AssemblyScript is not TypeScript. Especially so if you don't consider TypeScript to be JavaScript; I'd argue that the difference between TypeScript and AssemblyScript is bigger than TypeScript and JavaScript.

They seem to be using Rollup for builds, which supports ESM output, so they wouldn't even need to do any refactoring for that. Couple of configuration changes would suffice.

Uno [1] and Avalonia [2]?

[1]: https://platform.uno/

[2]: https://github.com/AvaloniaUI/Avalonia

Depends on implementation, you could remove the images from DOM when the user has scrolled passed them, and many libraries for inifinite scroll do exactly that.

Imgur does lots of things wrong, it's really really horrible to use, especially on mobile.

Although to be "fair", that's probably largely intentional crippling of the site to push users towards their app.

It's the new hotness if you measure hotness by the amount of Medium posts written about it.

Webpack does.

https://github.com/webpack/webpack/blob/master/tsconfig.json

https://github.com/webpack/webpack/blob/master/lib/Entrypoin...

Ugh you're right, it wouldn't work then. For what it's worth I was mostly commenting on the "the poster child of why async/await was made" comment above with the idea that async/await wouldn't necessarily be needed to make the code cleaner. But as you pointed out, in this case it wouldn't work. I'm sorry if the commment came out as wankery.

Even without async/await, it could be better if some unnecessary nesting would be cleaned up

    openpgp.cleartext
      .readArmored(req.body.message)
      .then(message => {
        openpgp.key
          .readArmored(nodes[0].value.key)
          .then(key => {
            ...
          })
      })

could be

    openpgp.cleartext
      .readArmored(req.body.message)
      .then(message =>
        openpgp.key.readArmored(nodes[0].value.key)
      )
      .then(key => {
        ...
      })

Because one is a language feature and the other is yet another JS library made by some person.

That's not an Electron limitation, it's a design choice they've made knowingly. As a "counterexample", VSCode allows resizing the sidebar just fine.

Note that this won't work concurrently if the promises are some kind of "lazy" promise implementation that executes the operation only when `.then` is called. Like with Knex, for example. I prefer

    const [a, b] = await Promise.all([promiseA, promiseB])

Try without a catch is fairly common and IMO quite fine when it's not the current method's job to deal with an error but it is its job to clean up state or some resources.

  async showImage() {
    this.showLoadingSpinner = true
    try {
      this.imageData = await fetchImageData()
    } finally {
      this.showLoadingSpinner = false
    }
  }

There might be a parent class/component/whatever that deals with errors and shows them to the user. The image component is responsible for showing the loading spinner and it shouldn't be left spinning if there's an error.

In the current proposal,

    case (value) {
        when { constructor: Buffer } ->
            console.log("It's a Buffer!")
    }

that doesn't handle subtying though and doesn't work across realms.