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

111–120 of 463 posts

Re: Fresh – Next-gen web framework

#111

Post by jchw »

jonobird1 wrote: post #49
jchw wrote: post #37

Earlier quoted context omitted.

Even if you wanna be cynical, this is a really boring and overplayed take in my opinion. Most frameworks are indeed kind of bloated for running useless hello world demos. Most C compilers give you some kilobytes of code that isn’t necessary for hello world either, even worse for other respected and modern languages like Rust and Go. It can be forgiven if you consider that most of these things are not tuned for optima…

This comment is the overplayed take that because a lot are heavy frameworks, that this should be acceptable. As soon as something is classified as a framework, it seems ok to be >200kb. If you take Tailwind CSS for example, when correctly using their CLI tool, it only includes the size of the css classes actually used, keeping it to a minimum, when compared to people just doing a standard import of the entire library…

The word framework doesn't really actually mean anything. People have a feel for it, but there is no concrete "this is a framework, not a library." However, I think that for most people, the criteria isn't actually related to how large the software is, but rather the feeling of using it. When you use a non-framework library, it feels like using a wrench or a drill; it's a tool. When you use a framework, it feels like you're writing code inside it, not using it. Frameworks can be small. The term "microframework" exists for this exact reason.

Semantics aside, the existence of things with different philosophies doesn't immediately invalidate everything that doesn't give you the same tradeoffs. For one thing, Tailwind deals with declarative CSS output, not imperative modular code. I'm not saying that makes it stupid or anything, but it's very apples and oranges. There are very few JS libraries or frameworks that can offer starting-from-zero KiB JS; maybe Svelte comes close? Ironically, if we're talking about client side bundles, it seems as though Fresh actually does start with 0 KiB, as it does not default to shipping JS code to the client at all.

This doesn't feel like a rational discussion at all. It feels like it's just necessary to come up with a cynical take because there's a new JavaScript thing. In a few weeks there could be some Rust FRP webassembly UI thing that has a 1.2 MiB hello world and hardly anyone will care.

Re: Fresh – Next-gen web framework

#113

Post by paxys »

0des wrote: post #28

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

Re: Fresh – Next-gen web framework

#114

Post by imiric »

jchw wrote: post #37
0des wrote: post #28

Quoted post unavailable.

Even if you wanna be cynical, this is a really boring and overplayed take in my opinion. Most frameworks are indeed kind of bloated for running useless hello world demos. Most C compilers give you some kilobytes of code that isn’t necessary for hello world either, even worse for other respected and modern languages like Rust and Go. It can be forgiven if you consider that most of these things are not tuned for optima…

Is this satire? I honestly can't tell, but it made me laugh.

If not, why in the world would a hello-world demo need optimization? By definition it's supposed to be the simplest thing you can build to showcase the features of what you're using. If the simplest project has the properties GP mentions, then it's not a good demo.

Re: Fresh – Next-gen web framework

#115

Post by jasfi »

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

Re: Fresh – Next-gen web framework

#116

Post by Hedepig »

jonny_eh wrote: post #102
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…

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

Choosing the tool that fits best with the requirements saves a bunch of time during a project lifecycle.

Re: Fresh – Next-gen web framework

#117

Post by fauigerzigerk »

solardev wrote: post #59
lmiller1990 wrote: post #9

I don't fully understand the difference between this (and something like Remix, which seems similar) and other frameworks like Next.js (React) and Nuxt.js (Vue). Can someone explain a bit about the differences, and pros/cons to each?

(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…

>Seconds later after the HTML has loaded, some "bootloader" JS then downloads all the other JS that enables interactivity...

So until that happens the UI looks functional but isn't. The user is left to tap/click furiously on that button but nothing happens?

It sounds to me like this is only suitable for pages where interaction is an exceptional thing that users will only attempt to do after reading some content.

Re: Fresh – Next-gen web framework

#118

Post by hackererror404 »

asadlionpk wrote: post #112

Does anyone know what software can be used to design the juicy hero animation seen here?

It's an SVG animation. There are a number of programs that can be used to create such an animation.

I use Flow, pretty simple to use and it's included with setapp (an app subscription platform on mac).

https://createwithflow.com/

You can also check out svgator, it's an online based solution. https://www.svgator.com/

Cheers!

Re: Fresh – Next-gen web framework

#119

Post by jchw »

datalopers wrote: post #15

Quoted post unavailable.

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 that it's doing, and yet still criticizing it as if you do.

We don't need this circus every time a new JS thing is released.

Re: Fresh – Next-gen web framework

#120

Post by 0x6c6f6c »

halfmatthalfcat wrote: post #10

Why use '$' as the package namespace prefix/identifier instead of the already agreed upon convention of '@'? E.g. '@fresh/{package}' vs '$fresh/{package}'. Seems like a departure from the norm for no reason unless there's some Deno particularity about it.

Because the '@' convention is for organizations, not the actual package, e.g. '@company/pkg'. In this case, '$fresh' is the actual package, and there is no organization name.

This just may be the Deno standard for their import mapping functionality since they also do full URLs for imports like Go (sans schema) normally.

Deno is also just not exactly like JS ecosystems, and that's exactly the point too. Opinionated defaults, out-of-the-box support for TypeScript, death to NPM.

Post reply on HN