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.
Fresh – Next-gen web framework
361–370 of 463 posts
Re: Fresh – Next-gen web framework
#362Wish 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.
Re: Fresh – Next-gen web framework
#363Earlier 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.
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
#364Wish 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.
Re: Fresh – Next-gen web framework
#365Wish 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
#366Re: Fresh – Next-gen web framework
#367Ooh, 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.
Re: Fresh – Next-gen web framework
#368Re: Fresh – Next-gen web framework
#369Re: Fresh – Next-gen web framework
#370Earlier 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…