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

71–80 of 463 posts

Re: Fresh – Next-gen web framework

#71

Post by okhobb »

PontifexMinimus wrote: post #57

From https://fresh.deno.dev/docs/getting-started/create-a-route : > Routes are defined as files in the routes directory. [...] If the file name is contact.js and is placed inside of the routes/about/ folder, the route will handle requests to /about/contact. I can't say I'm particularly keen on being told what directory to put files in, or or being told that I must only code exactly one endpoint in each file. Why aren…

This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?

Re: Fresh – Next-gen web framework

#72

Post by blunderkid »

Fresh looks inspired by Remix. Is that right? Not that there is anything wrong with that. But given that Remix does claim to be production ready, what makes Fresh better? I have been playing with Remix in a side project. I do like their simplicity vis-a-vis Nextjs. And the fact that it is all server rendered by design and not as a special case.

Re: Fresh – Next-gen web framework

#73

Post by eyelidlessness »

lmiller1990 wrote: post #9

I don't fully understand the difference between this (and something like Remix, which seems similar) and other frameworks like Next.js (React) and Nuxt.js (Vue). Can someone explain a bit about the differences, and pros/cons to each?

The big standout feature that sets it apart for UX is partial hydration. DX like Next (or whatever similar), and UX like plain HTML plus some isolated interactivity, is becoming a focal point for a lot of the current crop of FE tools. Astro has been a big player in this area, Marko doing it for years, Qwik is another really compelling option. But the more the merrier where devs can dev how they want and users aren’t getting gigantic globs of JS they don’t need or want.

Re: Fresh – Next-gen web framework

#74

Post by eyelidlessness »

eBombzor wrote: post #54
damowangcy wrote: post #41

Earlier quoted context omitted.

The end result might be same but all of these frameworks/library/tools have some tricks up their sleeves that makes things easier for developers to implement certain functionality. The major difference with Fresh is that it runs everything just-in-time when it is needed, hence doesn't require building no shipping anything by default to the client(but you can still ship some JS for client side interactivity). The key…

How is this better than astro?

It’s in the same space as Astro. I can say with certainty without even looking at my Twitter feed that the Astro team will welcome more work in the space. Even if it’s not “better”, everyone leading FE web projects who isn’t a dilettante is learning from and inspired by each other’s work.

Re: Fresh – Next-gen web framework

#75

Post by hsn915 »

I thought by now enough people have framework fatigue that no one bothers with yet another way to develop a website.

Is there a reason someone like me should care? Does it improve anything by atleast an order of magnitude?

Re: Fresh – Next-gen web framework

#76

Post by holistio »

okhobb wrote: post #71
PontifexMinimus wrote: post #57

From https://fresh.deno.dev/docs/getting-started/create-a-route : > Routes are defined as files in the routes directory. [...] If the file name is contact.js and is placed inside of the routes/about/ folder, the route will handle requests to /about/contact. I can't say I'm particularly keen on being told what directory to put files in, or or being told that I must only code exactly one endpoint in each file. Why aren…

This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?

In the case of Nuxt (which by default uses basically the same paradigm) I could circumvent this by using the package @nuxtjs/router.

I have no idea why this is the default behaviour, it sure feels something like a lot of people put a lot of work into and by then they didn't realise their fancy new feature doesn't make things better.

Re: Fresh – Next-gen web framework

#77

Post by lewisl9029 »

colordrops wrote: post #61
xavdid wrote: post #60

> fresh also does not have a build step. The code you write is also directly the code that is run on the server, and the code that is executed on the client. Any necessary transpilation of TypeScript or JSX to plain JavaScript is done on the fly, just when it is needed I find this very interesting. I get that adding a build step can be a pain during development / deployment, but running your TS build once per deploy…

Even if it isn't caching, it could be added with a service worker.

I explored using client-side service workers for build-less deployment workflows a while back, but the blocker was the initial visit when the service worker hasn't been installed yet. Ended up using es-module-shim's fetch hook (https://github.com/guybedford/es-module-shims#fetch-hook) instead, which worked quite well.

I kept the demo repo around here, in case it's helpful to anyone: https://github.com/lewisl9029/buildless-hot-reload-demo.

The repo itself is quite out of date at this point, but my current project, Reflame, is essentially the spiritual successor: https://reflame.app/

Reflame has the same ideals of achieving the developer experience I've always wanted for building client rendered React apps:

- instant production deployments (usually - instant preview environments that match production in pretty much every imaginable way (including the URL so we don't have to worry about special whitelisting for CORS and whatnot), that can also be flipped into development mode for fast-refresh (for the seamless feedback loop we're used to in local dev) and dev-mode dependencies (for better error messaging, etc)

- close-to-instant browser tests (1-3 seconds) that enable image snapshot comparisons that run with maximum parallelism, and only rerun when their dependency graphs change, and auto flake detection/recovery

Re: Fresh – Next-gen web framework

#78

Post by 0des »

Petersipoi wrote: post #53
0des wrote: post #52

Earlier quoted context omitted.

Quoted post unavailable.

Gotcha. So you did respond to the wrong comment. Thanks for clarifying. edit: 0des edited his previous comment to be much less hostile after I wrote this one (without indicating he did so), and then told me to "settle down sport" now that my comment seems a little aggressive. Really bad etiquette.

No post body was provided.

Re: Fresh – Next-gen web framework

#79

Post by xyzi2 »

okhobb wrote: post #71
PontifexMinimus wrote: post #57

From https://fresh.deno.dev/docs/getting-started/create-a-route : > Routes are defined as files in the routes directory. [...] If the file name is contact.js and is placed inside of the routes/about/ folder, the route will handle requests to /about/contact. I can't say I'm particularly keen on being told what directory to put files in, or or being told that I must only code exactly one endpoint in each file. Why aren…

This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?

I think it’s a part of their convention over configuration philosophy. Say what you will about it, there are obviously drawbacks.

But I’ve noticed that it makes it easier to quickly understand new codebases in my organization. Everyone are using Next.js and all the apps have about the same file layout.

Re: Fresh – Next-gen web framework

#80

Post by nstart »

hsn915 wrote: post #75

I thought by now enough people have framework fatigue that no one bothers with yet another way to develop a website. Is there a reason someone like me should care? Does it improve anything by atleast an order of magnitude?

I think the reason to be interested in this is because it’s deno specific. I’m not up to date with the deno landscape but I believe this is pretty novel for deno.
Post reply on HN