4 ms·

I mean, this is a "single file website" in the sense that `<iframe src="https://google.com"></iframe> https://google.com"></iframe>` is a "search engine impleme

by lhorie 5y ago

I mean, this is a "single file website" in the sense that `<iframe src="https://google.com"></iframe> https://google.com"></iframe>` is a "search engine implementation in one line of code". The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step. It's really not that different than doing regular Node.js development with a committed node_modules (hi, Google), except that if node.land or crux.land go down, you've lost your reproducibility. The thing about "familiar/modern techonologies" seem like superficial vanity. A vanilla Node.js equivalent might look something like this import {createServer} from 'http' import {parse} from 'url' const route = path => { switch (path) { case '/': return home() case '/about': return about() default: return error() } } const home = () => `Hello world` // etc... createServer((req, res) => { res.write(route(parse(req.url))) res.end() }).listen(80) Which is really not anything to write home about, nor an intimidating monstrosity by any measure. Serving cacheable HTML is really not rocket science, it simply does not require "the latest and greatest" anything.

krapp 5y ago
>The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step. We used to call those script tags back in the olden days...
hamandcheese 5y ago
> except that if node.land or crux.land go down, you've lost your reproducibility. I wouldn’t say you lost it, I’d say you never had it in the first place.
CreepGin 5y ago
Now, add jsx and ssr to your example, deploy it, then compare with the deno version in terms of performance, code length, and dev time.
- lhorie 5y ago
  Why? Just so you can tell another developer that there's a compiler transpiling non-standard syntax into function calls that concatenate strings at runtime? While the output HTML that the user sees is exactly the same? That's exactly why I'm calling out to be library vanity. My example is SSR, that's literally the default baseline. It doesn't make a very strong argument to imply my 5 min thing will somehow be worse if only you get to decide what random garbage to add to it to make the alternative look better. E.g. Make hegel types work in the original and then let's talk loss of productivity from arbitrary decisions. Deployment for a vanilla node.js thing is as simple as adding `node index` as the entry point in your favorite provider (because they all have node.js images these days), I've had such a thing humming along for years. Again, it's really not rocket science.
  - CreepGin 5y ago
    Different use cases. You equate SSR to just serving strings. Others need to use jsx + SSR together (be it personal preference or hard requirement). Imperative vanilla code vs Declarative components. Both should have their place.
    - kokanee 5y ago
      I'm with lhorie. SSR literally is about serving strings... you're the one equating it with server-side JSX. JSX is syntactical sugar that abstracts vanilla JS which in turn renders strings. Rendering HTML on the server has always been the standard way of doing it, so the whole concept of SSR is funny to me. We've been creating new abstractions that trade old problems for new problems, and then newer abstractions that trade out problems again, since the dawn of time.
      - CreepGin 5y ago
        My point is that it doesn't matter, serving strings or rendering react comps. For folks who has to work with jsx + ssr for one reason or another, they will appreciate what deno's team has done here. And yeah sure, you can always take a simple demo app with Declarative components and turn it into a few lines of imperative vanilla code and say it's simpler this way. But then what? How are you tackling scaling, organization, composability, and deployment? (these are the real things the deno team is trying to show here, are they not?) By the time you design everything out and put all these in place for your vanilla code, you'll end up spending just as much resources (if not more) as you'd have for using Declarative components with deno.
crowlKats 5y ago
I wouldnt say an iframe and this are in any way shape or form comparable. this is a "full-fledged" website. > except that if node.land or crux.land go down, you've lost your reproducibility. Dependencies are cached. This is no different from if npm would go down. > The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step Given that this seems interesting to you, it seems you haven't heard of Deno (https://deno.land https://deno.land). It is not related to node in terms of environment, its a new completely separate runtime. In regards to your node example, this is fairly different: the dependency pulled in from deno.land is a wrapper around the built-in http server, which does various error handling for you and simplifies the usage. The router isnt a simple switch statement either; its a URLPattern (the web's version of path-to-regexp) based minimal router. Campring these to the node built-ins isnt exactly a fair comparison I would say. Also on top of this, with node you need a configuration to get typescript working, then you need a package.json, etc etc.
- lhorie 5y ago
  Yes, I know what Deno is, and when I say "semi-interesting", I mean I'm trying to find a silver lining to praise Deno for. To clarify, the similarity is that this claims to be a "single file" thing by importing the meat of the functionality from elsewhere. Which is not really interesting at all, because using batteries to make websites was already a thing with PHP in the 90s. Or, as I mentioned, it's not that different from just using express or path-to-regexp or lodash or whatever in a typical Node.js setup. Caching dependencies is very different from general reproducibility. Committing node_modules guarantees that the app works even if the NPM registry were to implode. Try to deploy your deno thing from a cold state (e.g. maybe you're moving to a different AWS region or a different provider or whatever) while there's a deno.land outage and it will blow up. I'm actually curious what this caching story looks like for large cloud fleet deployments. Hopefully you don't have every single machine individually and simultaneously trying to warm up their own caches by calling out to domains on the internet, because that's a recipe for network flake outs. At least w/ something like yarn PNP, you can control exactly how dep caches get shuttled in and out of tightly controlled storage systems in e.g. a cloud CI/CD setup using AWS spot instances to save money. These deno discussions frankly feel like trying too hard to justify themselves. It's always like, hey look Typescript out of the box. Um, sure, CRA does that too, and it does HMR out of the box to boot. But so what? There's a bunch of streamlined devexp setups out there, from Svelte to Next.js to vite-* boilerplates. To me, deno is just another option in that sea of streamlined DX options, but it isn't (yet) compatible with much of the larger JS ecosystem. </two-cents>
deleted 5y ago
[deleted]

by lhorie 5y ago

krapp 5y ago

>The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step. We used to call those script tags back in the olden days...

hamandcheese 5y ago

> except that if node.land or crux.land go down, you've lost your reproducibility. I wouldn’t say you lost it, I’d say you never had it in the first place.

CreepGin 5y ago

Now, add jsx and ssr to your example, deploy it, then compare with the deno version in terms of performance, code length, and dev time.

lhorie 5y ago
Why? Just so you can tell another developer that there's a compiler transpiling non-standard syntax into function calls that concatenate strings at runtime? While the output HTML that the user sees is exactly the same? That's exactly why I'm calling out to be library vanity. My example is SSR, that's literally the default baseline. It doesn't make a very strong argument to imply my 5 min thing will somehow be worse if only you get to decide what random garbage to add to it to make the alternative look better. E.g. Make hegel types work in the original and then let's talk loss of productivity from arbitrary decisions. Deployment for a vanilla node.js thing is as simple as adding `node index` as the entry point in your favorite provider (because they all have node.js images these days), I've had such a thing humming along for years. Again, it's really not rocket science.
- CreepGin 5y ago
  Different use cases. You equate SSR to just serving strings. Others need to use jsx + SSR together (be it personal preference or hard requirement). Imperative vanilla code vs Declarative components. Both should have their place.
  - kokanee 5y ago
    I'm with lhorie. SSR literally is about serving strings... you're the one equating it with server-side JSX. JSX is syntactical sugar that abstracts vanilla JS which in turn renders strings. Rendering HTML on the server has always been the standard way of doing it, so the whole concept of SSR is funny to me. We've been creating new abstractions that trade old problems for new problems, and then newer abstractions that trade out problems again, since the dawn of time.
    - CreepGin 5y ago
      My point is that it doesn't matter, serving strings or rendering react comps. For folks who has to work with jsx + ssr for one reason or another, they will appreciate what deno's team has done here. And yeah sure, you can always take a simple demo app with Declarative components and turn it into a few lines of imperative vanilla code and say it's simpler this way. But then what? How are you tackling scaling, organization, composability, and deployment? (these are the real things the deno team is trying to show here, are they not?) By the time you design everything out and put all these in place for your vanilla code, you'll end up spending just as much resources (if not more) as you'd have for using Declarative components with deno.

crowlKats 5y ago

I wouldnt say an iframe and this are in any way shape or form comparable. this is a "full-fledged" website. > except that if node.land or crux.land go down, you've lost your reproducibility. Dependencies are cached. This is no different from if npm would go down. > The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step Given that this seems interesting to you, it seems you haven't heard of Deno (https://deno.land https://deno.land). It is not related to node in terms of environment, its a new completely separate runtime. In regards to your node example, this is fairly different: the dependency pulled in from deno.land is a wrapper around the built-in http server, which does various error handling for you and simplifies the usage. The router isnt a simple switch statement either; its a URLPattern (the web's version of path-to-regexp) based minimal router. Campring these to the node built-ins isnt exactly a fair comparison I would say. Also on top of this, with node you need a configuration to get typescript working, then you need a package.json, etc etc.

lhorie 5y ago
Yes, I know what Deno is, and when I say "semi-interesting", I mean I'm trying to find a silver lining to praise Deno for. To clarify, the similarity is that this claims to be a "single file" thing by importing the meat of the functionality from elsewhere. Which is not really interesting at all, because using batteries to make websites was already a thing with PHP in the 90s. Or, as I mentioned, it's not that different from just using express or path-to-regexp or lodash or whatever in a typical Node.js setup. Caching dependencies is very different from general reproducibility. Committing node_modules guarantees that the app works even if the NPM registry were to implode. Try to deploy your deno thing from a cold state (e.g. maybe you're moving to a different AWS region or a different provider or whatever) while there's a deno.land outage and it will blow up. I'm actually curious what this caching story looks like for large cloud fleet deployments. Hopefully you don't have every single machine individually and simultaneously trying to warm up their own caches by calling out to domains on the internet, because that's a recipe for network flake outs. At least w/ something like yarn PNP, you can control exactly how dep caches get shuttled in and out of tightly controlled storage systems in e.g. a cloud CI/CD setup using AWS spot instances to save money. These deno discussions frankly feel like trying too hard to justify themselves. It's always like, hey look Typescript out of the box. Um, sure, CRA does that too, and it does HMR out of the box to boot. But so what? There's a bunch of streamlined devexp setups out there, from Svelte to Next.js to vite-* boilerplates. To me, deno is just another option in that sea of streamlined DX options, but it isn't (yet) compatible with much of the larger JS ecosystem. </two-cents>

deleted 5y ago

[deleted]