491–500 of 598 posts
Have you talked with the TS people to see if maybe there are some bottlenecks that could be rewritten in Rust rather than rewriting everything? Even though I would love to have TSC in Rust, it seems like it would be a huge amount of work.
As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…
I'm a functional enthusiast and I find it much more enjoyable in TS. There is a lot of cool and interesting functional theory that only relates to types. Having a good type system tht TS provides has also saved me so much time debugging. It's invaluable
Earlier quoted context omitted.
Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.
When other people go ahead and build billion dollar companies on top of your development you can't "just fix the mistakes"
Software changes, languages change. Billion dollar companies adapt or migrate.
Earlier quoted context omitted.
> That combined with the 'download random code from any url What protection does NPM actually give you? Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable ins…
> What protection does NPM actually give you? Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well. I think this could be fixed quite easily if one could a…
Earlier quoted context omitted.
I think the answer is a break in backwards compatibility on a major version release. People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.
I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with. Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript. More to the point, Ryan has a humble explanation of what regrets he has about Node.j…
Why is that amusing? I specifically chose that example for that exact reason. I was highlighting the difference in the audience and use case.
> However I'd suggest this is not one of those cases.
I don't see the argument that supports that, either in the post or your reply.
The thing is, I can see Beepboo 1.0 being announced in 2025 to address the things that went wrong with deno. Because there will be design mistakes. And at what point do you say 'oh too many people rely on this software to fix this, I have to start over'?
Couple this with a very real trend-chasing and resume pushing in frontend dev and I'm starting to understand why people are so cynical about this stuff.
Typescript is something more palatable to me because it wasn't throwing the baby out with the bathwater.
Even if this new thing has slightly nicer syntax or usage of promises or whatever, does this alone justify it's existence? Learning all this new tooling and ecosystem all over again? Dividing the web development ecosystem even more? I really don't see how the problem it's solving is big enough for us to care really. I mean - enough already. In 8 years I'm sure Ryan Dahl can come up with an even better runtime written…
Earlier quoted context omitted.
Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.
Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.
Earlier quoted context omitted.
Maybe this will develop into a standard of multi-process servers (real micro services you could say), where the permissions are only given to a slice of the application.
Reinventing QNX will always be cutting edge.
Earlier quoted context omitted.
Would you say linux is insecure because a user can download an arbitrary shell script and run it? I know it's not an identical problem, but it does demonstrate that we probably agree that the onus is on the user to assess the risk of any arbitrary code they run on their machine, including the risk associated with the transport they use to obtain that code. Funnily enough I actually agree with you that I would prefer…
> Would you say linux is insecure because a user can download an arbitrary shell script and run it? Linux is not branded as a "Secure thing" right? Here Deno is building marketing on something inacurate.
Or in other words, wouldn't it have been easier and better to make an optionally headless version of the Servo browser with additional native APIs and some enhancements like being able to run JavaScript directly in addition to HTML?
The choice made means that Deno can't be used, at least directly, to make desktop applications, and also doesn't have all the features that browsers have for free, like multiprocess and multiple sandboxes, network traffic inspector, local storage, GPU compute, etc.