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

421–430 of 463 posts

Re: Fresh – Next-gen web framework

#421

Post by nindalf »

chrischen wrote: post #395
nindalf wrote: post #387

Earlier quoted context omitted.

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…

From your link

> Yes, Facebook uses SSR heavily. However, according to Lee, there are very few areas where they use React to render components on server. This was primarily a decision based on their server environment which is Hack.

Yeah this is my whole point. That person was attempting to school devs at Facebook on the benefits of server side rendering in PHP.

And whatever you said was quite niche.

Re: Fresh – Next-gen web framework

#422

Post by kennywinker »

hunterb123 wrote: post #400
kennywinker wrote: post #349

Earlier quoted context omitted.

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.

I actually am aware of the difference between a web app and a document, and I used the correct word. Thanks

Re: Fresh – Next-gen web framework

#423

Post by xmprt »

tomstuart wrote: post #146
xmprt wrote: post #131

Earlier quoted context omitted.

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?

“The page remembers the click” was the original intent [0], but the latest version of React includes a feature called selective hydration [1] which can hydrate a component synchronously in response to an event if possible (i.e. without replaying the event). Naturally React itself has to be loaded for any of that to work. [0] https://twitter.com/dan_abramov/status/1200118229697486849 [1] https://github.com/reactwg/rea…

Follow up: How does the HTML "remember" the events to replay without any help from Javascript?

Re: Fresh – Next-gen web framework

#424

Post by lucacasonato »

pier25 wrote: post #413
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...

Maybe it has a cache and this only happens the first time? It would be a bit ridiculous to re-compile JSX into JS on every request.

Yeah, it doesn't do this. The transpiled output is cached indefinitely for a given deployment.

Re: Fresh – Next-gen web framework

#425

Post by okhobb »

iamsaitam wrote: post #320
okhobb wrote: post #71

Earlier quoted context omitted.

This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?

What is a good argument against it? It makes understanding the layout of the website easily and saves you from having to come up with your own conventions around it.

I generally prefer keeping all the configuration in as few languages as possible and preferably in a single language. Adding filesystem-based config where a config option object in the main language of javascript would suffice goes against that.

Also, given a filesystem config, now I'm forced to have many very small files around for each route where each file is most likely just a call to another service handler. I'd prefer to mash most into bigger files that handle related but distinct routes.

Less important, but comes up, it's nice to be able to match routes based on code and not just string equality ... e.g. everyone seems to like having routes for usernames start with '@'

Re: Fresh – Next-gen web framework

#426

Post by ratww »

chrischen wrote: post #381
ratww wrote: post #263

Earlier quoted context omitted.

While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered. This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP u…

SSR isn’t a technique though. Functional UI composition is a technique, and SSR is an optimization being brought back to this technique.

Yes it is. It's a method of achieving something or carrying something out. But not only it doesn't matter, I don't think anyone else is interested in a stupid semantics discussion.

Re: Fresh – Next-gen web framework

#427

Post by ratww »

zepolen wrote: post #402
ratww wrote: post #297

Earlier quoted context omitted.

The solution to this completely hypothetical an unrealistic problem is to just not have too many partials to begin with. Which is the reality of 100% of the apps made with the libraries/frameworks I mentioned, WebForms, PJAX and Turbolinks.

Ok then what benefit is there over a regular page load?

Faster response to user actions, smaller payload, not reloading the whole page, keeping scrolling position, keeping focus and keyboard cursor position when possible, allowing transitions and animations, no need to change browser history unless necessary, very minimal javascript necessary, allowing user to disable javascript in some cases.

Just because this is a counterexample to something that you deem good, it doesn't mean it has to be absolute shit. The world is not black and white. I would suggest at least doing some research about how things work before criticising them. They might surprise you.

Re: Fresh – Next-gen web framework

#428

Post by sangnoir »

dixego wrote: post #326

Sometimes I wonder how much time humanity as a species has collectively spent first inventing and then trying to solve the problem of "making a website".

Far less than humanity has spent on "convince people to buy product X" when X has many alternatives that are perfectly serviceable...or even superior.

Re: Fresh – Next-gen web framework

#429

Post by baobabKoodaa »

pier25 wrote: post #419
baobabKoodaa wrote: post #157

Earlier quoted context omitted.

Many Node-based JS frameworks, such as Gatsby or Next, allow SSG that can be distributed by a CDN. Your comment is weird.

Dynamic responses also can be cached in a CDN you know...

The whole point of static site generation is that you don't have to manage servers; that you can instead simply generate your assets and distribute them via CDN. Sure you can manage servers and put a CDN in front of your servers, but then you still have to manage those servers...

Anyway, you're missing the crux of my point. I was criticizing GP for implying that all NodeJS-based frameworks require a dynamic server to run respond to queries at runtime. They don't.

Re: Fresh – Next-gen web framework

#430

Post by mypalmike »

ratww wrote: post #264
mypalmike wrote: post #225

Earlier quoted context omitted.

Quoted post unavailable.

While Vanilla-PHP was definitely mostly just doing text substitution and had injection issues, there were other languages and template engines that were able to fix this by having more sensible defaults where raw-html interpolation is not a default. Also, keep in mind that injection attacks are definitely still possible with modern frameworks. The same old techniques apply when you're dealing with data originating fr…

The comparison I am responding to is original PHP ("30 years ago", which itself is garbage of course, given the language did not exist 30 years ago), not the new goalposts you have planted.
Post reply on HN