Live data from Hacker News

A whole website in a single JavaScript file

deno.com

31–40 of 170 posts

Re: A whole website in a single JavaScript file

#31
Since 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 something similar.

Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views.

If you haven't experienced this already, you will come away with one of two conclusions.

1. Wow, this is so much fun, as long as I stay on the happy path of ... Rails ... Django ... ASP.net.

2. Wow, setting up all these moving parts really sucks' I'm mostly writing configuration files, and then Googling the error messages when I inevitably screw something up.

What I think Deno is trying to do is make the process of getting a server side rendered application with modern tooling running with minimal ceremony, while still enabling the developer to customize the system and build things that are not covered by the documentation guides. In addition, their solution is one that can be more easily hosted on edge servers than most other options out there.

I'm glad they are doing it, because it's a sorely lacking area of modern web development. They only other people who are taking this on in a meaningful way that I am aware of are Remix. I would be happy for there to be more entrants into this field.

Best of luck to everyone out there.

Re: A whole website in a single JavaScript file

#33
post #25
post #5

Earlier quoted context omitted.

Aaron from Deno here. Of course it's producing HTML as an output, but the point is that you can use JSX and familiar technologies like tailwind to dynamically generate that HTML at edge vs client side. And unlike a pure static site, you can add API or form routes

Oh. So you've reinvented PHP. Nice.

This is a very lazy comment. I'm sure it makes you feel smart, but it drags down the entire conversation, and doesn't add anything of value. You seem very capable and accomplished, so I'm confused why you would spend any of your time to simply shit-post on someone who is trying to build something of use to many people.

Re: A whole website in a single JavaScript file

#34

I don't think most of the people commenting here realize that the entire site loads just fine with Javascript disabled. Essentially this is HTML getting generated on the server. The fact that it is in Deno rather than PHP, Ruby or Python is the point of the article.

Thank you. Being unfamiliar with Deno, I was trying to figure out what was loading the libraries when there was only one request/response over the wire. I of course was making the assumption that the single JS file was being run in the browser, not on the server.

Re: A whole website in a single JavaScript file

#35

This starts to make sense when you consider the self-flagellation of a full server-side-rendering production setup that has existed over the past decade, to the point many SPA products completely give up on SSR - or nowadays throw themselves at the walled garden of Vercel/Next.js etc to solve it for them.

There's plenty of non-Vercel attempts at this and it's kind of table stakes for frameworks hoping to get popular. There is a push for server-first/MPA app development where SSR is assumed to be the baseline. Remix [1], Qwik [2], and Marko [3] are in that camp. I'm not sure about Remix but the other two have a goal of authoring the entire app components but only sending the JS needed for the parts that can change on the client.

[1] https://remix.run/ [2] https://github.com/BuilderIO/qwik [3] https://markojs.com/

Re: A whole website in a single JavaScript file

#37
post #16

Earlier quoted context omitted.

You can see for yourself with the provided Pagespeed metrics that the root document was served in around 30ms (corresponding to TTFB). If you can elaborate on how statically-served HTML would render orders of magnitude faster than server-sider-rendered HTML with a similar response time, I'd love to hear it.

Unless the server runs at negative cycles per second, more cycles means more time taken. Did i miss-math?

You've shown a way to add multiples of ~0.0000000003 seconds to the time but haven't explained how the page is going to go from .01 seconds to 1.0 seconds as a result when TTFB is 0.03 seconds.

Re: A whole website in a single JavaScript file

#38

Earlier quoted context omitted.

It's not. Next.js works on any platform supporting Node, and Vercel supports more than just Next.js. They support dozens of other frameworks.[0] They do promote Next.js on Vercel, but they don't stop you from using other systems. [0]: https://vercel.com/new/templates

Ever since Vercel killed `now`'s ability to serve an index.html with `now .`, I stopped being a fan. That and the pricing blunders have unfortunately pushed me away. On the other hand, https://docs.ycombinator.lol/ has been running for years without me ever having to worry once, so there's that. Maybe it's time to give them another try.

That never stopped working. Neither on the edge side (as your live site indicates, which has been edge cached for 109 days in San Francisco), or on the deployment site, as the example below shows:

Try it out: https://hi-there.vercel.app

  ▲  /tmp/ mkdir hi-there
  ▲  /tmp/ cd hi-there
  ▲  hi-there/ echo 'hi sillysaurusx' > index.html
  ▲  hi-there/ vc
  […]
  Inspect: https://vercel.com/rauchg/hi-there [690ms]
  Production: https://hi-there.vercel.app [copied to clipboard] [9s]
In under 10s which includes the project setup and linking prompts. The main difference is that `now` got shorter to `vc`

Happy to hear more feedback on pricing. Please reach out to rauchg@vercel.com

Re: A whole website in a single JavaScript file

#40
post #38

Earlier quoted context omitted.

Ever since Vercel killed `now`'s ability to serve an index.html with `now .`, I stopped being a fan. That and the pricing blunders have unfortunately pushed me away. On the other hand, https://docs.ycombinator.lol/ has been running for years without me ever having to worry once, so there's that. Maybe it's time to give them another try.

That never stopped working. Neither on the edge side (as your live site indicates, which has been edge cached for 109 days in San Francisco), or on the deployment site, as the example below shows: Try it out: https://hi-there.vercel.app ▲ /tmp/ mkdir hi-there ▲ /tmp/ cd hi-there ▲ hi-there/ echo ' hi sillysaurusx ' > index.html ▲ hi-there/ vc […] Inspect: https://vercel.com/rauchg/hi-there [690ms] Production: https:/…

Happy to hear that. It did, at one point -- I am quite certain of this -- but that was years ago.

I think it was in the transition between now and vercel. Back then, `now` had some sort of requirement where it only worked automatically if the folder had a package.json file. A plain index.html file required configuration. Delighted to see that this is no longer the case.

I'll give `vc` a shot.

The pricing issues stemmed from the fact that I use updown.io to monitor my domains. Since it pings them every 15 minutes or so, and since vercel spins up servers on demand, that means I was paying for essentially 24/7 service, which was an unwelcome bill over what I signed up for. Customer support gave a 50% refund, which I appreciated, and I've downgraded to a free account ever since.

Post reply on HN