Live data from Hacker News

A whole website in a single JavaScript file

deno.com

61–70 of 170 posts

Re: A whole website in a single JavaScript file

#61
post #46

Earlier quoted context omitted.

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.

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.

Re: A whole website in a single JavaScript file

#62

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…

> 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 rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.

Re: A whole website in a single JavaScript file

#63

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…

> 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 spreading hate towards people who use JavaScript to serve static blog content and talking down to them. not every 2022 of you, in my opinion.

let's work to get rid of the culture where you imply somebody else's code project doesn't meet your standards, and that since they wrote it, they are dumber than you for making poor design decisions in your opinion.

Re: A whole website in a single JavaScript file

#64

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…

> 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.

Perhaps, but if your goal is to turn a pile of markdown/aciidoc/rst files into a blog, there are better and more purpose built tools for that. i.e. Jekyll, Hugo, Gatsby, 11ty.

Re: A whole website in a single JavaScript file

#65

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…

>"tight-knit programming community that is supposed to be full of love and collaboration."

Now you owe me a coffee and a monitor.

Re: A whole website in a single JavaScript file

#66

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.

> Essentially this is HTML getting generated on the server. Not a web developer. How is this different from CGI or a regular web server? This an honest question - I don't understand the significance.

it is not different.

CGI is replaced by JS

Apache/nginx is replaced by CDN

web server is replaced by edge nodes (aka, glorified runtimes automagically spread across many endpoints)

Re: A whole website in a single JavaScript file

#67

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.

> Essentially this is HTML getting generated on the server. Not a web developer. How is this different from CGI or a regular web server? This an honest question - I don't understand the significance.

Yes, everything old is new again. I just browsed the docs, but it seems it's not so different, other than it's automatically run on servers all over the world. Temporarily, this is for free. Also, it automatically updates after pushing a commit to GitHub, which seems nice.

Re: A whole website in a single JavaScript file

#68

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.

>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 -> request more data if you need -> send events and data to the server -> respond with the new state to display if different than the client’s version.

Re: A whole website in a single JavaScript file

#69

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.

> Essentially this is HTML getting generated on the server. Not a web developer. How is this different from CGI or a regular web server? This an honest question - I don't understand the significance.

[deleted]

Re: A whole website in a single JavaScript file

#70

Earlier quoted context omitted.

> Essentially this is HTML getting generated on the server. Not a web developer. How is this different from CGI or a regular web server? This an honest question - I don't understand the significance.

Yes, everything old is new again. I just browsed the docs, but it seems it's not so different, other than it's automatically run on servers all over the world. Temporarily, this is for free. Also, it automatically updates after pushing a commit to GitHub, which seems nice.

> Also, it automatically updates after pushing a commit to GitHub, which seems nice.

also not new, but you know that already :)

Post reply on HN