291–299 of 299 posts
Remember when some people advocated not using semicolons to end statements? Good times... https://javascript.info/structure
Earlier quoted context omitted.
I get the analogy, but build/lint/format functionalities are currently split across multiple different tools and their many multiple plugins. They aren't standards, they're just a bunch of tools that people have to glue together every time they create a new project. Attempting to put them together into a single binary with no dependencies isn't creating another standard, it's just creating a single tool (one similar…
Yarn and npm I'm familiar with, though I don't know why to prefer one over the other. Yarn's newer, I suppose that's pro or con depending who you talk to. Npx I had no idea. LSP has two parts, a client implented by an editor (or plugin for one), and a server for whichever specific language. If you always use vim but several languages, you need one language client for vim, and a language server for, yes, each specific…
So Yarn was created to deal with issues in NPM (amongst other things: speed, problems with package duplication, no lockfile). AFAICS from watching Ryan Dahl talking about the process of his developing Node, NPM was kind of an afterthought, so it has some flaws that are difficult to fix because they're so ingrained into how Node works.
So Yarn [v1] has a very similar API, and uses the NPM registry, and works in a very similar way (dependencies go in node_modules, etc etc). Most of the time, when you see the choice, the author of the documentation is talking about NPM vs. Yarn v1.
Competition from Yarn [v1] was a generally good thing despite the slight confusion it causes, because what it did was force NPM to update to include some of Yarn's better features, in an attempt to gain feature parity.
The existence of Yarn v2 is also now [imo] important because of its two main features that differentiate it from NPM. Its API is basically the same as NPM, but the way it works is not, and yes, it's confusing. It works (and works very well), but I think its core value (and the reason why IMO it should be pushed alongside NPM despite the confusion that is likely to cause) is that it's acting as a testbed for features that are probably useful to the JS ecosystem. And the wider the usage, the more those features can be battle tested:
- it has full support for monorepos (storing all code for all associated projects in a single repo) which can make development easier in what would seem to be a large set of contexts.
- it allows a user to dispense with node_modules through a mechanism called plug and play. Dependency management is much better than NPM, issues with dependencies are easier to locate, and unless there are new deps added, there is no install step after the initial one (I can push my code to a repo, someone can clone the repo and just start the application immediately). This IME has fairly significant DX benefits, as well as making CI tasks take significantly less time and resource.
Earlier quoted context omitted.
(async () => { set(await get()); })(); get().then(r => set(r)); Ignoring error handling I'll often choose the second option.
OK. I'll do: const result = await get() set(result) But you do you. Current node and console have top level await BTW.
Earlier quoted context omitted.
OK. I'll do: const result = await get() set(result) But you do you. Current node and console have top level await BTW.
That only works in an async function. The then example doesn't have that requirement. So the alternative shouldn't either.
In other words, your complaints have disappeared in node, and will soon in browsers: https://github.com/tc39/proposal-top-level-await
So yes:
set(await get())This is not a tutorial [1]. It's more like a guide [2]. [1]: https://documentation.divio.com/tutorials/ [2]: https://documentation.divio.com/how-to-guides/ Edit: I don't mention this to be nitpicky. I mention it because I wish that we would collectively start standardizing those terms. I think it would be helpful if, whenever we saw "… guide" or "… tutorial" we had a general idea about the structure and purpose of th…
Earlier quoted context omitted.
That only works in an async function. The then example doesn't have that requirement. So the alternative shouldn't either.
Yes, your example isn't complaining about then() being clearer than await (because it isn't) but rather complaining that top level await isn't everywhere yet. In other words, your complaints have disappeared in node, and will soon in browsers: https://github.com/tc39/proposal-top-level-await So yes: set(await get())
Earlier quoted context omitted.
Yes, your example isn't complaining about then() being clearer than await (because it isn't) but rather complaining that top level await isn't everywhere yet. In other words, your complaints have disappeared in node, and will soon in browsers: https://github.com/tc39/proposal-top-level-await So yes: set(await get())
Sometimes you may need to handle a promise in a function that can't be made async.
Earlier quoted context omitted.
Aren't those the exception and not the rule. Hence the statement modern web = ts is wrong. Personally I used the zoom native client and not the web one. I spend most of my time in offline office and not the web version
> I used the zoom native client and not the web one You might want to reconsider that; they have a pretty bad security track record: https://www.securemac.com/news/zoom-security-flaw-puts-you-a... https://talosintelligence.com/vulnerability_reports/TALOS-20... https://talosintelligence.com/vulnerability_reports/TALOS-20... https://blog.0patch.com/2020/07/remote-code-execution-vulner...
That's like saying don't use the web version cos your out of date browser can be exploited.