Live data from Hacker News

A whole website in a single JavaScript file

deno.com

151–160 of 170 posts

Re: A whole website in a single JavaScript file

#151

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…

My thoughts weren't really meant to be a condemnation of monolithic web app frameworks, just a summary of my conclusions after using them for years.

The reasons I have for justifying use of React, JSX, GraphQL, etc. have nothing to do with being "hip and cool" and everything to do with happiness and productivity. Using modern tools is both more enjoyable and more productive in my experience, as someone who used Ruby-on-Rails with templated pages for four years.

Re: A whole website in a single JavaScript file

#152
post #25

Earlier quoted context omitted.

Oh. So you've reinvented PHP. Nice.

This is a very lazy comment. I'm sure it makes you feel smart, but it drags down the entire conversation, and doesn't add anything of value. You seem very capable and accomplished, so I'm confused why you would spend any of your time to simply shit-post on someone who is trying to build something of use to many people.

You are right. It is a lazy comment. I would delete it if I could at this point but thats not possible.

It really comes about from my frustration. So much effort pushing into new tech and the result (at least as I and others in the comments here noted) is something reflective of pre-existing technology that has been around for decades.

I get that though enough of these exercises true innovation does emerge. However there is a whole lot of "re-inventing the wheel" in-between that which is frustrating as it seems to be prevalent.

Re: A whole website in a single JavaScript file

#153

Earlier quoted context omitted.

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

[deleted]

Re: A whole website in a single JavaScript file

#154

Earlier quoted context omitted.

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

The import { h } made me think it was preact, but I guess it's not even that.

Re: A whole website in a single JavaScript file

#155
post #125
post #99

Earlier quoted context omitted.

To be clear, IMHO, Deno looks fine for what it is. The features are great. The cons ironically mostly boil down to "it's not node", i.e. ejecting a non-trivial app from CRA into some vite setup is doable with some effort, but migrating to Deno is, charitably, likely a monumental task that nobody would ever undertake, even considering the upsides. At the risk of diving too deep into opinion territory, I'm not all that…

Leo, your comments save me a lot of typing on threads like this, and since I recently wrote[1] what beeandapenguin wrote above almost to a point (sans security), I feel obliged to expand a bit. You are right about incompatibility being a major issue; Deno recognizes that as well, hence, they are working on a compatibility mode that allows using Node specific libraries in Deno[2]. > migrating to Deno is, charitably, l…

> The major technical road-block

Yeah, this is primarily what I'd expect would hold back migrations, both in actual technical terms (e.g. Deno-flavored libraries for some tasks may not exist at all) and buy-in from engineers. Don't get me wrong, I'd love to seriously consider Deno for our (very large) codebase (a 1000+ package monorepo with 400+ engineers committing), and I say this as someone who's successfully lead a number of massive migrations for this monorepo. But Node -> Deno at even 1/100 of this scale is, in my mind, potentially orders of magnitude more difficult than even a monorepo-wide Flow -> Typescript conversion, which is already fairly daunting migration.

Re: A whole website in a single JavaScript file

#156

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…

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

i seek out new technologies because i want to be _more_ productive than the average engineer. i don't believe there are hundreds of thousands of developers who are more productive than someone who makes an effort to learn stuff like deno, vite, unjs, fauna, etc. as soon as possible

Re: A whole website in a single JavaScript file

#157

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…

“Modern” also means the solution may benefit from reflection on past solutions.

The accounting software I use, written in 2004, evolved over the decades starting from 1980s software. It all works (hence, I’m using it now), but comparing the user experience and source code of various features developed at various times reveals a lot about what “modern” means.

Here’s a few things:

Standardisation: Modern software tends to use proven designs, such as SQL over a bespoke query language.

Performance: The strictness of ABIs and APIs makes it difficult to restructure for the sake of optimisation without introducing undesirable breaking changes. Old codebases may be essentially “frozen” and stuck on old versions of libraries. Fresh software can use the latest versions of libraries, with their new APIs & ABIs and whatever optimisations come along.

Fundamental coding improvements: Old languages don’t have ergonomic, performant closures (see lambda functions in Python). New languages do (see arrow functions in ES6). Replace “closures” with any core language feature, like null coalescing, match statements, object & array destructing (or even better: pattern matching assignment), or hygienic macros. (Let’s not discuss async/await as that doesn’t lie in the “unquestionably better” column.)

Better error messages & debugging: Over time, we collectively as developers have figured out what helps and what hinders when trying to track down troubles.

——

I also build stuff that solves real world problems. I once used Python and Django for everything. Now, I’ve moved to Node.js, TypeScript, React, and generally that ecosystem. It works far better than Python+Django. My development speed is blazingly fast in comparison, and the results stand up — they’re shippable.

Once I was familiar with Python & Django, they got the job done.

Now, I’m familiar with TypeScript & Node, they get the job done better.

Familiarity is that invisible force that, in its absence, prevents us from distinguishing things that don’t work from things that do work but are just different from what we know.

Re: A whole website in a single JavaScript file

#158

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.

Yep, I've been using Next.js for several years and it's mostly great. One thing that I found is that Next.js still suffers from configuration fatigue, this was especially true before the team moved from Webpack to SWC. I'm glad to see that the team is moving more in the direction of "configured by default", but you still inevitably need to fiddle with the dials if you want to use things outside of the documented tool integrations.

Re: A whole website in a single JavaScript file

#159

Earlier quoted context omitted.

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.

Whether the reason is true, the behavior seems more or less consistent with my experience. Mobile Safari caching seems forgetful on surprisingly short horizons (especially when low power mode is on). Mobile Firefox seems better but sucks down battery life on the order that Google / Apple Maps in active navigation do.

If you have a reason to believe the reality is different, though, happy to hear about more details beyond "this sounds made up."

Re: A whole website in a single JavaScript file

#160

Is there a particular advantage to how this is done here with Deno or is this just an example of server side rendering being possible in Deno? The latter is fine as I'm a fan of Deno :) just missing why it's such a popular post (maybe more Deno fans?)

You mean you are a user ? Fans are for music :)

I'm actually still a Node user! I really like how Deno has been innovating this space though and it's come a long way in the last couple of years so I'm looking forward to making the switch at some point. Even if I never do for some reason (most likely node API specific libraries) it has really given Node some reasons to innovate in a few places and I love Deno for that as well.
Post reply on HN