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

401–410 of 463 posts

Re: Fresh – Next-gen web framework

#401

Post by chrischen »

csmpltn wrote: post #335
tomnipotent wrote: post #315

Earlier quoted context omitted.

> argument is that the techniques themselves were "forgotten" and are now being rediscovered Which is a silly, lazy argument. > by people claiming that the term "Server Side Rendering" can't be retroactively applied Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other…

> "The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR." Can you provide even a single example for something we can do with JS running on both the client and…

Doing "new" stuff and being more performant is really in the domain of the web browser, not in the javascript libraries that run on browser engines. Saying React doesn't enable "new" stuff in that regard isn't really fair because React isn't meant to do that. What React does do is allow for the development of maintainable complex applications such as most major web apps you use including Instagram, Facebook.com, Netflix.com, etc.

Re: Fresh – Next-gen web framework

#402

Post by zepolen »

ratww wrote: post #297
zepolen wrote: post #286

Earlier quoted context omitted.

> You can have the backend render partials and only send the affected part. This has been widely in use and battle-tested for about two decades in .NET WebForms, PJAX, Rails Turbolinks and other technologies. No, rendering partials is not a solution once you have a moderately complex app. Example: The user submits a form to change an entity, you need to send a partial back for the successfully submitted form, but you…

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?

Re: Fresh – Next-gen web framework

#403

Post by pier25 »

yencabulator wrote: post #394
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.

the Solid team is working on Start which is their full stack framework

Re: Fresh – Next-gen web framework

#405

Post by radicalriddler »

pier25 wrote: post #404

Did they copy the React API or the client side stuff is a wrapper on top of React? https://fresh.deno.dev/docs/getting-started/adding-interacti... It looks identical to React.

> The framework uses Preact and JSX for rendering and templating on both the server and the client.

On https://fresh.deno.dev/docs/introduction

Re: Fresh – Next-gen web framework

#406

Post by zelphirkalt »

DylanSp wrote: post #246
zelphirkalt wrote: post #104

Earlier quoted context omitted.

Next (no pun intended) thing we will rediscover is using templating engines (only in JS or so), because we realize, that mixing state and behavior is a problem. Then we will have gone full circle, but probably with some unreasonable overhead as a result. Maybe the whole thing of rendering templates will somehow become a part of webpack and everyone will have to configure webpack. Good that classic web frameworks are…

Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typecheckin…

> Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code.

I get that. The thing is, that you are already using a "new language" when writing TSX/JSX/whatever. The philosophy of it does not even try to prevent you from making any mistakes. It is like in Python Mako vs Jinja2. In Mako you can run arbitrary Python code easily, so you need a lot of discipline to not screw up. In Jinja2 you are mostly just handing in the data to render the template, perhaps apply some filter or so. This help inexperienced developers to keep clear boundaries between the view layer and other layers. But with TSX/JSX/etc. all that is thrown out of the window again and people will do anything they want in a place, where there should be view code only.

Whether I need to learn which elements can be inside which other elements in TSX/JSX, as it is not HTML + JS or anything and it does not allow mostly (!) arbitrary nesting like HTML, or I learn a templating language, which is more traditional ... I have to learn a new little language (perhaps DSL, or whatever one could call it) anyway.

And with the swing back to server-side rendering, the question arises, whether we really should mix all that state and behavior together again and forget mostly about the lessons of the past.

Re: Fresh – Next-gen web framework

#407

Post by zelphirkalt »

qudat wrote: post #358
DylanSp wrote: post #246

Earlier quoted context omitted.

Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typecheckin…

> that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. This is exactly what I find frustrating about go templating. I lose autocomplete and type hints.

Makes me think of Scheme and SXML, where you never leave the context of the language. Transfer that to something statically typed, and you would get what you want. Maybe something like that exists in Haskell or a similar language?

Re: Fresh – Next-gen web framework

#408

Post by hunterb123 »

meowtimemania wrote: post #399
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?

I'm not familiar with their implementation, but it could be that the bundling is only a temporary solution for browsers that don't support import maps. Or a light layer on top of it.

Import maps are pretty cool, you don't need to bundle in modern browsers and it plays to http2's parallel request strengths.

Re: Fresh – Next-gen web framework

#409

Post by lucacasonato »

davidravid wrote: post #86

it looks amazing solution, how much it cost?

It's open source, and runnable on any server that you can run Deno on (so any reasonably modern Linux, macOS, or Windows) system. You can also host it on our managed edge runtime offering, Deno Deploy.

Re: Fresh – Next-gen web framework

#410

Post by tbeseda »

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.

I think the convention of `~somepackage` is more common than using `@` as a shortcut.
Post reply on HN