does Deno have a solid web framework? Next.js is somewhat being worked on / forked for, like Aleph.js
A whole website in a single JavaScript file
91–100 of 170 posts
Re: A whole website in a single JavaScript file
#92Earlier quoted context omitted.
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 t…
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 differe…
IMO the silver lining to Deno is incredibly simple: it’s compatibility with the web platform. I’m not sure what you mean by not compatible with the larger ecosystem, as Deno is basically spec compliant except for the Deno namespace (which you can polyfill out).
If you haven’t experienced any pain authoring isomorphic JS with Node, that’s great! My experience has been the opposite of that. But with Deno, everything feels completely web native. You never need to worry about modules, syntax, platform features (even localStorage!), or packages… it just works.
On top of that, all the built-in tooling is high quality and I’ve never felt the need to replace them. A formatter, test runner, bundler, type checker, doc generator, benchmarker, and even the built in deployment platform. In fact, I’ve never experienced a more smooth deployment experience anywhere. There is nothing this cohesive in Node.
If you need one more reason, Deno is arguably the most secure runtime in the world. I would not be surprised to see more corporations start to use Deno for user submitted programs as we’ve seen recently with Supabase and Slack, for this reason.
Re: A whole website in a single JavaScript file
#93Earlier quoted context omitted.
The request headers have no-cache set. I assume this is because it's in a live developer playground page instead of a production deployment.
> I assume this is because it's in a live developer playground page instead of a production deployment. Not how I read it - the first link is to a site deployed via "deno deploy", the last one is a link to the same content in a playground. >> Hosted on Deno Deploy, this little website is able to acheive a perfect pagespeed score. Serviced from an anycast IP address over encrypted HTTP from 29 data centers around the…
You know what's funny I'm a fool that still had "disable cache" checked in the dev tools from a previous session when I was checking the request headers. At the current moment now that I have unchecked that in dev tools it is actually respecting the cache for those images. I can't definitively say if that is different than before but either way at least it seems cache is verifiably working with it normally now that I have that unchecked.
Re: A whole website in a single JavaScript file
#94Seemed pretty simple to add a bagel route https://dash.deno.com/playground/cold-parrot-17 with page not found handling. Love the minimalistic nature of this.
Re: A whole website in a single JavaScript file
#95Earlier quoted context omitted.
> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.
>People are already building JavaScript monstrosities to serve entirely static blog content. I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. I started talking to a junior developer the other day about server side…
Since forcing the industry to realize the possibility of server-side rendering at gunpoint is oppressive and impractical I suppose that there is some sense in which we need "accept that's how websites are built now," but there's certainly no problem with speaking about the benefits of server-side rendering and drawbacks of JS-ification.
> 2-3mb of JS download (that will be cached aggressively)
It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.
Re: A whole website in a single JavaScript file
#96Earlier quoted context omitted.
>People are already building JavaScript monstrosities to serve entirely static blog content. I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. I started talking to a junior developer the other day about server side…
I would like to see web apps move in the direction of server-side rendered static pages on initial load, and then progressively hydrate the app with data from the back-end on demand. Rails does this surprisingly well using Stimulus with web sockets to mediate the exchange of events and data between the client and server layers. Similar strategies are used in Phoenix Live View apps. Load static markup and data -> requ…
Some of the jamstack frameworks like Gatsby do this. They turn into SPAs after the first page of pre-rendered HTML is served.
Re: A whole website in a single JavaScript file
#97Earlier quoted context omitted.
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.
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…
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.
Re: A whole website in a single JavaScript file
#98Since a bunch of people are setting up a straw-man to criticize this post for "not just serving plain HTML" I'll share my opinions on this. Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, they are going to use it to build a monolith application to get content from a database, or a service, then generate server-rendered pages, and also host an API from the same codebase, or…
You can use a service worker proxy to cache and serve files to an application, which keeps things both fast and also with raw uncompiled html and JS file.
Re: A whole website in a single JavaScript file
#99Earlier quoted context omitted.
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 differe…
IMO the silver lining to Deno is incredibly simple: it’s compatibility with the web platform. I’m not sure what you mean by not compatible with the larger ecosystem, as Deno is basically spec compliant except for the Deno namespace (which you can polyfill out). If you haven’t experienced any pain authoring isomorphic JS with Node, that’s great! My experience has been the opposite of that. But with Deno, everything fe…
To be clear, IMHO, Deno looks fine for what it is. The features are great. The cons ironically mostly boil down to "it's not node", i.e. ejecting a non-trivial app from CRA into some vite setup is doable with some effort, but migrating to Deno is, charitably, likely a monumental task that nobody would ever undertake, even considering the upsides.
At the risk of diving too deep into opinion territory, I'm not all that enthusiastic about isomorphic JS (and I say this as a someone who's worked on a isomorphic framework). The promise of low learning curve is certainly appealing, especially for those still in the learning phase, but at least in my experience I find that isomorphism falls a bit short in practice because server and client semantics are just... different.
When I talk about compatibility, I'm specifically talking about non-platform compatibility, i.e. library authors need to consciously target Deno if they want to support it, and the way to do so may be entirely non-trivial (e.g. the lengths that postgres.js goes to, compared to slonik, comes to mind). But most of the JS ecosystem lives on NPM and imports things willy-nilly with no regard for whether their thing will work in Deno because that's the path of least resistance. This is not Deno's fault of course, just an unfortunate reality.
Re: A whole website in a single JavaScript file
#100Earlier quoted context omitted.
> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.
> monstrosities why do you have to sprinkle that snark + negativity in there? it implies a toxic role of "you are superior" and "people who use JavaScript to serve static blog content" are inferior. why can't we all just get along? especially in this tight-knit programming community that is supposed to be full of love and collaboration. in today's modern day of inclusion and emphasis on mental health, you're spreadin…
> full of love and collaboration
Why do you have to sprinkle that positivity in there? It implies a toxic role of “I am naive”.
Ah, I’m just jerking your chain. For the most part I agree with you. Calling the way other people do things a “monstrosity” really is uncalled for.