Live data from Hacker News

Fresh – Next-gen web framework

fresh.deno.dev

361–370 of 463 posts

Re: Fresh – Next-gen web framework

#361

Wish we could have just skip the hard part of transitioning to the future. At least next generations will start write JS/TS on both ends (front/back) and hopefully maintain seamlessly the state, benefit the server side and benefit on the front. Writing in same language and sharing the logic around. Sometimes it is a nightmare switching between languages python/php/go/anything else and then js for full-stacks.

The future is the past - Meteor.js.

Re: Fresh – Next-gen web framework

#362

Wish we could have just skip the hard part of transitioning to the future. At least next generations will start write JS/TS on both ends (front/back) and hopefully maintain seamlessly the state, benefit the server side and benefit on the front. Writing in same language and sharing the logic around. Sometimes it is a nightmare switching between languages python/php/go/anything else and then js for full-stacks.

Hopefully we'll be able to use a language that is more advanced than TS on both frontend and backend one day

Re: Fresh – Next-gen web framework

#363

Earlier quoted context omitted.

Next is lovely to work with but it has a flaw. It loses client state between pages if you use getServerSideProps. For any app that needs to load some up to date data on every page if the user is hitting it for the first time, but doesn't need to load it if the client already has it, Next doesn't have a solution. You end up using a persist gateway pattern which is a massive amount of work that you shouldn't really nee…

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 the prior person mentioned with getServerSideProps.

Next.js probably seems great if you're writing greenfield code in a dead simple web app. Routing/URL handling on Next.js is just broken. This is all glaringly obvious if you've been around the SPA/SSR world for more than a day.

Re: Fresh – Next-gen web framework

#364

Wish we could have just skip the hard part of transitioning to the future. At least next generations will start write JS/TS on both ends (front/back) and hopefully maintain seamlessly the state, benefit the server side and benefit on the front. Writing in same language and sharing the logic around. Sometimes it is a nightmare switching between languages python/php/go/anything else and then js for full-stacks.

In particular, can we skip to the part that involves no js :)

Re: Fresh – Next-gen web framework

#365

Wish we could have just skip the hard part of transitioning to the future. At least next generations will start write JS/TS on both ends (front/back) and hopefully maintain seamlessly the state, benefit the server side and benefit on the front. Writing in same language and sharing the logic around. Sometimes it is a nightmare switching between languages python/php/go/anything else and then js for full-stacks.

Hopefully we'll be able to use a language that is more advanced than TS on both frontend and backend one day

Probably something like Gleam lang. That full stack has felt like tasting the future

Re: Fresh – Next-gen web framework

#367

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…

https://Remix.run is the real competition for (/successor to) Next.js. It can target a Deno runtime so I guess it's competition for "Fresh", too.

I didn't know Remix supported Deno, that's interesting

Re: Fresh – Next-gen web framework

#370

Earlier quoted context omitted.

> that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). You only need one (or none). I personally recommend Next.js for just about anything.

Next is lovely to work with but it has a flaw. It loses client state between pages if you use getServerSideProps. For any app that needs to load some up to date data on every page if the user is hitting it for the first time, but doesn't need to load it if the client already has it, Next doesn't have a solution. You end up using a persist gateway pattern which is a massive amount of work that you shouldn't really nee…

They're working on that with Server Components: https://nextjs.org/blog/layouts-rfc?utm_source=next-site&utm...
Post reply on HN