191–200 of 215 posts
Earlier quoted context omitted.
A couple of questions: “Make [] false-y” Why? “Add macros” Why? How? “Bring back `with`” Why?
Not GP, but I really like [] being false in ruby and python because I often want to ask "is this variable that should hold a collection holding a collection of things, or is it empty/false?"
Earlier quoted context omitted.
How are you using Deno with minified code? Do you mean importing a minified script like https://cdn.jsdelivr.net/npm/react/cjs/react.production.min.... ?
I meant bundling your code for production.
Can Deno now be used with MS SQL?
But there's a proper sqlite driver now using the new ffi api support in deno. This didn't exist last time I tried googling db support in deno.
> You can log and style CLI output the same way you do it in the browser’s developer tools: using what you know with console.log > console.log("%cHello World", "color: red"); TIL, neat! If anyone else did too - https://developer.mozilla.org/en-US/docs/Web/API/console#sty... looks great Using alert/confirm/prompt for CLI tools is nice too, makes a lot of sense to build that in and use the web APIs for it.
Earlier quoted context omitted.
In Deno, you use vendoring. https://deno.land/manual@v1.20.1/tools/vendor.md
Is this really a better workflow? I mean it works, but now you do not have a central list of all your external dependencies. Sure they recommend you just do all your imports in a single file and re-export them. But that sounds very tedious and at the end of the day to what advantage? I'm really struggling to see it.
https://github.com/WICG/import-maps https://deno.land/manual@v1.20.1/linking_to_external_code/im...
Earlier quoted context omitted.
A lot of the time that pattern is written, it's because the APIs from the web and Node are different and will break if you call something that's not isomorphic. Perhaps Deno fixes that as well and the pattern isn't needed in the first place. Obviously not every case though.
I'm surprised nobody else has called this out - implementing browser APIs in a non-browser runtime seems like a really bad idea. Take a look at https://developer.mozilla.org/en-US/docs/Web/API/Window - the submitted article seem to have demonstrated literally the only APIs that make sense to implement in a terminal. What would happen when a library tries to call window.location or window.history? Almost none of these…
That said, there are other browser APIs that I would love to see available elsewhere:
- window.crypto as an interface over libcrypto
- window.localStorage and window.sessionStorage as an abstraction over temporary files and an in-memory key/value store, respectively
- window.indexedDb for an in-runtime DB à la Erlang Term Storage or MUMPS
- window.opener, window.parent, window.open(), window.postMessage() for inter-process communication
There's a lot to work with here if you get creative.
Earlier quoted context omitted.
To be fair, CF workers is much older than Deno by a few years. I don’t see us as dismantling anything - do you blame the wind mill or Don Quixote for tilting at them? This is a very competitive space too. Cloudflare is but one player and I don’t think the ones who do well will focus just on the serverless infrastructure piece. It’s more about having a very complete product story that solves pain points better than an…
> They’ve also compounded that velocity by writing most of the runtime in Typescript whereas our runtime is in C++ Can you explain more? Deno doesn't use typescript in the runtime. It is rust and pure js (for globals and wrapping bindings). I don't expect their current architecture to be any less efficient from what I know but it may have changed.
Doesn’t matter though because it’s the same (the only way to run TS is to transpile to JS)
https://github.com/denoland/deno/blob/main/runtime/js/README...
A good chunk of the runtime is in JS, snapshotted and loaded into each isolate. This is a greater memory overhead (and probably slower startup time) than having it written directly in Rust because the snapshot needs to be copied into each isolate. I assume Deno Deploy follows a similar model as Workers where you have many many isolates running concurrently within a process where this overhead may start to matter.
If Deno Deploy gets some scale, I’m curious how they’ll tackle. Less interesting is if they start inlining a good chunk of that functionality into Rust. It’s much more interesting if they figure out some way to improve v8 to reduce this cost. There’s some ways potentially if you could create a COW clonable isolate in v8 efficiently and it could be interesting to collaborate with them on it. But that’s hard. Maybe they have alternate plans.
Earlier quoted context omitted.
I'm surprised nobody else has called this out - implementing browser APIs in a non-browser runtime seems like a really bad idea. Take a look at https://developer.mozilla.org/en-US/docs/Web/API/Window - the submitted article seem to have demonstrated literally the only APIs that make sense to implement in a terminal. What would happen when a library tries to call window.location or window.history? Almost none of these…
window.location could be repurposed as a way to get or change the current working directory? Though the idiom of "window.location = " as a navigation mechanism would not really be portable. That said, there are other browser APIs that I would love to see available elsewhere: - window.crypto as an interface over libcrypto - window.localStorage and window.sessionStorage as an abstraction over temporary files and an in-…
Earlier quoted context omitted.
window.location could be repurposed as a way to get or change the current working directory? Though the idiom of "window.location = " as a navigation mechanism would not really be portable. That said, there are other browser APIs that I would love to see available elsewhere: - window.crypto as an interface over libcrypto - window.localStorage and window.sessionStorage as an abstraction over temporary files and an in-…
if i have to think about what the browser-equivalent operation would be when i'm working with a server-side API, i'm going to use a different language entirely.
The first attempt at this was to port the node standard library to the browser via browserify and the like. This tended to create gigantic JS build artifacts and frequently led to runtime errors when developers used an abstraction that just had no equivalent in the browser (like saving something to disk or opening a separate process). The browser is definitely the lowest common denominator of JS runtimes, even if there are a few browser APIs that just don't make sense in a server environment (like window.history)