281–290 of 598 posts
Earlier quoted context omitted.
Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.
Security is literally the main selling point of this thing. Otherwise just use node.
The benefit of NPM is that every package version is immutable...
Also first class Typescript support is great, but they are just using tsc internally... isn't that directly tying a typescript version to the DENO version?
Is there some deterministic way of measuring JS execution time? Explanation for why I want that: I've started making an game RTS game - think starcraft but you can program your units. Currently I'm trying to decide what language to expose to players. The two main requirements are that it's secure (I'll be running player A's code on player B's computer) and that it has a deterministic method of counting execution time…
Is there some deterministic way of measuring JS execution time? Explanation for why I want that: I've started making an game RTS game - think starcraft but you can program your units. Currently I'm trying to decide what language to expose to players. The two main requirements are that it's secure (I'll be running player A's code on player B's computer) and that it has a deterministic method of counting execution time…
Lua is frequently used for interactions with game engines and programming basic logic. Maybe see if there's a Lua engine in whatever language your game engine will be written with?
I have security concerns about all the lua runtimes I've seen. They (very understandably) do not seem to be particularly battle tested against malicious use, and they have a history of security issues when I check their bugs list. Otherwise I'd love to use lua.
Is there some deterministic way of measuring JS execution time? Explanation for why I want that: I've started making an game RTS game - think starcraft but you can program your units. Currently I'm trying to decide what language to expose to players. The two main requirements are that it's secure (I'll be running player A's code on player B's computer) and that it has a deterministic method of counting execution time…
I guess it would depend on the JS engine. If the player is the one writing JS, and you want a scaled down environment (since it's not an app in the browser), probably making your own JS parser/engine could be the way to go? You'd want the JS engine to be inside the game engine somehow.
This is definitely a requirement, a very scaled down one since I don't want any interaction with the outside world apart from the game engine (for determinism purposes).
> probably making your own JS parser/engine could be the way to go
That sounds like a lot of work to do well. If I had infinite time I suppose re-implementing a common language would be the best way forwards, but I don't, especially for a hobby project.
> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…
I guess I'm wondering why Deno is targeting V8 instead of Servo? Maybe I'm mistaken, but Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust. [0] https://servo.org/ [1] https://wiki.mozilla.org/Quantum/Stylo
1. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won't hurt anyone, but it's certainly never something that I've wanted. I expect most people will simply white-list most access by default in all new projects.
2. deno bundle: Initially, when I heard about this, I was excited. The need to bundle code via webpack and similar systems is one of the worst things about front end browser development. It introduces tons of complexity and makes debugging much harder. So I thought, wow, maybe deno is going to just give us a first-class solution to this problem that will just work. Nope. They are only concerned with bundling code such that it can be run elsewhere by deno. A friend put it thus: "we don't want bundlers anymore, so we're making deno bundle, the one true bundler!" "does it do any of the stuff that webpack does?" "mostly no, because it's not meant for that" Read the comments on https://github.com/denoland/deno/issues/2475 to get a sense of what I'm complaining about.
3. URL Imports. Packages in node.js are stupendously easy to use. Making me import from a URL instead of typing `yarn add foo` and `import * as foo from 'foo'` does not make my life any easier. It certainly makes the implementation easier, and I'm glad to see the last of node_modules and path-climbing module resolution. But the URL-based system offers no equivalent that I can see to lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial features. This is something that node developers need and want, and if Deno doesn't provide it, 3rd parties will. My worry is that we'll end up with competing third-party solutions and a fractured ecosystem, due to Deno's failure of leadership here.
4. Stack traces: The single worst thing about using node is the frequency with which you get utterly useless stack traces that tell you nothing about the true source of the error. It was easier to debug C++ programs 20 years ago that it is to debug node.js apps today. But as far as I can tell, deno isn't making any efforts to improve this. That's ok, they don't have to fix every problem. But it does make me worry that they don't know what node.js developers actually care about, if this wasn't on their "must fix" list.
5. Typescript by default. I really like typescript. I mostly want to use it instead of javascript these days. But tsc is slow. Slooooooow. Really really slow. I am worried that most deno programs are going to be very slow to start up in practice. (Before you say "caching", 99% of the time that you want to start a program, it's because you just changed the source code. caching can only do so much in this case). And I am extremely skeptical of the plan to build a new typescript compiler in rust.
I'll conclude with praising a few things that I am very glad to see: No more node_modules, Web APIs, and a promise-based stdlib.
Earlier quoted context omitted.
You'll like https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript
Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.
I noticed in a couple of popular TypeScript (+React fullstack) boilerplates, that they were using ts-node to run the server in production.
Unlike babel-node, there's no mention in the documentation to avoid using it in production - but I figured there'd be performance impact, since it's transpiling on the fly (I suppose just once per require).
New implementation of WHAT? Is this a JS Engine, or a wrapper around V8? Which version?
Guys - whatever it is - I love it (!!!), but this is a very long and wordy article that does not well summarize the most relevant things, and uses words, long explanations for issues that I think are just a little specific.
"First Class Typescript" - does this mean just 'transpilation at runtime'? Or does it mean something more hardcore? What does it mean at all?
This could be 1/2 as long a 2x more explanatory and precise.
Finally - it all looks super cool - but why specifically am I interested in this over things like Node? Speed, security?
Not to take away from the great work.
Earlier quoted context omitted.
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.
True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).
I hate to break it to you but dependency management has been a massive issue in golang until the devs formally adopted go mod.
Only Google seemed okay with checking in their dependencies to version control. Everyone else was doing crazy hacks like https://labix.org/gopkg.in