Live data from Hacker News

Deno Is Webby

blog.jim-nielsen.com

61–70 of 215 posts

Re: Deno Is Webby

#61
post #7

Earlier quoted context omitted.

Deno is also creating a standard library, so that too should reduce the amount of external packages you'll need.

The Deno standard library is not bundled, but separately fetched as a dependency for each embedded file.

That's a pedantic argument, the deno standard library doesn't depend on any other library except itself and deno's core. You can know if you depend on it that you don't have dozens or hundreds of other dependencies, unlike pulling in a random npm package.

Re: Deno Is Webby

#62

Earlier quoted context omitted.

One of the many things about Node that Dahl explicitly wanted to "fix"* when building Deno was that the global namespace should be `window`, because that's what it is in JavaScript's natural habitat. *scare-quotes because the reader might feel strongly opposed to the term, not because I have an agenda

That does seem like it will break a common pattern in web app code that runs both in browsers and on a server (such as a React app with server-side rendering) to determine whether you’re on the browser or the server, which is to check if typeof window === “undefined”.

You should be branching on the existence of `document` to discover if you are running in a DOM context, not `window`. Using `window` to branch SSR and CSR code will also inevitably will give false positives/negatives in workers and worklets when used in libraries.

Re: Deno Is Webby

#63
I agree on the premises, it's nice to have an open standard - in practice the API available on the web is usually a downgrade in developer experience.

Think about the old node library request vs fetch, require vs import/import(). I hope deno has Buffers and I won't have to use atob / btoa.

Re: Deno Is Webby

#64

I cannot help but root for Deno whenever it features on here. It offers such a wonderful potential future for JavaScript. It's not fully-baked yet, but man, it solves so many problems in one fell swoop.

It's so good I worry about the Betamax effect

What betamax effect? Didn't it fail since the cartridge design was worse and also held less tape than vhs?

Re: Deno Is Webby

#65
post #4

This is nice, until its not. I have spent a fair amount of time over the last several years trying to make node act like the browser, or vice versa. It's doubly confusing to juniors who don't understand the difference between a language and a runtime. alert() looks like a standard function and should be specified by the ECMAScript Language Specification. But its actually specified by the HTML standard, because its Wi…

There is a TC39 proposal for a standard library[1]. One of the ideas reserves a URL scheme built in modules. So to import from a language defined standard library you would use the "js" scheme (import Temporal from "js:temporal") and importing from the runtime you could potentially use e.g. "web" scheme (import AudioContext from "web:audio-context").

I really hope we will have something like that. It would both give us the option of never using magical globals and make the distinction clear whether the module comes from the language or the runtime. Although I can see a case where it could get annoying if you are writing for multiple runtimes and need to get e.g. fetch (import fetch from "runtime:fetch").

1: https://github.com/tc39/proposal-built-in-modules

Re: Deno Is Webby

#66
I'm simply unable of not reacting to someone so exhilarantly rejoicing you don't need a third party library for taking user input with cynicism. Am I living in a bubble, or what the hell went wrong here?

Re: Deno Is Webby

#67
post #5

> You Might Not Need NPM If it's like every other JavaScript project I've been on since 2016, it's going to actually require thousands of JavaScript packages and doing everything with it is going to be slow as molasses even on high-end developer workstations.

One benefit of deno on this front is that it _only_ pulls down the js files you actually need. With npm, even if you only import one file from a package, every single other file will also be downloaded to your computer. And probably some test files, a bunch of package-lock files, maybe some branding images. Oh and the same for all the packages it references, too. The storage/download time savings of getting just the js add up a _lot_ more than I expected. I've toyed with deno on a few projects, and my entire deno cache is smaller than any single node_modules directory.

Re: Deno Is Webby

#68

I'm sorry but all those examples and Deno's documentation in general should be in JavaScript. I respect the devs right to choose which ever language they want, but Deno seems to want to be the standard bearer for the power of scripting and web standards [1]. If that's the case, then they are causing more harm than good by focusing exclusively on TypeScript, which isn't a language as much as a set of macros on top of…

> not promoted as some sort of better alternative to JavaScript, because it's really not. This leaves me skeptical if you have extensive experience with Typescript. It's way more than "oh this is a number not a string." It's "you forgot this property on an object's return type that you built from a response value" or "your Redux reducer doesn't handle all of the possible action types so it will crash at run time"

Deno attempts to provide a standalone tool for quickly scripting complex functionality.

That's from Deno's home page. What I'm talking about isn't whether TypeScript is useful for some projects, as that has been proven beyond question. What I'm saying is that as a tool for "quickly scripting", as claimed by Deno, it is unnecessary and counter productive to JavaScript as a whole.

My point is that the Deno project is a high profile JavaScript engine which, in my opinion, is misguided in their end-user focus on TypeScript and I think it's a shame.

Devs are always searching for the "right" way to do things, and can be easily convinced to do things like misuse "const" because some pedantic fool convinced them it was sorta like type safety, and therefore not using it was "baaaaaaad". And the sheep followed and now const is used everywhere, despite the clear and unambiguous intended functionality of the feature's designers, who added it as a way of tracking, incredibly, constants and nothing else.

It would be nice if we saved a generation of devs another debacle like const, NoSQL databases and UML.

Re: Deno Is Webby

#69
post #4

This is nice, until its not. I have spent a fair amount of time over the last several years trying to make node act like the browser, or vice versa. It's doubly confusing to juniors who don't understand the difference between a language and a runtime. alert() looks like a standard function and should be specified by the ECMAScript Language Specification. But its actually specified by the HTML standard, because its Wi…

This has also unfortunately been my experience, even when working with developers that have several years of experience writing JS.

There seems to be a big gap in knowledge when it comes to boundaries between the language specification, runtimes, and innate abilities.

People consistently confused about why they can't use JSX without a build-step, not understanding that JSX isn't "real", why doesn't fetch() work in Node, why does code in my Next.js app break randomly (server vs client render context).

Lot of pain in trying to explain to folks that a browser and Node are two different universes that happen to speak the same general language.

There's too much magic in this ecosystem and not enough emphasis placed on taking the time to understand the tools you work with, IMO.

Re: Deno Is Webby

#70
post #55

Earlier quoted context omitted.

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?"

[] is truthy in Ruby. Only false and nil are falsy.

Yeah, sadly zero is not falsy in Ruby.
Post reply on HN