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

101–110 of 170 posts

Re: A whole website in a single JavaScript file

#101

Post by orange8 »

ramesh31 wrote: post #62
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.

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

Look at the bright side... more $$$ for your efforts.

Re: A whole website in a single JavaScript file

#103

Post by mark_and_sweep »

adriangrigore wrote: post #84

I personally find it insane to use the monstrosity in terms of loc and complexity that the v8 engine is to generate a static HTML web site. I also disagree with other JS based static site generators because of the above reasons. I strongly believe it's a bad idea to have to locally install nodejs or deno and write JavaScript to generate a few HTML pages. Also, I disagree with plain HTML because of duplication. http:/…

Glad to hear that you prefer shell scripting, but please consider that there are many (web) devs out there who prefer JavaScript:

"Many [devs] are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. (...) Many developers, we think, prefer web-first abstraction layers." -- https://deno.com/blog/the-deno-company

Re: A whole website in a single JavaScript file

#104

Post by cutler »

evilduck wrote: post #78
Dangeranger wrote: post #68

Earlier quoted context omitted.

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.

Have you actually had a look at Rails 7 with Turbo? It's nothing like what you're describing with NextJS etc. in that it aims to keep Javascript to an absolute minimum.

Re: A whole website in a single JavaScript file

#105

Post by ehnto »

chrisco255 wrote: post #73
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.

But just like all other frameworks, the cost isn't just getting it started, it's learning the framework, learning the ecosystem, and slowly building up your knowledge of the edge cases when you start moving past it's limits.

Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've now got all the complexity of a server-side monolith and a frontend framework, with the added bonus complexity of components that have to switch between client and server-side contexts, then state management and hydration across that boundary as well.

Now people are going to say "Ha, idiot, you just simply..." but that's just part of the learning, so you're in no better place with Next.js/SSR in general unless you want to build an interactive application. This isn't against Next.js by the way, I did enjoy it when I needed it, it's just that there's no avoiding some of the inherent domain problems regardless of which framework you pick.

Re: A whole website in a single JavaScript file

#107

Post by DangitBobby »

ehnto wrote: post #105
chrisco255 wrote: post #73

Earlier quoted context omitted.

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.

But just like all other frameworks, the cost isn't just getting it started, it's learning the framework, learning the ecosystem, and slowly building up your knowledge of the edge cases when you start moving past it's limits. Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've…

Definitely my biggest concern working with nextjs so far is that the line between when something is will execute server side and when it will execute client side is a bit blurry until you test them. It's manageable but requires some trial and error IME.

Re: A whole website in a single JavaScript file

#108

Post by DangitBobby »

bachmeier wrote: post #60
thunderbong wrote: post #30

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's written in js/React so you can share frontend and backend code and write the entire site in one language or even using the exact same components for server side and client side rendering. This is a boon for development. Ignore the nay-sayers.

Re: A whole website in a single JavaScript file

#109

Post by lhorie »

CreepGin wrote: post #97
kokanee wrote: post #80

Earlier quoted context omitted.

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, organiza…

What I was trying to get at is that whether you have to work with JSX or whatever, that doesn't really have much correlation with Deno per se. CRA/Next/Remix give you decent JSX setups out of the box too (for scopes where JSX is actually justifiable), and so on for all the popular framework flavors, so it kinda doesn't do Deno any justice to say what amounts to "hey look, it can do the most basic of things when you pull in a bunch of libs".

If the point of the article was to highlight a super simple, no-fuss edge computing deployment thing, maybe it would have been better to lead with that? Because if you lead w/ "A whole static website in a single JS file", then let's not blame me for pointing out that that's a relatively trivial task to accomplish with other technologies.

Re: A whole website in a single JavaScript file

#110

Post by didip »

I fucking love what Ryan is trying to do with Deno. The entire JS landscape is unnecessarily complicated and NPM is making it even worse.

Deno is making JS development fun again. Major props. I hope Deno Deploy is a commercial success for the team.

Post reply on HN