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

141–150 of 170 posts

Re: A whole website in a single JavaScript file

#141

Post by lucacasonato »

ROARosen wrote: post #90
lhorie wrote: post #56

Earlier quoted context omitted.

Yes, I know what Deno is, and when I say "semi-interesting", I mean I'm trying to find a silver lining to praise Deno for. To clarify, the similarity is that this claims to be a "single file" thing by importing the meat of the functionality from elsewhere. Which is not really interesting at all, because using batteries to make websites was already a thing with PHP in the 90s. Or, as I mentioned, it's not that differe…

> Committing node_modules guarantees that the app works even if the NPM registry were to implode. Try to deploy your deno thing from a cold state (e.g. maybe you're moving to a different AWS region or a different provider or whatever) while there's a deno.land outage and it will blow up You can just move your DENO_DIR (cache) along with the rest of your code the same way you can move your node_modules folder. See: ht…

Or you can use `deno vendor` to check in your dependencies into version control, or put a caching HTTP proxy between you and the origin server. Don’t be fooled: Node & NPM have these same problems.

Re: A whole website in a single JavaScript file

#142

Post by hamandcheese »

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…

> except that if node.land or crux.land go down, you've lost your reproducibility.

I wouldn’t say you lost it, I’d say you never had it in the first place.

Re: A whole website in a single JavaScript file

#143

Post by wink »

I've been looking at Deno very briefly recently (overall a good impression) and I was very much surprised that just getting the visitor's IP address took like a dozen lines of code.

My test case was, basically reproducing something like
and I was a little surprised how much convenience was baked into it and how you wouldn't have access to all that in other libs. That someone created an issue[1] makes me think I am not just not looking good enough and it's actually tedious.

[1]: https://github.com/denoland/deno_std/issues/1884

Re: A whole website in a single JavaScript file

#144

Post by 5560675260 »

adriangrigore wrote: post #116
mark_and_sweep wrote: post #103

Earlier quoted context omitted.

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…

> a powerful sh based templating engine > it mimics building a small C project

You're using practices from a language unrelated to webdev, scripting language unrelated to webdev and what looks to be a closed source generator built and (un)maintained by a single person. There probably is a context where this setup makes sense, but to me it's anything but simple or intuitive.

Re: A whole website in a single JavaScript file

#146

Post by masa331 »

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…

Your focus on things being "modern", which is no indicator of value except for hipsters and recruiters, made you forget about the third conclusion with which you might come away from setting up a monolith application:

3. Wow, this actually works. I am so productive and i can actually get my work done quickly, the same way as hundreds of thousands other normal developers out there. And then i can have a free time and mind free of stressing over what's cool or not

It's about what you value. If it is your time and happinnes, if you mainly want to just build stuff to solve real world problems, then choosing good old monolith application will get you there safe and fast in 90% of situations.

If you value to be hip and cool, then Deno, hydrating whatever, edge servers and sorely lacking areas of modern web development will 100% get you there.

Re: A whole website in a single JavaScript file

#147

Post by trollied »

kokanee wrote: post #80
CreepGin wrote: post #61

Earlier quoted context omitted.

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…

Agree 100%. The first time I heard the term "Server side rendering" I wondered what the hell it meant! Must have been coined by the new-fangled DOM-manipulator army. Modern web development is a big, clunky, slow mess, and for no good reason.

Re: A whole website in a single JavaScript file

#148

Post by alt227 »

EnKopVand wrote: post #130
epolanski wrote: post #72

Earlier quoted context omitted.

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.

Why do you think the previous poster is right? I personally think they are being sort of silly. Don’t get me wrong, I absolutely think you should consider your tools, but I recently had to get a screw out of a bookcase. It was stuck in free air and was just going round and round, so I ended up using a hammer to push it in the right direction. This is far from the only time I’ve used my hammer for something it wasn’t…

Should have used some pliers...

Re: A whole website in a single JavaScript file

#149

Post by 52-6F-62 »

DangitBobby wrote: post #107
ehnto wrote: post #105

Earlier quoted context omitted.

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.

That was problematic for me when I was testing it out. Can’t access the window object without excessive workarounds that I couldn’t make work with my project. I ended up reusing existing react components and move it to all browser rendered react and even that experience has me leaning toward moving it to Vue or dropping the framework altogether and grinding everything out in css again. That said, I did enjoy using styled components. I found that pattern pleasant to reason around.

Re: A whole website in a single JavaScript file

#150

Post by buchanaf »

thestepafter wrote: post #120
wwweston wrote: post #95

Earlier quoted context omitted.

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.

This sounds made up.
Post reply on HN