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

211–220 of 463 posts

Re: Fresh – Next-gen web framework

#211

Post by sdevonoes »

askonomm wrote: post #181
sdevonoes wrote: post #177

Earlier quoted context omitted.

> The key here is no building (packing, bundling, transpiling). How is that possible? In the documentation ( https://fresh.deno.dev/docs/getting-started/create-a-route ) I see .tsx files... so I imagine that at least one needs to compile TS to JS and then JSX to JS. Perhaps I got that wrong, though and browsers nowadays support TSX out of the box.

It's using the Deno runtime, not Node. Deno has a TS compiler built-in, thus not requiring you to set anything up in that regard.

Thanks. I didn't know that.

Re: Fresh – Next-gen web framework

#212

Post by bartlomieju »

3np wrote: post #101
francis-li wrote: post #43

Ryan Dahl talks a bit about it in this talk at Remix Conf 2022: https://www.youtube.com/watch?v=4_nxvVTNY9s&t=10781s He describes it as a post-Unix web framework (i.e. built on serverless primitives like cloudflare workers/deno deploy) with the goal of <10s deployment (which he says requires JIT compilation on first-request)

So my reading of that is that Fresh as it stands now is more of a demo and challenge to the Remix community to step up.

Not really, Fresh already powers several websites https://deno.land/, so it definitely has production use.

Re: Fresh – Next-gen web framework

#213

Post by dbbk »

bushidowarrior wrote: post #209

Here are some of my thoughts: It is using silly naming conventions in filenames as an alternative to specifying routes. eg /users/[name].tsx for /users/:name It uses a manifest file. I remember when entity framework in C# had a separate file that represented the mappings of the database. The problem is the database and the manifest would get out of sync. I imagine the same thing would happen here. There is no documen…

The naming convention is no different to Next.js, arguably the most popular frontend framework currently

Re: Fresh – Next-gen web framework

#214

Post by 1337shadow »

jasfi wrote: post #115
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…

The htmx library is a good way to do that: https://htmx.org

Unpoly.js also good

Re: Fresh – Next-gen web framework

#215

Post by e12e »

csmpltn wrote: post #200
chrischen wrote: post #175

Earlier quoted context omitted.

Knowing what it is now, describing it that way makes total sense... but it only works for people after knowing what it is... kind of like an inside joke. For anyone wondering what it means: it ships only the JS for select components (usually ones that have some sort of client-side interactivity, such as the incrementing counter on their demo page), so it only has to hydrate that part (where hydration is reconciling t…

I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much…

> People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months.

Well, kind of. The thing is that the natural progression from server side rendering/content-generation with only html and css, via Asynchronous JavaScript and XML (AJAX) to the current js-first paradigm - was a transition from hypertext document system to "movable code" (In the terms of Fielding's REST thesis)[1].

Keeping state/cache consistent works differently in the two paradigms (and they have different benefits/trade-offs).

There's a real tention between "application" and "document system". And a lot of what seems insane about contemporary web dev, is when people take something that is clearly easily/well solved as a "document system" (eg: blog/homepage) - and implement it as an application (essentially writing half of a web browser in js - with custom routing/addressing and widgets).

It's the reverse of the problem react et al tries to solve: writing an application using a document system (ie: a complex php app).

[1] Ed: In particular "Mobile Agent" - the last section in https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...

Re: Fresh – Next-gen web framework

#216

Post by lbriner »

LeanderK wrote: post #148
eyelidlessness wrote: post #128

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?

The way I read it, you might have lots of javascript to compute and render your e.g. counter control but you can keep that on the server side, only return the (much smaller) piece of HTML code and ONLY the JS needed to make the control interactive.

I don't know whether this means that it doesn't work as SPA any more since if you want to keep the best of both, you will end up creating more4 complexity, a new framework to learn and probably get marginal improvements at best.

Re: Fresh – Next-gen web framework

#217

Post by jhgb »

madeofpalk wrote: post #185
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…

If you think it's bad then why do you use it? Browsers still support just HTML. You can shove a just a script tag down in the page. Eventually, you'll have enough devs working on this you'll start to run into issues with how you coordinate your work. Your site becomes large enough the code gets more complicated and needs organising to work on it without slowing you down. You'll start to reinvent the above tools to so…

> If you think it's bad then why do you use it?

I didn't see GP make the claim of using it?

Re: Fresh – Next-gen web framework

#218

Post by chrisweekly »

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…

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

#219

Post by FpUser »

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.

Re: Fresh – Next-gen web framework

#220

Post by csmpltn »

zepolen wrote: post #208
csmpltn wrote: post #200

Earlier quoted context omitted.

I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much…

You can't compare JS SSR with PHP, SSR implies there is CSR which is not the case with PHP. Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward. And I say this as someone who was developing CGI scripts before PHP came along.

> "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward."

This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about.

1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversation with different trade-offs, there's no one-size-fits-all here. It's disingenuous to paint this as an ideal we all have to work towards on a whim.

2. I don't even know where's the innovation in being able to "send the minimum necessary over the wire". This is a pillar of decent software engineering. We've been severely regressing here due to the pervasive use of bloated abstraction layers, combined with a deep lack of understanding of how things work (ref. the Uncle Bob post I've linked earlier).

Post reply on HN