141–150 of 463 posts
Fresh looks inspired by Remix. Is that right? Not that there is anything wrong with that. But given that Remix does claim to be production ready, what makes Fresh better? I have been playing with Remix in a side project. I do like their simplicity vis-a-vis Nextjs. And the fact that it is all server rendered by design and not as a special case.
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…
How widely use is deno?
There’s companies that bet on deno/deno-like runtimes. It’s a move to having more options/control on sandboxing/embedding JS on server runtimes.
Think of how Lua is used. Heavy lifting in a compiled language with Lua on top to cover app specific logic.
Node is in a sense that, but with a stronger emphasis on being a general purpose runtime for JS.
Deno (and similar), gives you more options for embedding and restricting the JS side.
I think it’s worth keeping an eye on, because I think the JS world is soon in an refinement/optimization phase. It’s settling and stabilizing towards a set of core ideas and Deno might be part of that.
I heard the word "hydration" so many times, I sort of get it, but always have question mark in mind that what's different between hydration and jquery approach ?
In the jquery aprroach the in-memory model is built straight from what's on the page (the dom). This removes an entire class of problems (there's no mis-synchronization possible) but has its own set of issues (the model you build may not end up being what you expected while coding).
More importantly, "hydration" use implies that the HTML that gets sent to the client is a Server-Side Rendered version generated from the same JS code that runs in the page. The very big advantage here is that there's a single place where the page's content is controlled from (the js/jsx/whatever code) instead of having to manually maintain the html/js relationship by hand like in the jquery case.
Furthermore, the jquery approach is global in nature (you can manually scope jquery-fiddling, but if you make a mistake you may end up modifying stuff elsewhere on the page) whereas this cannot happen in the vdom approach.
In general, the vdom approach makes code more manageable at the cost of runtime performance. That's why many people recommend react and/or other vdom-based frameworks for the complicated cases (lots of dynamic stuff on the page) but vanilla/jquery/etc. when the in-page interactivity is lower.
Today's crop of "frontend frameworks" (such as nextjs, fresh here, etc.) are trying to achieve the benefits of the vdom approach while minimizing its' drawbacks (and full-page hydration is a big drawback because it takes "a lot" of time decreasing the page's Time-To-Interactive metric).
Earlier quoted context omitted.
(I am not affiliated with any of these technologies, but am a Next/Vercel customer. I am also not super familiar with anything except Next, but this is my attempt at an explanation.) I think they all try to solve the same problem: how to get a modern interactive app to run on (and be performant) what is essentially a hacked-together ecosystem, HTML + Javascript, with decades of backward compatibility baggage. The ess…
What happens when the user interacts with the page while it's being rehydrated? Is that click eaten, does the user see some error, or does the page remember the click and run it when it has pulled in the relevant js?
[0] https://twitter.com/dan_abramov/status/1200118229697486849
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…
The htmx library is a good way to do that: https://htmx.org
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…
Earlier quoted context omitted.
> 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…
if the code is the same on the server, one could serialise the state and transfer it with the html, right?