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…
Deno Is Webby
151–160 of 215 posts
Re: Deno Is Webby
#152One of the things I love about Deno is that since it implements standard web APIs, many libraries built for the browser just work. For example, I recently made a simple static site generator with Deno to make my blog, and I found that I could use Marked for markdown support simply by importing it like this: import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; // now I can use window.marked()
> import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js';
Doesn't this mean your code won't run if the website https://cdn.jsdelivr.net goes down?
In Node.js you download modules you need, to a local folder under you dev-folder. So you can run and develop and test your code whether you have internet connection or not.
Re: Deno Is Webby
#153This 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 think it's even worse than that, because by being "webby" here Deno has committed itself to alert(); multiple browser vendors (including Mozilla) have advocated removing alert() from the web platform. (They want to do that because alert() "stops the world" by blocking the main thread event loop, and because they make it easy for a site to post a message that appears to come from Chrome itself, or from another websi…
Rich Harris actually disagrees with the browser vendors decision to deprecate alerts. From the article you linked:
> We can't normalise the attitude that collateral damage is the price of progress, even if we accept the premise — which I don't — that removing APIs like alert represents progress. For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow's spec wranglers, is a world in which the web has already lost.
Re: Deno Is Webby
#154One of the things I love about Deno is that since it implements standard web APIs, many libraries built for the browser just work. For example, I recently made a simple static site generator with Deno to make my blog, and I found that I could use Marked for markdown support simply by importing it like this: import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; // now I can use window.marked()
> import ' https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js '; Doesn't this mean your code won't run if the website https://cdn.jsdelivr.net goes down? In Node.js you download modules you need, to a local folder under you dev-folder. So you can run and develop and test your code whether you have internet connection or not.
In Deno, you use vendoring.
Re: Deno Is Webby
#155One of the things I love about Deno is that since it implements standard web APIs, many libraries built for the browser just work. For example, I recently made a simple static site generator with Deno to make my blog, and I found that I could use Marked for markdown support simply by importing it like this: import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; // now I can use window.marked()
> import ' https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js '; Doesn't this mean your code won't run if the website https://cdn.jsdelivr.net goes down? In Node.js you download modules you need, to a local folder under you dev-folder. So you can run and develop and test your code whether you have internet connection or not.
Well... CDNs aren't supposed to go down, but if they do suffer an outage, Deno caches dependencies locally.
If that's still not enough, you can also just download the JS file and import from a local path or use the vendoring feature.
Re: Deno Is Webby
#156Earlier quoted context omitted.
> import ' https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js '; Doesn't this mean your code won't run if the website https://cdn.jsdelivr.net goes down? In Node.js you download modules you need, to a local folder under you dev-folder. So you can run and develop and test your code whether you have internet connection or not.
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.
Re: Deno Is Webby
#157Earlier 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”.
There’s better ways to do this - personally I’ve found the approach taken in this tiny lib very reliable: https://github.com/flexdinesh/browser-or-node/blob/master/sr...
Re: Deno Is Webby
#158Earlier quoted context omitted.
>beforeunload handlers ooh no, how will sites tell me that my free offer will expire if I navigate away? But on the serious side, this is useful for many antiquated apps (e.g. government stuff) that break tons of stuff if you attempt to re-submit a form, use the back button, etc, so I see that causing a ton of problems.
Yeah, especially after having had it for years, business leaders just do not understand why the browser would remove such a useful feature. And then you get questions like “So? Can we just stick with IE 10 then?” I still haven’t found a way to consistently send a request while the tab/browser is closing.
visibilitychange and sendBeacon
Why would you need it to be consistent? Depending on this for anything other than analytics is bad design. It’s like catching sigterm on desktop.
Re: Deno Is Webby
#159Earlier 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.
It seems like a feature that would be better implemented at the IDE/editor level. Paste in a URL and it asks you if you want to add it to package management.
Re: Deno Is Webby
#160Earlier 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”.
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 map neatly to any possible implementation on the server or in a scripting environment.