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

111–120 of 170 posts

Re: A whole website in a single JavaScript file

#111

Post by crate_barre »

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…

Is it Node’s Rails or Django? That’s roughly what we want to encourage. It’s been a long time coming.

Channeling my inner Cicero, Fuck Rust.

Re: A whole website in a single JavaScript file

#112

Post by brundolf »

DangitBobby wrote: post #108
bachmeier wrote: post #60

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.

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.

The demo doesn't use React, only JSX

Re: A whole website in a single JavaScript file

#113

Post by brundolf »

AaronO wrote: post #5
edent wrote: post #2

> rendered dynamically, just in time, at the edge, close to the user. HTML. You're serving HTML. Doesn't really matter that the server-side language is JS, PHP, or BASIC.

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

I can appreciate what's being done here, but I think a more compelling demo would have had a bit of dynamic rendering just to emphasize the point (since in the real world, a fully-static site like this would be better served by a static-only hosting service with no custom server running at all, even one on the edge). Even something as simple as grabbing the current timestamp and displaying it in the returned HTML, just to show that logic is running on every request.

Re: A whole website in a single JavaScript file

#114

Post by metaltyphoon »

victor_e wrote: post #88
abracadaniel wrote: post #34

Earlier quoted context omitted.

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.

I was doing the same!

3 of us :D

Re: A whole website in a single JavaScript file

#115

Post by CreepGin »

lhorie wrote: post #109
CreepGin wrote: post #97

Earlier quoted context omitted.

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

Yes, you are certainly not alone on that. The headline could be made better. Focus should be more on the composability and tooling side of things.

Re: A whole website in a single JavaScript file

#116

Post by adriangrigore »

mark_and_sweep wrote: post #103
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-compan…

Not sure if matter of preference or matter of right tool for the job and industry agreed best practices regarding simple vs complex. In the sense that you may prefer the round peg, but it doesn't fit the square hole.

I've been doing JavaScript myself for about 15 year, unfamiliar with the UNIX philosophy (to be doubted as any doctrine). Started doing web development using plain HTML the "old school" way, I personally dare to say the _normal_ way.

Before the rise of SPAs I very much agreed with the idea of progressive enhancement which is coming again into attention with the likes of https://turbo.hotwired.dev/.

While doing SPAs I always felt that stuff constantly didn't fit, that we were constantly using unfit tech, doing hacks for benefits of using a single (unfit?) language both on the server and the client, partial loads (faster loading times) and having a single codebase for all OSes. Stuff felt hacky most of the times and we were hiding those complex hacks under what _seemed_ as elegant and simple abstractions. But I believe most experienced JavaScript developers agree that the elegance and simplicity is mostly on the surface. I constantly felt dissatisfied with the code I wrote. I refuse to go on a full rant regarding SPAs and JavaScript but that's the gist of it.

While configuring my dev environment I stumbled up the https://suckless.org/ guys. Their code embodies the UNIX philosophy well although some people, including me, might say that some stuff is too simple. Simplicity for the sake of simplicity is not a good idea (nothing for the sake of anything is a good idea to be honest) but rather as a consequence of you understanding of what's not really needed.

While investigating more more the UNIX world, discovering OpenBSD and using it as a daily driver things started to fit and make sense.

Now, regarding how mkws fits generating static sites, it mimics building a small C project except the Makefile is replaced by a shell script, so all the principles fit and are well established. pp is the compiler, .upphtml files are the sources, html files are the output binaries. Everything integrates and fits well. I feel satisfied about how everything works.

Code is small and simple, abstractions are kept to a minimum. I, as a single person, am able to investigate, understand and change every part of the generating process. Can't say the same thing about a JavaScript static site generator, you don't really need the v8 engine to generate a few HTML files, that's complex, most of use agree simple is relatively good, complex relatively bad as an industry best practice.

Regarding SPAs, I believe they were a quick solution until we properly solve the problems they solve via progressive enhancement.

Re: A whole website in a single JavaScript file

#117

Post by evilduck »

cutler wrote: post #104
evilduck wrote: post #78

Earlier quoted context omitted.

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.

Yes, they’re sending HTML chunks over the wire. It’s the same end result though, except you’re still not exempted from learning JS.

Re: A whole website in a single JavaScript file

#119

Post by gorgoiler »

Alas, I wanted to believe, but I pretty much immediately uncovered a bug with the way my browser’s back button works.

In iOS Safari, click the “CLI” link at the top, then swipe the page to the right to go back. If you do it slowly it works, but the first time I tried I did a regular flick-swipe from about the height of the page where the version number is. I was trapped in deno.land and couldn’t go back.

(Maybe that’s a bug in deno.land though, not deno.com?)

Re: A whole website in a single JavaScript file

#120

Post by thestepafter »

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

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…

A couple versions ago mobile browsers started clearing cache when you leave the application to help save battery life if I remember correctly. Very annoying because now I am unable to open a bunch of tabs in Safari for HN threads before I go off grid.
Post reply on HN