Earlier quoted context omitted.
The htmx library is a good way to do that: https://htmx.org
HTMX is revolutionary in it's bang-for-buck simplicity
[deleted]
Fresh – Next-gen web framework
161–170 of 463 posts
Re: Fresh – Next-gen web framework
#162This 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
Thank you. I actually realised/remembered about the domain and already edited my comment. But the author of the project is a Deno employee.
Re: Fresh – Next-gen web framework
#163This 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
I totally assumed it was an official Deno launch until I read your comment. I think it's the combination of the domain and the Deno mascot that makes it misleading.
EDIT: oh, if it's made by a Deno employee that changes it.
Re: Fresh – Next-gen web framework
#164This 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
the repo is under a Deno core team member tho. https://github.com/lucacasonato/fresh
Re: Fresh – Next-gen web framework
#165Earlier 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…
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.
Re: Fresh – Next-gen web framework
#166How do you get the content from the headless CMS into the static sites if there is no build step?
Re: Fresh – Next-gen web framework
#167Why 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…
Yep. We have come full circle. This is php with a better experience
So can I buy just some random hosting, upload .js file and it is done?
Re: Fresh – Next-gen web framework
#168> Island based client hydration
Software development already has its own vocabulary, but I feel quite ignorant now.
Re: Fresh – Next-gen web framework
#169That animation stole my heart
Re: Fresh – Next-gen web framework
#170Quoted post unavailable.
If you want to render random text and a button you shouldn't be using such frameworks at all. For a full-fledged web application a hundred kilobytes overhead isn't as crazy as you are making it seem.
I find it funny that the real egregious stat is the 600ms render time, but every retort to GP's comment is about the size.