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

A whole website in a single JavaScript file

deno.com

Post reply on HN
Print view View original

71–80 of 170 posts

Re: A whole website in a single JavaScript file

#71

Post by lhorie »

CreepGin wrote: post #61
lhorie wrote: post #46

Earlier quoted context omitted.

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

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.

SSR means server-side rendering. String-ness is irrelevant (everything is a string as far as HTTP is concerned). The difference is between serving HTML vs JS for the purposes of generating a DOM tree. The article is using nanossr specifically to server HTML, MPA-style. My thing is using template string, which is what systems like lit-html use for their flavor of "declarative components"

Whether one wants to squint at this and think of React is neither here nor there, IMHO. Svelte, for example, cannot implement this website in this MPA format with only one `.svelte` file, but I don't think it's necessarily more verbose or slower to develop with than, say, Gatsby.

Re: A whole website in a single JavaScript file

#72

Post by epolanski »

MuffinFlavored wrote: post #63
giantrobot wrote: post #55

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

While I don't like as well the tone of previous poster, I think that any field should have a healthy dose of "elitism" and "competition" and the previous user is right.

Re: A whole website in a single JavaScript file

#73

Post by chrisco255 »

Dangeranger wrote: post #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…

There is no need to manually set up your own Node.js SSR framework for React. Next.js exists, and is quite mature at this point. Next.js is quite fun. Highly recommend it.

The novel thing, for this, in my mind, is the edge hosting.

Re: A whole website in a single JavaScript file

#74

Post by [deleted] »

lhorie wrote: post #42

I mean, this is a "single file website" in the sense that ` " rel="nofollow">https://google.com"> ` 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…

[deleted]

Re: A whole website in a single JavaScript file

#75

Post by [deleted] »

MuffinFlavored wrote: post #63
giantrobot wrote: post #55

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

[deleted]

Re: A whole website in a single JavaScript file

#77

Post by redleader55 »

lucacasonato wrote: post #7
dmitrygr wrote: post #3

"time to interactive: 1.0s / first content paint 1.0s" My man, let me introduce you to ... HTML. It has "time to interactive" at 0.0 seconds and content paints instantly!

I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.

I know it's taken from their marketing lingo, but edge makes sense only if you have a "core". This demo app doesn't use that model. It's just "cloud", or lambda if you want.

I'm not sure Deno(the service, not Deno the language) are actualy proposing a model - similar to Cloudflare, for example - where you have your infra somewhere and they only host the "edge", in a CDN, or spread around the world.

Re: A whole website in a single JavaScript file

#78

Post by evilduck »

Dangeranger wrote: post #68
ramesh31 wrote: post #62

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

At the risk of sounding rude, what you're describing has been the status quo for data-heavy SPA scenarios for a couple years. NextJS, NuxtJS, Angular Universal, Gatsby, they all allow you to preload data into a server side render and then let the client side JS take over on demand.

Re: A whole website in a single JavaScript file

#79

Post by cxr »

suprfsat wrote: post #12
dmitrygr wrote: post #8

Earlier quoted context omitted.

The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML

The demo is literally a static site generator that generates HTML

It's not, unless "static site generator" is one of those terms (like "literally" or "REST"[0]) that has morphed to mean the opposite of what it was supposed to mean. (Not to be confused with "serverless", which never meant what the word suggests.)

This application is generating HTML on the server, but so does PHP. A Web site backed by a PHP application is the antithesis of a static site.

0. https://news.ycombinator.com/item?id=23672561

Re: A whole website in a single JavaScript file

#80

Post by kokanee »

CreepGin wrote: post #61
lhorie wrote: post #46

Earlier quoted context omitted.

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

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 trade out problems again, since the dawn of time.

Post reply on HN