Fresh – Next-gen web framework • Hacker News Board

Re: Fresh – Next-gen web framework

#261

Post by FpUser » Mon, Jun 13, 2022, 1:12 PM UTC

kortex wrote: post #253

FpUser wrote: post #219

Earlier quoted context omitted.

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.

Why? This is just what language does - it's like a constantly evolving entropy code. Jargon emerges to concisely describe unique concepts. Hydration is a great example: it's important in the process, so it gets talked about a lot, but it's distinct from rendering, so it gets its own term. Likewise, ingress/egress is not quite the same as read/write. It gets its own terminology because it's distinct.

Egress/ingress rate - rate of the traffic that exits / enters an entity or a network.

I see zero difference with entity/network read/write rate.

As for hydration - sounds highly inappropriate to me but whatever warms the cockles of their hearts.

Re: Fresh – Next-gen web framework

#262

Post by quelltext » Mon, Jun 13, 2022, 1:13 PM UTC

thr0wawayf00 wrote: post #232

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…

> It's just not hip anymore, because it wasn't invented within the past 36 months. Yes, technology moves in cycles but statements like this grossly generalize. The amount of Javascript running on the web has exploded over the last decade plus to the point that frameworks like React were released to create more modern, interactive experiences because that's what business demanded. Then the industry started figuring ou…

> Then the industry started figuring out that the virtual DOM was kind of a scam from a performance standpoint

Could you elaborate?

Not a frontend guy but my understanding was that the virtual DOM is what's necessary to enable a simplified model where you can code as if your entire view was rerendered from scratch when there's a change.

Mutating the DOM only where and when you need to in a handcrafted fashion is always going to be faster, it's just not scalable, I guess.

So, in that context the virtual DOM is not really a scam. Not sure in what sense it is? Was it claimed to be performing better than it does?

Re: Fresh – Next-gen web framework

#263

Post by ratww » Mon, Jun 13, 2022, 1:15 PM UTC

zeroonetwothree wrote: post #259

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…

I’ve been developing for the web since, well not quite 30 years ago (PHP isn’t even 30!), but let’s say 25 years ago. I’ve used so much different tech in those years that I have a pretty good sense of it, and I even contributed to the development of both PHP and React. And you are totally off base. Modern frameworks are far superior for building modern web apps than older serverside tech. Demands have changed and so…

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 used to do.

I personally enjoy both the old and new techniques, and I think it's a natural progression to use those new frameworks for also rendering on the server. Not only because of code-sharing, but because I think they're better than old templating engines.

Re: Fresh – Next-gen web framework

#264

Post by ratww » Mon, Jun 13, 2022, 1:20 PM UTC

mypalmike wrote: post #225

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…

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 from users. Sure, the raw-html interpolation is not a default anymore, but like I said that's also present in old backend tech.

Re: Fresh – Next-gen web framework

#265

Post by ratww » Mon, Jun 13, 2022, 1:23 PM UTC

techdragon wrote: post #205

noobermin wrote: post #191

Earlier quoted context omitted.

Isn't this how webpages used to work with jquery? Are you telling me everything just went full circle back?

Yep, we’re reinventing all the classic server side templating tech, but with “front end frameworks”… which I suppose is actually making them “full stack frameworks” but that’s beside the point.

I wouldn't call it reinventing.

We're just using newer client-side frameworks to also render things on the server, because for lots of people there is a clear advantage in using such frameworks rather than old templating engines. Advantages often include more ergonomic APIs and code-sharing.

Re: Fresh – Next-gen web framework

#266

Post by asadlionpk » Mon, Jun 13, 2022, 1:24 PM UTC

hackererror404 wrote: post #118

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!

These are great, thanks!

Re: Fresh – Next-gen web framework

#267

Post by WuxiFingerHold » Mon, Jun 13, 2022, 1:26 PM UTC

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 (Client Side Rendered) https://hackernews-csr.ryansolid.workers.dev (by the way, there're other implementations like Remix or Svelte as well)

IMO very hard to beat. For larger apps we can use component based code splitting.

The new SSR frameworks are very complex. So there's a downside to it.

Of course there's a big market for the cloud providers as you need to run and pay for a server for your SSR instead of simply serving static JS! That's why there's such a hype lately. I'm not convinced that the performance gains are worth the complexity, costs or vendor lock in.

Again, check out the SolidJS example app I've linked above and measure for yourself if you really need the additional cost and complexity of a server pre-rendering, hydrating, etc..

Re: Fresh – Next-gen web framework

#268

Post by ratww » Mon, Jun 13, 2022, 1:31 PM UTC

quelltext wrote: post #262

thr0wawayf00 wrote: post #232

Earlier quoted context omitted.

> It's just not hip anymore, because it wasn't invented within the past 36 months. Yes, technology moves in cycles but statements like this grossly generalize. The amount of Javascript running on the web has exploded over the last decade plus to the point that frameworks like React were released to create more modern, interactive experiences because that's what business demanded. Then the industry started figuring ou…

> Then the industry started figuring out that the virtual DOM was kind of a scam from a performance standpoint Could you elaborate? Not a frontend guy but my understanding was that the virtual DOM is what's necessary to enable a simplified model where you can code as if your entire view was rerendered from scratch when there's a change. Mutating the DOM only where and when you need to in a handcrafted fashion is alwa…

Your understanding is correct.

Virtual DOM never promised better performance than pre-rendered static HTML. It only achieves better performance (and better UX) than dumbly re-rendering the whole website whenever the underlying data changes.

The reason people are doing SSR with modern JS-frameworks is quite simple: some kinds of content aren't a good fit for SPAs (or maybe there are other constraints that favour rendering it all in the server), but it might still be desirable to use modern JS-frameworks. For example: you wouldn't implement a blog as an SPA, but it might still be desirable to use React to render everything.

Re: Fresh – Next-gen web framework

#269

Post by totallymike » Mon, Jun 13, 2022, 1:32 PM UTC

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…

This feels like a strange argument to make when server-rendered HTML has been the norm for decades, and it's only been recently that SPAs have become popular.

Re: Fresh – Next-gen web framework

#270

Post by indymike » Mon, Jun 13, 2022, 1:34 PM UTC

e12e wrote: post #215

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…

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

> There's a real tention between "application" and "document system".

Not really. The web implements a "document as application" or "living document" model. Since the most rudimentary software is just printing static text (and static graphics) you get quite a bit of mileage with just HTML & CSS. The web scales nicely from this to fully interactive applications, and I think some of the tension you are perceiving comes from the fact it's easy to disable or override features built into to the browse, and often developers find a way to do something novel, and in doing so, break thinks like the clipboard.