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

351–360 of 463 posts

Re: Fresh – Next-gen web framework

#351

Post by solardev »

cercatrova wrote: post #165
onion2k wrote: post #110

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.

You can set next/image to work with Cloudinary or Imgix or a custom provider. It gets the job done that way, but yeah, the experience isn't as smooth as with Vercel.

Same with incremental static regeneration and some other features... Next is obviously built not just by, but also for, Vercel. Vendor lock-in already is a small issue and may become a bigger one if they keep going down that route.

Re: Fresh – Next-gen web framework

#353

Post by lucacasonato »

gigatexal wrote: post #58
gavinray wrote: post #36

On the part about adding interactivity: > "To include this in a page component, one can just use the component normally. Fresh will take care of automatically mounting the island component on the client with the correct props:" How does a developer know what rendering is going to take place client-side vs server-side, and is there any way to control this? Or is it all fully "magical"

Yeah this seems like a pain. I don’t like magic. Magic is hard to debug.

It's not magic. There is an `islands/` folder that you must place all of your client components in. 1 component per file. See https://fresh.deno.dev/docs/getting-started/adding-interacti...

Re: Fresh – Next-gen web framework

#356

Post by AtNightWeCode »

triyambakam wrote: post #345
AtNightWeCode wrote: post #339

Earlier quoted context omitted.

He really is the JS server-side sect leader. Plain wrong about so many things you lost count while he talks. Glad that the JS community, not that I am fan, left this dude behind.

What makes you believe the community left him behind? And he's only wrong from your perspective, especially as you say you aren't working in this domain.

Well, NodeJS is the default for service-side JS. Node > Deno.

React is the main driver for JS not some server-side BS.

The classic scripting arg. JS is a poor choice for scripting and hence, not used for it that much anymore.

Re: Fresh – Next-gen web framework

#358

Post by qudat »

DylanSp wrote: post #246
zelphirkalt wrote: post #104

Earlier quoted context omitted.

Next (no pun intended) thing we will rediscover is using templating engines (only in JS or so), because we realize, that mixing state and behavior is a problem. Then we will have gone full circle, but probably with some unreasonable overhead as a result. Maybe the whole thing of rendering templates will somehow become a part of webpack and everyone will have to configure webpack. Good that classic web frameworks are…

Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) 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 typecheckin…

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

Re: Fresh – Next-gen web framework

#359

Post by jchw »

datalopers wrote: post #336
jchw wrote: post #119

Earlier quoted context omitted.

I'm really sad that this sort of attitude is common in Hacker News. I am not a huge fan of JS, but what I hate about this is not that it's critical of JS, but that it's clearly just a knee-jerk cynical reaction. This framework in question is not doing what PHP/Ruby frameworks were doing. Whether what it's doing is a good idea or not is neither here nor there, it's just simply that you aren't understanding what it is…

The fact that you think it’s materially different is amusing. The only “magic” here is injecting JS shims to handle bidirectional syncs for certain components (“islands” in their parlance). That is also something we’ve had for a very long time, though admittedly it was kludgy as hell two decades ago (ajax polling, SSE, long-polling, comet, etc).

No post body was provided.

Re: Fresh – Next-gen web framework

#360

Post by simultsop »

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.

Post reply on HN