Fresh – Next-gen web framework • Hacker News Board

Re: Fresh – Next-gen web framework

#391

Post by likortera » Mon, Jun 13, 2022, 7:28 PM UTC

solardev wrote: post #64

steve_adams_86 wrote: post #44

Earlier quoted context omitted.

Have you seen Remix yet? It’s pretty compelling in terms of competition for Next.JS. It makes different trade offs and isn’t strictly better by every metric, but overall I’m very happy with it for the two use cases I’ve tried it with. It’s a very low overhead framework once the simple conventions click. I’d still like to check this out, then redwood and a couple others too. I’m not huge on these frameworks in general…

I've heard really good things about Remix, especially the nested routes. But I think Next is trying to copy that in Layouts? https://nextjs.org/blog/layouts-rfc I use Next not just for the routing and composition and hydration, but for all the other quality-of-life improvements (image resizing, buildchain configs, hot reload), especially when it's paired with Vercel (per-push sandbox builds, stale-while-revalidate, s…

It's funny to me to see how many people say Next is copying something about remix when the entire remix thing is a copy of Next.

Heck, I've heard in a podcadt they're even working on a hosting platform copying vercel.

Re: Fresh – Next-gen web framework

#392

Post by yencabulator » Mon, Jun 13, 2022, 8:14 PM UTC

FpUser wrote: post #219

jokoon wrote: post #168

> Island based client hydration Software development already has its own vocabulary, but I feel quite ignorant now.

Some of the "modern" terminology in software development makes me want to puke. "Hydration" is one of those examples. And of course ingress / egress rate sounds way more important than read / write speed / rate.

Often read/write are only used when talking about storage.

Ingress/egress are also important in networking because they communicate direction -- lots of pipes are asymmetric, and a firewall allowing all egress is very different from allowing all ingress.

Ingress/egress also measure total data, when the gadget might only "read" a fraction of the traffic. For example, if a hardware-accelerated router makes decisions based on just a few fields of an IP packet, did it "read" the whole packet?

Re: Fresh – Next-gen web framework

#393

Post by melony » Mon, Jun 13, 2022, 8:22 PM UTC

eyelidlessness wrote: post #128

solardev wrote: post #12

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…

> 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 not the old days. Hydration is actually a compromise, and not a great one for UX. It’s in fact been said to be “pure overhead”, which I think is an overstatement but only slightly. What you’re describing in the abstra…

For all the improvements pioneered by Marko, why is eBay still so slow (compared to equivalent ecommerce sites in Next.js and similar)?

Re: Fresh – Next-gen web framework

#394

Post by yencabulator » Mon, Jun 13, 2022, 8:35 PM UTC

WuxiFingerHold wrote: post #267

The next-gen SPA frameworks/libs like SolidJS or Svelte are already very fast and more importantly very small in bundle size. At least much faster and smaller than React or Angular. Therefore the advantages of SSR frameworks like this new one are much smaller when compared to e.g. SolidJS. The performance claims made for this new framework need to be proven by benchmarks. Check out this SolidJS Hackernews clone (Clie…

Meanwhile, the Svelte people are working on SvelteKit, their integrated SSR+SPA.

Re: Fresh – Next-gen web framework

#395

Post by chrischen » Mon, Jun 13, 2022, 8:37 PM UTC

nindalf wrote: post #387

chrischen wrote: post #384

Earlier quoted context omitted.

The funny thing is as far as I know they still use PHP to render React (via embedded javascript interpreter) on the server.

You have a source for that? The React code I've seen at Facebook is client rendered.

> Whenever they want to run JavaScript on server (e.g. rendering React on server) they just use V8 directly rather than using Node.

I forgot where I read it, but it was someone on the internet where they embed V8 and call from PHP (Hack).

https://hashnode.com/post/10-things-you-probably-didnt-know-...

It's true they don't really use SSR that widely, as Facebook.com doesn't really need it, but I'm pretty sure they do use streaming SSR, which offers UX benefits.

Re: Fresh – Next-gen web framework

#396

Post by yencabulator » Mon, Jun 13, 2022, 8:44 PM UTC

"No build step" is a weird pitch when what actually happens is that, in production, they'll fetch a WASM module on the fly to do bundling at request time.

That build step was there to avoid doing this work over and over!

https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6...

Re: Fresh – Next-gen web framework

#397

Post by triyambakam » Mon, Jun 13, 2022, 9:10 PM UTC

AtNightWeCode wrote: post #356

triyambakam wrote: post #345

Earlier quoted context omitted.

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.

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

Are you aware that Deno is very new? I wouldn't say that Ryan Dahl got left behind because everyone hasn't switched to Node yet. There is a large amount of interest in Deno, exemplified by how frequently Deno projects make it to the front page of HN.

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

Haha. Just because you hate JS doesn't change reality.

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

This statement doesn't make sense. It never was very popular as a Bash replacement, if that's what you're meaning. And otherwise, it is the only option for browser interactivity. So it doesn't make sense what you're saying.

Re: Fresh – Next-gen web framework

#398

Post by AtNightWeCode » Mon, Jun 13, 2022, 9:35 PM UTC

triyambakam wrote: post #397

AtNightWeCode wrote: post #356

Earlier quoted context omitted.

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.

> Well, NodeJS is the default for service-side JS. Node > Deno. Are you aware that Deno is very new? I wouldn't say that Ryan Dahl got left behind because everyone hasn't switched to Node yet. There is a large amount of interest in Deno, exemplified by how frequently Deno projects make it to the front page of HN. > React is the main driver for JS not some server-side BS. Haha. Just because you hate JS doesn't change…

I am aware about what Deno is. But it is yet simply not the major leap forward that will get rid of NodeJS with that large ecosystem.

React was the first framework that requires the coder to really understand and utilize the modern features of JS.

Scripting something simple or spinning up a simple endpoint have always been arguments for NodeJS. R always talks about this. Terrible ground for decision making.

Re: Fresh – Next-gen web framework

#399

Post by meowtimemania » Mon, Jun 13, 2022, 9:58 PM UTC

yencabulator wrote: post #396

"No build step" is a weird pitch when what actually happens is that, in production , they'll fetch a WASM module on the fly to do bundling at request time . That build step was there to avoid doing this work over and over! https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6... https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6...

I thought this too. Isn’t it a better user experience if the bundling happens ahead of time rather than at request time?

Re: Fresh – Next-gen web framework

#400

Post by hunterb123 » Mon, Jun 13, 2022, 10:07 PM UTC

kennywinker wrote: post #349

sdevonoes wrote: post #173

Earlier quoted context omitted.

> except you can write code like it's not the old days. I imagine you mean that writing (frontend) code now a days is better than how it was in the old days. Well, at least from my perspective that's not the case. "Modern" frontend code requires: - a package manager (npm) - node (or deno or whatever) - transpilers (or is it plugins?) - TS - 10K+ dependencies And to be honest, what is all that good for? To being able…

I recently wrote a small web app. I started with https://alpinejs.dev/ linked via CDN, and OpenJSCAD, also linked via CDN - I wrote basic html, marked it up with alpine `x-model` and `x-data` tags, and sprinkled a little vanilla js on top. Everything worked well and I got 80% of the way through the project. In the final 20% I ended up adding a bundler (parcel), so I could bring in an scss framework and override its v…

You made a web site that displays a document. Not a web app. Web apps, like native apps, have a lot more UI state that needs certain patterns and tech to manage them properly. Many devs can discern the difference and use the correct tools. Some do reach for the wrong tool but it's not the tools fault.