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

411–420 of 463 posts

Re: Fresh – Next-gen web framework

#411

Post by qudat »

zelphirkalt wrote: post #407
qudat wrote: post #358

Earlier quoted context omitted.

> that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. This is exactly what I find frustrating about go templating. I lose autocomplete and type hints.

Makes me think of Scheme and SXML, where you never leave the context of the language. Transfer that to something statically typed, and you would get what you want. Maybe something like that exists in Haskell or a similar language?

Tsx is the templating language that is also typescript. So the “controller” and the template are the same function.

Re: Fresh – Next-gen web framework

#412

Post by pier25 »

radicalriddler wrote: post #405
pier25 wrote: post #404

Did they copy the React API or the client side stuff is a wrapper on top of React? https://fresh.deno.dev/docs/getting-started/adding-interacti... It looks identical to React.

> The framework uses Preact and JSX for rendering and templating on both the server and the client. On https://fresh.deno.dev/docs/introduction

Thanks I missed that!

Re: Fresh – Next-gen web framework

#413

Post by pier25 »

yencabulator wrote: post #396

"No build step" is a weird pitch when what actually happens is that, in production , they'll fetch a WASM module on the fly to do bundling at request time . That build step was there to avoid doing this work over and over! https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6... https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6...

Maybe it has a cache and this only happens the first time?

It would be a bit ridiculous to re-compile JSX into JS on every request.

Re: Fresh – Next-gen web framework

#414

Post by steve_adams_86 »

likortera wrote: post #391
solardev wrote: post #64

Earlier quoted context omitted.

I've heard really good things about Remix, especially the nested routes. But I think Next is trying to copy that in Layouts? https://nextjs.org/blog/layouts-rfc I use Next not just for the routing and composition and hydration, but for all the other quality-of-life improvements (image resizing, buildchain configs, hot reload), especially when it's paired with Vercel (per-push sandbox builds, stale-while-revalidate, s…

It's funny to me to see how many people say Next is copying something about remix when the entire remix thing is a copy of Next. Heck, I've heard in a podcadt they're even working on a hosting platform copying vercel.

For sure, Vercel was working on nested routes before Remix was a thing, as far as I know. A lot of people suggested it was lifted from Remix. It’s not a new idea at all and people have been asking for it for years.

Arguably there is nothing all that novel in either framework. We are constantly reiterating and rebuilding wheels, doing it a little better each time.

I’m glad to see the Remix take in things gaining steam though. It’s quite a bit less cognitive overhead than Next without any magical trade offs. Nothing ground breaking, but definitely better at things I care about.

Like most things, a blend of solutions would be ideal

Re: Fresh – Next-gen web framework

#415

Post by moneywoes »

deckard1 wrote: post #363
cercatrova wrote: post #165

Earlier quoted context omitted.

Also, next/image only works with a CDN, ie Vercel, it doesn't work with static site generation. It's been an open issue for years and I honestly now feel like Vercel doesn't fix the problem on purpose, to push more people to using their service rather than simply exporting to a static host which are plentiful.

been saying it for awhile... Next.js is an ad for their services. Take a look at their middleware. It's designed to be used solely with their serverless cloud BS. It uses a janky JS sandbox which means you can't use node APIs. It's just horrible for no good reason at all. I've never seen middleware so intentionally crippled anywhere before. And the whole reason you need middleware is to maneuver around the flaws that…

What is the alternative for SSR?

Re: Fresh – Next-gen web framework

#416

Post by pier25 »

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…

> Serializing server state to HTML and sprinkling in interactivity to pick up where it left off is exactly where we should be headed.

Ironically we were already doing that 15 years ago years with PHP/ASP/Java/Rails + jQuery.

Re: Fresh – Next-gen web framework

#417

Post by pier25 »

melony wrote: post #393
eyelidlessness wrote: post #128

Earlier quoted context omitted.

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

For all the improvements pioneered by Marko, why is eBay still so slow (compared to equivalent ecommerce sites in Next.js and similar)?

My guess, the bottleneck is in the data layer.

Honestly it's unfair to compare a small e-commerce site made with Next to one of the biggest websites on the internet.

If Ebay was made with Next it would probably be much slower. React is the slowest at SSR of the modern frameworks. Amazon considered using it but it was too slow for them so they keep using Java + sprinkled JS.

Re: Fresh – Next-gen web framework

#418

Post by eyelidlessness »

pier25 wrote: post #416
eyelidlessness wrote: post #128

Earlier quoted context omitted.

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

> Serializing server state to HTML and sprinkling in interactivity to pick up where it left off is exactly where we should be headed. Ironically we were already doing that 15 years ago years with PHP/ASP/Java/Rails + jQuery.

This is neither ironic nor correct. But I will say I’ve described my mental model of Qwik as effectively that UX, but the compiler writes the jQuery for you.

Re: Fresh – Next-gen web framework

#419

Post by pier25 »

baobabKoodaa wrote: post #157
ezrast wrote: post #97

Earlier quoted context omitted.

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.

Dynamic responses also can be cached in a CDN you know...

Re: Fresh – Next-gen web framework

#420

Post by noobermin »

dismantlethesun wrote: post #206
noobermin wrote: post #191

Earlier quoted context omitted.

Isn't this how webpages used to work with jquery? Are you telling me everything just went full circle back?

Yes! But with Jquery you had to manually separate out the interactive elements ship those to the client. With newer frameworks (Svelte, Fresh), the framework itself automatically parses out the interactive elements and ships them. There's no context switch between interactive and non-interactive either, since all rendering is done with the same language and framework, and even the same file. I think this is great. I…

I guess the lack of context switch seems like it would be easier on the brain. I guess the actual working of static + dynamic bits unlike how it is now with everything dynamic is more of a "how it works is similar" thing while the coding is coherent unlike jquery.
Post reply on HN