41–50 of 157 posts
I'm still waiting for abortable fetch feature, since I have to deal with some services that have unstable network connection and often got stuck and never drop their connection. Is there any progress over this one? Last time I heard, they still have to wait till rusty_v8 got matured enough for this feature to be available.
Earlier quoted context omitted.
But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem
Just because they are attempting to address it does not mean they will succeed.
It reminds me of Angular coming with it's own Router, Forms, Animations and then since they're provided officially, alternatives don't get created and then the half of the team leaves and the packages are abandoned.
But I also was quite skeptical of their dependency model with plain url imports.
With the current implementation you end up with a half-baked import map that's essentially a poor mans package.json, but without any of the tooling that you'd expect. (like npm upgrade, npm outdated)
It recently dawned on me what they are going for: a "cloud native" computing platform that doesn't require builds and packaging. Targeting both Javascript and WASM.
I do believe there is quite a lot of promise in the project. The tooling can improve. It'll be interesting how things evolve.
Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…
Each team will have different problems when it comes to scaling, running tests in parallel - sometimes on the same machine, sometimes on multiple machines, e2e tests vs unit-tests, etc. This looks like a problem you solve in a library, not something to add in the core.
Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…
But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem
Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…
I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem.
Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since these libraries are smaller, it's easier to change one for another.
Because of that, community is much less likely to settle on one standard way of doing things just because of "how things are done here", and ecosystem continues to evolve and find better ways of writing code. Would any other language ecosystem that is widely used in production go from callbacks to different promise libraries, to standard promise api to async? I don't think so. (Edit: strike that, Rust seems to have done it too. Well, Rust is also awesome). Of course, it means that you have to learn more; but it also leads to things actually becoming better, and not because of some central mandate by language committee, but as a result of a more decentralised gradual evolution. (Not completely decentralised, just compared to alternatives).
In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase; in NPM, I've done meaningful contribution to a library less then an hour after learning about it's existence.
Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…
> 1000+ dependency from NPM I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem. Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since thes…
Some reasons it's a problem:
- it's slows and disrupts the development process
- packages get abandoned very easily; not many packages are highly popular/active
- security audits are essentially impossible
> Of course, it means that you have to learn more
JavaScript takes this to an extreme. It literally takes daily effort to keep up.
> In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase
So you prefer an ecosystem created by amateurs? After years of working with PHP and JavaScript, I don't.