Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fresh is a new full stack web framework for Deno

deno.com

Post reply on HN
Print view View original

241–249 of 249 posts

Re: Fresh is a new full stack web framework for Deno

#241

Post by keithly »

pnt12 wrote: post #240
mbgerring wrote: post #197

In 2007 I was writing websites that were mostly rendered on a server, with JavaScript used selectively in some places for interactivity I remember writing at the time that moving everything to the client was solving one problem (poor encapsulation of JavaScript-powered front-end components) with another (needlessly rendering everything on the client) The industry moved toward CSR anyway, and I had to learn it to cont…

As posted in a similar HN thread: thesis, antithesis, synthesis. An idea comes up. It solves problems, but it also has shortcomings. An antithesis that deals fixed the shortcomings comes up and is adopted. Turns out it also has shortcomings of its own. The synthesis merged them together. And repeat. (these are the ideas from some thinker whose name I forget)

Hegel

Re: Fresh is a new full stack web framework for Deno

#242

Post by aabhay »

WORMS_EAT_WORMS wrote: post #153
aabhay wrote: post #136

We are using the pre release version of Nuxt v3 in production. I really like Nuxt’s developer experience and it is my go-to for front end development. As a backend, I truly don’t pay much attention to whether it’s Firebase + Workers, Vercel, Cloudflare, etc. The framework basically does it all under the hood for us.

I disagree but glad I saw this. I think as these edge runtime things get more feature rich, it's going to pay off to be all-in on one that does it perfectly exactly optimized with an easy pathway vs expecting third party packages to figure out an implementation and stay up to date.

What kinds of feature richness are we to expect from edge runtimes? It seems like it’s just like a CDN that can execute code.

Re: Fresh is a new full stack web framework for Deno

#243

Post by Already__Taken »

threatofrain wrote: post #177
pxeger1 wrote: post #165

Earlier quoted context omitted.

Deno and Node are not generally compatible: - their module/packaging systems are totally different - their APIs for interacting with the system are different

How far along is the story of cross compilation for the two ecosystems?

I had no joy trying to get a node JIRA library to run under deno with the various platforms. So still some way to go. Didn't seem far off. IIRC axios was the problem.

Re: Fresh is a new full stack web framework for Deno

#244

Post by likortera »

stack_framer wrote: post #206
jokethrowaway wrote: post #137

Earlier quoted context omitted.

To each his own, personally I stay away from Django and full fledged frameworks (context: I run a few small saas and launch new products frequently). I find that having to dig to find out how things are done and trying to hack around the framework is the cause of bugs and frustrations. I still manage two services based on Django and they're a continue cause of pain. I'd rather spend a week at the beginning of the pro…

> I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies. Me too. I don't use create-react-app or anything else to set up my Node.js/React/TypeScript/SWC projects. I install each package I need manually, and configure each item precisely how I want it (tsconfig.json, webpack.config.ts, .swcrc, even .eslintrc.json). Makes for a nice, lean project every t…

And almost impossible to understand or maintain to anyone coming after you to the project.

The benefits of frameworks is that there's shared knowledge on how to use it, lots of documentation and they are more battle proven.

There's a reason people are not writing assembler. Reinventing the wheel every single time has its trade offs too.

Re: Fresh is a new full stack web framework for Deno

#245

Post by ChefGabe »

swuecho wrote: post #227
quickthrower2 wrote: post #226

The issue I have is, if I understand correctly, you need to go to the server for everything. Their sauce is of course that server is close, maybe 10ms away. But it needs to be online, and so do you. If most things interactive on your site need a round trip BEFORE the interactivity (e.g. a Like button) then this is OK. However if you are writing a web app which does a lot of stuff offline and there is no reason for it…

That's exactly the island in Fresh does. Use Island for interactivity

And what happens to 60fps when your server is 100+ms away

Re: Fresh is a new full stack web framework for Deno

#248

Post by ecares »

pxeger1 wrote: post #165
andruby wrote: post #155

Earlier quoted context omitted.

I didn’t find a mention id this Fresh framework could also run on Node. In other words: is it relying on anything deno-specific?

Deno and Node are not generally compatible: - their module/packaging systems are totally different - their APIs for interacting with the system are different

It took a friend and I 2 days last year to build a compatibility layer that allowed to run all the tests of Deno on Node.

Re: Fresh is a new full stack web framework for Deno

#249

Post by akatechis »

juancampa wrote: post #229
mbgerring wrote: post #197

In 2007 I was writing websites that were mostly rendered on a server, with JavaScript used selectively in some places for interactivity I remember writing at the time that moving everything to the client was solving one problem (poor encapsulation of JavaScript-powered front-end components) with another (needlessly rendering everything on the client) The industry moved toward CSR anyway, and I had to learn it to cont…

I just thought of a possible reason. Maybe because the internet is generally much faster and lower latency these days? So rendering on a server can provide a good UX today, but it couldn't in 2007? Was "the edge" such a prominent concept back then? I honestly don't know if this is a good explanation or not, I have no data at hand to prove it, but I think it makes sense.

The "edge" didn't really exist at the time, along with concepts like cloud, serverless. I seem to remember that even CDN was an evolving architecture idea at the time.

AWS et al had not yet turned web servers into a commodity, so it wasn't feasible to "just deploy the software to multiple regions" to improve latency.

Post reply on HN