Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fresh – Next-gen web framework

fresh.deno.dev

Post reply on HN
Print view View original

151–160 of 463 posts

Re: Fresh – Next-gen web framework

#151

Post by imiric »

jchw wrote: post #124
imiric wrote: post #114

Earlier quoted context omitted.

Is this satire? I honestly can't tell, but it made me laugh. If not, why in the world would a hello-world demo need optimization? By definition it's supposed to be the simplest thing you can build to showcase the features of what you're using. If the simplest project has the properties GP mentions, then it's not a good demo.

Quoted post unavailable.

The difference is that it doesn't take 600ms for a Rust binary to render "Hello world!" to stdout. In the context of CLI apps, binary size is irrelevant to the functionality of the demo. In the context of web apps, bundle size and speed _does_ matter, so 108KiB and 600ms are very relevant data points.

Besides, I'm pretty sure that in this framework's case the final bundle can also be trivially stripped, but would that also reduce the render time? It's difficult to tell, and maybe those things should be mentioned in the demo. (Sidenote: I haven't confirmed whether what 0des posted is true or not; I'm just going by the fact that you're defending it.)

Re: Fresh – Next-gen web framework

#153

Post by sriku »

Slowly getting somewhat cynical. This is the only space where both "prebuilds everything and therefore saves rendering time and improves caching" and "no build step and so speeds up deployment" are both considered valid feature pitches.

Re: Fresh – Next-gen web framework

#155

Post by mayank »

eyelidlessness wrote: post #128
solardev wrote: post #12

Ooh, some competition for Next.js? Vercel is doing a really good job with Next, but it's good to see some competition. Of course, that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's…

> Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's not the old days. Hydration is actually a compromise, and not a great one for UX. It’s in fact been said to be “pure overhead”, which I think is an overstatement but only slightly. What you’re describing in the abstra…

> The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client.

I understand the spirit of your comment, but this was/is also true of Google Web Toolkit (GWT).

Re: Fresh – Next-gen web framework

#156

Post by norman784 »

sriku wrote: post #153

Slowly getting somewhat cynical. This is the only space where both "prebuilds everything and therefore saves rendering time and improves caching" and "no build step and so speeds up deployment" are both considered valid feature pitches.

To me it reads more focused on developers than users of the site you build.

I like that in the last couple of years the developer experience was improved in some ways, this kind of apps that you could develop "easily" as monolithic could be served in a serverless hosting as a microservice (if I understood correctly how serverless works) serving each endpoint as a separate service, everything without you as dev put too much effort into it.

Re: Fresh – Next-gen web framework

#157

Post by baobabKoodaa »

ezrast wrote: post #97
btbuildem wrote: post #92

Earlier quoted context omitted.

Does that mean JS running server-side? That's a full-stop dealbreaker for me.

Deno is a JS runtime like Node, so if that's not your thing then yeah, this isn't for you.

Many Node-based JS frameworks, such as Gatsby or Next, allow SSG that can be distributed by a CDN. Your comment is weird.

Re: Fresh – Next-gen web framework

#158

Post by creamyhorror »

btbuildem wrote: post #92
manigandham wrote: post #87

Fresh = Deno version of Astro (static-first with SSR) and Isle (vue-focused) and bigger Next.js/Nuxt SSR (with no client js) modes. Remix also does well here with a focus on only SSR. It's basically what the original "isomorphic" javascript promise was to have the same code seamlessly running on server and client with a flexible split on what part ran where, now possible down to an individual tag/component. Also wort…

Does that mean JS running server-side? That's a full-stop dealbreaker for me.

Sorry, this is just funny considering how JS-on-the-server has become a (the?) dominant web paradigm among startups and newer tech teams. It's like a comment from 2014.

Re: Fresh – Next-gen web framework

#159

Post by tqkxzugoaupvwqr »

frou_dh wrote: post #154

This obviously has some level of Deno officialness. But from looking at the TODO-ridden state of the docs, it doesn't seem like it's ready for its '#1 on HN' public launch moment.

It has nothing to do with the official Deno project except for being hosted on Deno Deploy which gives you a .deno.dev domain. I find deno.dev misleading in the sense that it gives any random project instant credibility.

[1] https://deno.com/deploy/docs/projects

Re: Fresh – Next-gen web framework

#160

Post by norman784 »

toddmorey wrote: post #83
MarquesMa wrote: post #67

Why this can be great: - The dev experience is closer to the early days of PHP. - TypeScript, Preact out of the box. No need to configure build tools / deploys much faster. It's a pain in the ass to make these working at the same time and targeting both browser and server nowadays. - You can have interactivity without bolt-on client-side scripts that are different from other parts. - The code could be running on the…

Frameworks like Next or Nuxt often render each page server-side, shipping HTML to the client, but then also send enough javascript and json data to the client to "hydrate" the page back into fully interactive components. The whole site, then, really acts as one large javascript app once fully loaded. The islands approach is different: pages are server rendered, but you can easily define islands of interactivity (like…

Could solidjs considered also using the island architecture or at least considered a similar architecture?
Post reply on HN