That's fine, because it's not exactly clear what "ld" stands for to begin with. If anyone asks, you could just say that the W and E stand for "Weally Efficient".
It genuinely surprises the shit out of me that people haven't created a "middleware" layer that treats GitHub as its backend / source of truth, but everything gets routed through a custom domain. E.g., spin up this glorified reverse proxy on Heroku, and now example.com/bugs is really just example.github.io/bugs, which is a page with all its form actions pointing to the Heroku service acting as a go-between for managing github.com/example/whatever/issues with full backups, etc.
That's a name, not an IP address. And what you would expect to find at that name is not an A record for that IP address (which would be redundant) but a PTR record providing its canonical name.
> Right, but that is basically saying we should all go back to something similar to before npm/bower/etc.
That position isn't without good reason. Refer, for example, to the linked post, explaining the engineering decisions behind esbuild. ("It's Golang, not JS" is only part of the answer to "Why is esbuild fast?" The implications seem to be lost on many of esbuild's users, given the nature of esbuild itself and the job it's supposed to do.)
It's an odd thing. The way people talk, you'd think NodeJS and JavaScript are synonymous. Turns out, NodeJS is this generation's JScript, including shoddy support for the language proper, and it includes vendor-specific extensions that you're expected to use instead. It has somehow though managed to escape any of the criticism that gets thrown at other projects pilloried for stuff like this.
Node came out way before any of these features were invented, and the ES committee knowingly broke compatibility when designing for the browser. Modules are supported since v14 but you have to opt in.
They didn't break compatibility. NodeJS never attempted to be compatible with the Web. The design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out. And it's a design that was in ECMAScript 6. Six years later, and you still have to opt in. The TypeScript team got it right, working in a way that NodeJS should have been taken lessons from.
Yeah, technically better, at the cost of huge complexity.
CommonJS was easy to implement anywhere and dead simple. We only need static analyzers and tree-shaking optimizations because the JS ecosystem went wild on dependencies. I honestly think we were better off 10 years ago.
> NodeJS never attempted to be compatible with the Web
It goes the other way around? Node caved in and support modules now, what has been done in tc-39 for web modules to be compatible with node (considering it predates all of it)?
> I want to build web apps with low memory, cpu, and bandwidth profile. Give us a simpler language that doesn’t need crazy complicated hotspot profiling JITs. Just make the default, simple thing insanely fast.
What makes you think it isn't? What if I told you that people were creating Electron-style apps over a decade before Electron ever existed? Go use Firefox 0.8 or Netscape 6. Pretty much every part of the UI on your screen that you'll interact with is backed by JavaScript. Keep in mind that this was 15–20 years ago, pre-Windows Vista, where main memory wasn't measured in gigabytes. And that was all pre-JIT!
Here's a screenshot of the file listing for the version of AOL Instant Messenger that was built into Netscape Navigator: https://imgur.com/a/ztaMVon
The problem is webpack and the development style favored by the NodeJS/NPM community. It's filled with bad practices, and they all do it because either no one knows better, or they don't care. JS is not inherently slow. It's exceptionally fast, even. Contrary to popular belief, though, how you write code still matters. The myth of the sufficiently smart compiler (including JITs) is that: a myth.
Agreed. They should have required an extra token like ? to disambiguate bindings from evaluations. Not only would it avert this pitfall, it would also obviate the need to have a special identifier to discard a bound value; instead of writing _ to discard a binding, one would just write ? without a variable name.
I fear a poor design like this is going to not only discourage people from using the feature at all, it is also going to poison the well and discourage people from using pattern matching in languages with a much more robust implementation. Which is a shame, because I actually like pattern matching.
(Tinfoil-hat take: Maybe that’s the whole point, after all Guido doesn’t like functional programming.)
I could be wrong, but this PEP feels to me like it only got accepted because Guido is stepping (or stepped) back from his BDFL role. It has noticeably more rough edges and less consistency than most feature adds I have seen in the past. This is pure personal speculation though.
The people who live on GitHub are unfortunately unable to recognize any distinction.