Live data from Hacker News

Fresh is a new full stack web framework for Deno

deno.com

11–20 of 249 posts

Re: Fresh is a new full stack web framework for Deno

#12
I am very interested in seeing where this goes. I would love to see things get fleshed out a little more ala BlitzJS (auth, simple client/server session management, integrated database tooling), but I don't know if that goes along with Fresh's principles. But this is a very exciting start for this framework and looks like a great addition to the Deno ecosystem.

Re: Fresh is a new full stack web framework for Deno

#14
post #8

> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML. server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8? for a properly-chunked app, hopefully m…

> server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?

Expensive not in money terms, but in user experience.

Also: if you are doing e-commerce, 100ms added latency can cost you 7-8% in conversions. Spending 5% more on hosting to do SSR just makes economic sense.

Re: Fresh is a new full stack web framework for Deno

#15
post #8

> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML. server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8? for a properly-chunked app, hopefully m…

To add to the list: Svelte is also faster and lighter for most cases. And with SvelteKit the server sends only the bare minimum JS to make the page dynamic while being SEO friendly depending on the adapter of choice.

It can even output static, precompiled, pages with the adapter-static so no heavy backend processing involved and response times are best-in-class: https://github.com/sveltejs/kit/tree/master/packages/adapter...

Re: Fresh is a new full stack web framework for Deno

#16

Are deno packages usable from the node side of the ecosystem ? and vice versa ?

Depends if your package uses any specific Deno/Node APIs. Deno also only supports ESM (which you should be using anyway).

There is, however, a Node compatibility layer for Deno: https://deno.land/manual@v1.14.1/npm_nodejs/std_node

Re: Fresh is a new full stack web framework for Deno

#18
post #4

I really like the idea of Deno and Fresh's philosophy also resonates with me (I'm a Rails guy). I would like to see an integrated ORM (can be an existing one) and testing framework though, before I would consider it a "full-stack" web framework.

Yes, this is something I want to add in the future. We're just not quite there yet. My current plan is: 1. first class styling plugins 2. synchronized island state 3. built in data persistence

Amazing. If I can make a wish for 1: Tailwind =)

Re: Fresh is a new full stack web framework for Deno

#19
post #8

> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML. server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8? for a properly-chunked app, hopefully m…

The cost of server-side rendering feels pretty trivial to me these days.

Fly.io will sell you a 256MB of RAM container for $1.94/month, which is perfectly capable of server-side rendering dozens (maybe even hundreds if you write efficient code) of requests per second.

I'm sure you can get even better deals if you shop around.

Re: Fresh is a new full stack web framework for Deno

#20
post #8

> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML. server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8? for a properly-chunked app, hopefully m…

> server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8? Expensive not in money terms, but in user experience. Also: if you are doing e-commerce, 100ms added latency can cost you 7-8% in conversions. Spending 5% more on hosting to do SSR just makes economic sense.

> 100ms added latency can cost you 7-8% in conversions

i hear this metric (or something equally absurd) cited frequently and have never seen it to be true in my own experience.

i guess if you have to load a product page with 100 images (or assets) and each has 100ms network latency, then it will add up to much more than that. but 100ms for a single interaction or network request (e.g. process payment POST) is not going to move the needle on conversions. 100ms will feel instantaneous to 97% of users, and more than satisfactory for the remaining 3%.

(i say this as someone who profiles aggressively and strives to optimize every stray 5ms in JS and every 1kb over the wire)

Post reply on HN