261–270 of 446 posts
Earlier quoted context omitted.
We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem
Is Deno still going for TS runtime? > Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language.
Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effort). Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes. I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), clien…
This probably either sounds nuts or over opinionated but I don't think the NPM ecosystem is as valuable as people think it is... stuff is deprecated continuously anyway - when you find a way to move away from 10k dependencies (because your shortsighted previous self decided to depend on a single package without looking closer), it's a damn relief. I hate how needlessly complicated the NPM ecosystem is, I would actual…
And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code.
The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.
Earlier quoted context omitted.
That's why you dual license, which is significantly more approachable. "This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it.
In some places, the people who hold the purse strings are rather far removed from the actual developers, that it's a lot easier to just go with something that's "free". I think this is one of the reasons why cloud computing monoliths like AWS are so successful. It's way easier to set up a $50/month VM on AWS then to get permission to spend $5/month on a VM elsewhere.
Unless you have a ridiculously good relationship with a handful of organizations or a perfect system for fitting into existing infrastructures, it's a big mistake to care about selling something to those organizations.
AWS is popular because it's free for companies with a high potential for getting big (like YC companies) and they can absorb the costs of the sales cycle.
> Many are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. Bash and Zsh scripts calling into native code will never go away. But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Many developers, we think, prefer web-first abstraction layers. Every time I read so…
> Or if it just exists because JavaScript developers don’t want to learn something new. Looks to me like they don't want to write stuff twice, and they would have had to write for the web anyway. The web stack is not good by any measure. The native GUI toolkits are suffering form abandonment, so the web-based toolkits are among the best available (but not at the top). But if you don't have any reason to expect to cre…
SwiftUI is new.
Flutter is new.
Both have taken birth recently and have huge investments and usage.
Earlier quoted context omitted.
> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…
URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits
Earlier quoted context omitted.
I just don't understand this. This project uses distributed version control. This implies 2 things 1. It is impossible to delete every copy of this project. If the authors wanted to restrict access by taking the repo private, they can't. It will always be out there. 2. Every commit is licensed with MIT. So even if there is a licensing change, you have access to every commit licensed by MIT. You've lost nothing except…
"If it's popular enough to be forked by the community" Yes. And if it isn't you need to switch. If you are tied in in a way to proprietary tools or APIs then you have some major migration in front of you. If you don't you you might be able to use Node. If you have a tight schedule already, or no development capacity for the migration, you will need to buy a license because you might not want to run your code on a pla…
Earlier quoted context omitted.
> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…
URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits
If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno
Earlier quoted context omitted.
> Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.
Code examples abound on Stack Overflow, GitHub Gist, blog posts, etc. These may contain direct URL dependencies. Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and…
Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm.
Npm can install from git repos and registries other than npmjs.
Having a package on npm by its own doesn't make it any less malicious.
A solution would be to enforce registries you can import from and fail if it's outside that.