Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Is Webby

blog.jim-nielsen.com

Post reply on HN
Print view View original

161–170 of 215 posts

Re: Deno Is Webby

#161

Post by esprehn »

lucacasonato wrote: post #62
tshaddox wrote: post #39

Earlier quoted context omitted.

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.

Window is not available in a worker context. What's a situation where you have a window available and no document?

Re: Deno Is Webby

#162

Post by afiori »

moron4hire wrote: post #78
afiori wrote: post #28

Earlier quoted context omitted.

ecmascript now has both `globalThis` and `self` that can act as global namespace (they all point to the same object except in workers as window and globalThis cannot be used in workers)

No, `globalThis` is available in workers. It points to `self`. On the page, `globalThis` points to `window`. `globalThis` thus becomes the one, safe, global reference you can make for code that runs in both pages and workers.

Thanks, I misunderstood this.

Re: Deno Is Webby

#163

Post by ihateolives »

hajile wrote: post #145
gavinray wrote: post #69

Earlier quoted context omitted.

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 No…

JS is the only programming language I know of where people read zero docs and still decide they know how to write it. They wouldn't dream of this with C, Java or even python (even though these probably work exactly like other languages they know -- unlike JS), but for some reason perfectly smart developers make this crazy decision all the time.

> They wouldn't dream of this with C, Java or even python (even though these probably work exactly like other languages they know -- unlike JS), but for some reason perfectly smart developers make this crazy decision all the time.

It's because they can. You can cobble something together and it works or seems to work. It may fail later down the chain but browsers accept all sorts of hackery, because they have been historically doing this for a long time. Before there was Javascript you could write broken HTML, nest elements wrong and browsers still figured out a way to deal with it. The expectations of half-assed solutions has always been there on the web.

Re: Deno Is Webby

#164

Post by sjnu »

mediumdeviation wrote: post #160
treyhuffine wrote: post #49

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…

Do you have a reasonable example of why a library that would call location or history?

All I can think of is "using query string as getenv() for random debug hacks" or "using history as a hack to synchronously reach the structured clone algorithm", neither of which a library should do (but both easily emulatable).

Re: Deno Is Webby

#165

Post by binarynate »

esprehn wrote: post #161
lucacasonato wrote: post #62

Earlier quoted context omitted.

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.

Window is not available in a worker context. What's a situation where you have a window available and no document?

Deno

Re: Deno Is Webby

#166

Post by binarynate »

nightski wrote: post #156
int_19h wrote: post #154

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.

For scripts, it's pretty sweet to be able to import dependencies directly via URL without needing to do an `npm init` and `npm install`. For larger projects (like my static site generator), I didn't find it tedious to import from a central deps.ts file, although I admit that importing from a relative path like '../../deps.ts' is not as quite as nice as importing by package name like in Node. I'm OK with that the tradeoff, though, especially since it matches the way imports work in the browser.

Re: Deno Is Webby

#167

Post by dmitriid »

binarynate wrote: post #166
nightski wrote: post #156

Earlier quoted context omitted.

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.

For scripts, it's pretty sweet to be able to import dependencies directly via URL without needing to do an `npm init` and `npm install`. For larger projects (like my static site generator), I didn't find it tedious to import from a central deps.ts file, although I admit that importing from a relative path like '../../deps.ts' is not as quite as nice as importing by package name like in Node. I'm OK with that the trad…

What about transitive dependencies?

Re: Deno Is Webby

#168

Post by jahewson »

moron4hire wrote: post #78
afiori wrote: post #28

Earlier quoted context omitted.

ecmascript now has both `globalThis` and `self` that can act as global namespace (they all point to the same object except in workers as window and globalThis cannot be used in workers)

No, `globalThis` is available in workers. It points to `self`. On the page, `globalThis` points to `window`. `globalThis` thus becomes the one, safe, global reference you can make for code that runs in both pages and workers.

‘self’ works on pages too.

Re: Deno Is Webby

#169

Post by russellbeattie »

c0balt wrote: post #128
russellbeattie wrote: post #68

Earlier quoted context omitted.

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…

How are NoSQL databases "bad" and should in general? The term "NoSQL" in itself is very inclusive and might include databases such as redis, elasticsearch or apache cassandra.a It's important to choose the right tool for the job and SQL/ relational DBs fit many usecases but are not always the right choice. Especially when handling massive amounts of data, that can fit into structures such as wide-column stores, datab…

NoSQL is a good solution for the 1% of projects that need it. It sounds like you had great success with it, congrats.

Otherwise, it just ends up being a big flat in-memory table with a badly implemented version of SQL welded on top, written by developers who never bothered to learn SQL or database management in the first place. Then a bunch of fad followers jump on the bandwagon, and before you know it, we have a decade of idiots blathering on about "web scale" technologies.

That's the debacle I'm talking about. Millions of man hours wasted.

Re: Deno Is Webby

#170

Post by Xenoamorphous »

gavinray wrote: post #69
dexwiz wrote: 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 No…

> why doesn't fetch() work in Node

Actually it does now! Or it will soon.

https://fusebit.io/blog/node-fetch/?utm_source=www.google.co...

Post reply on HN