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.
Deno Is Webby
61–70 of 215 posts
Re: Deno Is Webby
#62Earlier 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”.
Re: Deno Is Webby
#63Think 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
#64I 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
Re: Deno Is Webby
#65This 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…
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").
Re: Deno Is Webby
#66Re: Deno Is Webby
#67> 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.
Re: Deno Is Webby
#68I'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"
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
#69This 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 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
#70Earlier 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.