inbx0

To each their own. I can't imagine doing UI development without HMR anymore. Makes it so much faster to iterate.

The people who already know JS/TS and would like to occasionally do something interesting with a piece of data. With Python, most of my time goes into googling how that list filtering / mapping syntax went again or some other basic level stuff that I do every day with JS. I know Python, but I'm not fluent in it. And I will likely never be fluent in it, because my Python use cases are so infrequent.

Then again, why bother with the tokens if you have XSS access as an attacker? I'd simply show the user a login prompt and take their password when they type it in.

I don't know if it's what's happening here, but it's a common phenomenon in HN that a post starts a trend of posts with a similar theme. People discuss a subject, they post some links to related projects in comments, other people wander into those links and find them or the links that those pages have worthy of their own HN posts.

Out of curiosity, what features are you using that aren't already supported by all major browsers?

> It's a maximum of 4 videos at once

Hmm, what? Do you mean like max 4 participants in Teams calls? No I don't think there's a restriction like that, it should work exactly the same as the Electron version. Our team also has more than 4 people. Maybe you are thinking some restrictions on the free version of Teams? If you or your company is paying for Teams/Office, then you get the same "premium" features on the PWA as you would with the Electron app when you login.

If you go to teams.microsoft.com with Chrome or Edge and login, it should suggest installing the PWA [1].

1: https://www.omglinux.com/microsoft-teams-pwa-now-available-o...

Have you tried the PWA? I use it in Linux and it's much more performant than the Electron version. You can use extensions too with it, like uBlock Origin, which makes it even faster.

I mean it's still Teams so faster here means still not fast at all, and it still suffers from many other UX problems, but definitely worth trying if you are forced to use some form of Teams.

It is also the norm to strictly pin dependency versions in the npm-ecosystem, at the project-level, via lockfiles. So simply doing an `npm install` in an existing project won't install the new trojan.

Yes, versions aren't usually pinned at the package-level, so if you install a new dependency that introduces the trojan to the project, then yeah your are compromised. Not sure if that happens to "millions of servers" in a few weeks tho, it'd have to be a pretty popular package at least and remain undetected when these millions of developers presumably test the new code that their new dependencies introduce.

Having versions tightly pinned in the package-level isn't a free gift. It'll lead in lots of duplicated versions of a practically same package being installed and ran when two higher level dependencies have a transitive dependency to sligthly different (but in practice compatible) versions of the same package.

Edit: I agree with the points about sandboxing and permission configuration, etc, though. That's hopefully also coming to Node at some point.

The author is pretty clear that their intention is to use this as a simple first step to creating an app without the hassles of bundlers, they don't seem to be advocating that one would create "medium-large" projects like this. The word "incremental" is mentioned in the first sentence.

Nor does their message come across as "why don't people do this" to me.

> Until recently though, I wasn’t sure how to make this step feel incremental.

Seems like they genuinely just found a neat way to do a thing and wanted to share it.

Offtopic, but Signals and Threads is my absolute favourite programming podcast, maybe even favourite podcast overall. They go into interesting topics deeply, instead of the way too common "interviewer read the summary of the wikipedia page about the subject and is now interviewing someone who actually read the entire page."

Hoping they'll get more content out soon.

In line 3, where it's called

     })();

With this way of invoking, `this` will be `undefined` in "strict mode" (i.e. if the file or parent function has 'use strict' or if we are in an ES module), and Window in "sloppy mode".

In the first example, when you look at the first line

  foo = function() { console.log(this.n); };

You cannot possibly know what "this" refers to when the function is eventually called. Is it some object? Is it the surrounding class or function? Is it window? Is it undefined? Is it the function itself?

There's no way to know, because it hasn't been decided yet. Deciding what `this` refers to in the "normal"/non-arrow functions is up to the caller.

  o1.foo();

Here, `this` will be o1.

  o2.foo();

here, `this` will be o2.

  o1.foo.call("hello")

here, `this` will be `new String("hello")`.

That's what the parent commenter meant by "binding this at the call site".

Classes are still very common out there, despite the popularity of e.g. React function components etc, and `this` is pretty essential with classes.

The pipeline operator [1] is a bit further along, although I'm not exactly holding my breath for it either. At least it currently has a champion. With pipelines

    import { map, takeWhile, forEach } from "iterlib";

    getPlayers()
        |> map(%, x => x.character())
        |> takeWhile(%, x => x.strength > 100)
        |> forEach(%, x => console.log(x));

1: https://github.com/tc39/proposal-pipeline-operator

The main benefit of arrow function generators would be the inherited parent-scope this-binding they'd get

At the end of the day, it comes down to whether browser vendors are willing to ship the feature even though it breaks said websites, and they do have visitor data to back those decisions. If the rule was "never break any website ever", you'd be able to block proposals you don't personally like by crafting a website that "gets broken" by that proposal.

At least in the array grouping proposal, they did evaluate amount and popularity of possibly breaking sites, before eventually renaming the method from .groupBy to .group

https://github.com/tc39/proposal-array-grouping/issues/37

I use Tutanota and it's... fine for my needs. The web app is ok but it'd be nice if there was something like Proton Mail Bridge [1] for Tutanota so I could use my own email client.

I guess having data center inside EU could be a plus for EU citizens?

1: https://proton.me/mail/bridge

Different, I think. It's a Canon but I don't it wasn't bought by me and I don't have it right now so can't check the exact model, sorry. Quick googling suggests that it can be done with Rebel too: https://support.usa.canon.com/kb/index?page=content&id=ART17...

It should be an AF/MF toggle in the lens.

It's not ideal but I've circumvented this by disabling automatic focus and other things that add visible elements to the preview, and the just using the preview's 720p output. It's a hassle and you'll have to manually adjust the focus so that everything's not blurry, but the end result quality is quite good.

Are you using some bespoke Babel plugin that actually adds Java-like classical inheritance to JavaScript, or are you implying that the standard EcmaScript 6 classes which Babel handles by default are somehow "Java-like" instead of prototype based? Because they are not, they still use the same prototype-based inheritance, even though the syntax kinda looks like Java, and have all the same pros and cons of prototypal inheritance as before.

It's a real shame that they threw away Firefox Send. It would've been a great addition to that bundle.

Aren't they? Do people use excel online for anything but viewing spreadsheets they have received via email or Teams etc? What they probably aren't beating is Excel the desktop app.

Offtopic but I have to ask now that this came up, why do people even use enums instead of string literal type unions? The latter just seems so much simpler and more readable to me. You get the same type safety, pretty much the same or better performance, autocomplete works fine etc.

One reason I've heard is that enums allow you to do rename symbol refactoring in all use sites, but like what How often do you need to do that? Once in a lifetime? Twice? And with string unions you can ofcourse also just rename it, TS will tell all the places that need fixing, and it'll take couple hours to go though 1000+ usages of it.

Yeah I agree, that's not what I'd consider good variance rules either.

I guess my point was more about the reasons behind these weird rules. AFAIK interop with existing JavaScript was not the primary reason for doing them this way, if that's any consolation.

FWIW your example wouldn't fly in Flow

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjGBDAzrsAQQDsBL...

By sub-type variance are you referring to issues like this https://stackoverflow.com/questions/47850513/unsafe-implicit... ?

FWIW the lack of explicit variance annotations (and probably many other TS unsound design choices) are not so much related to supporting old untyped JS, but rather language design decisions that have to do with pragmatism and type system complexity.

I can't find it now but I have a vague recollection Hejlsberg talking about the explcit variance annotations explicitly, how those were a huge can of worms in C# and they didn't want to bring them to TS. Unlike Flow, by the way, which does have explicit variance handling and doesn't suffer from the beforementioned foot gun (but does have its own foot guns of course).

There's an issue for that to be added as part of import assertions https://github.com/tc39/proposal-import-assertions/issues/11...

The live reloading side panel for web development in Brackets was ahead of its time.

And to clarify, you should run this once by hand to collect the list, don't add the grepping to the actuall installation script or you are back to square one :D

Here's what I use with yarn, install.sh:

    #!/usr/bin/env bash

    yarn

    function run_install() {
      local dependency="node_modules/$1"
      if [[ -d "$dependency" ]]; then
        yarn --cwd "$dependency" run postinstall
      fi
    }

    run_install 'esbuild'
    run_install 'other_package'
    ...

Reminder that people should seriously consider disabling the install-scripts.

Personal system-wide config:

     npm/yarn config set ignore-scripts true -g

and add & commit a .npmrc/.yarnrc file with

     ignore-scripts true

Yes, this will cause headaches in some (increasingly rare) cases where some package actually needs those scripts. You can fix this with custom install scripts that take care of running install for those specific packages.

And yes yes, as people love to point out, this isn't exactly a bulletproof solution either. The attacker could just put the malicious code inside the package's code and wait for it to be actually executed. But again and again, they don't, they choose to use the package's install scripts as the place to do their dirty work.

So in practice this policy would've alrady protected you from who knows how many of these attacks, and my guess is that it'll continue to do so.

-name "*coa*" is a bit too eager. It will flag other packages too, like the fairly popular babel-plugin-nullish-coalescing

The extension has picked up some attention from the core team, ever since FB retired their Nuclide tool for Atom. Not saying that the extension is perfect, but AFAIK most features come through LSP and are added to the Flow server and should pretty much be just picked up by the extension now that the LSP wiring is done. So apart from bugfixes and other small stuff, I don't know what kind of major updates you are expecting to the thing.