181–190 of 249 posts
Yes, they also firmly keep the claim that fresh doesn’t have a build step. Hint: It does [^1]. They’ve just hidden it for most people by making it part of the local testing.
The post seems to claim that there is no drawbacks others approach with the 0 bytes of js, and link to a blog post [1] that absolutely tells nothing how to properly manage back/front state and rendering consistency between the rendering and the «islands» on the client. [1] https://jasonformat.com/islands-architecture
The difference being it's all one isomorphic (?) React-y Deno codebase instead of the tangled PHP+jQuery mess.
Promising enough, if you ask me.
Earlier quoted context omitted.
> 100ms added latency can cost you 7-8% in conversions i hear this metric (or something equally absurd) cited frequently and have never seen it to be true in my own experience. i guess if you have to load a product page with 100 images (or assets) and each has 100ms network latency, then it will add up to much more than that. but 100ms for a single interaction or network request (e.g. process payment POST) is not goi…
I've worked in e-commerce for a while and have heard similar stated from time to time and seemed like someone was trying to fit a linear line over what's almost certainly an s-curve distribution. At lower latencies no one is going to leave your site because it takes 1200ms instead of 1000ms to fully load a page. But at some point almost everyone is going to leave your site rather than wait. I also find these stats re…
Earlier quoted context omitted.
> 100ms added latency can cost you 7-8% in conversions i hear this metric (or something equally absurd) cited frequently and have never seen it to be true in my own experience. i guess if you have to load a product page with 100 images (or assets) and each has 100ms network latency, then it will add up to much more than that. but 100ms for a single interaction or network request (e.g. process payment POST) is not goi…
I could see the 100ms/7% impact coming into play for a super impulsive shopper going from page to page compulsively until they pull the trigger on a product. I wouldn't be surprised if that was a lot of Amazon's business—people buying things they had not set out to buy. Makes less sense the smaller an e-shop gets since the consumer already needed intent to shop there. If I know I already want product X on Shop Y toda…
Earlier quoted context omitted.
CSR is expensive, because you lose customers over bad performance (measurably), and you can not scale the client. You can however scale the server.
modern JS runtimes are extremely fast on all hardware that's not a 2000-era phone or an embedded micro-controller with 4MB ram. if your CSR is slow on a modern client, then that same JS code will bring your server to its knees when you simply migrate it to an equivalent V8-powered JS backend. scaling the server will not solve this; you just have to write fast JS code and pay attention when you write it, not merely op…
> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML. server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8? for a properly-chunked app, hopefully m…
This was my thought, too. In reality, client side rendering today is “cheap” because you typically put a CDN in front of your application to serve static resources and scripts, and your backend only serves the API requests (if needed). Rendering everything on the backend means by contrast that you’re limited to the capacity of your server and the latency based on where it’s located.
SSR definitely has drawbacks in the old "run your app from a single VPS somewhere" model, but in a globally distributed edge computing model, you remove a lot (but not all) of those drawbacks.
Earlier quoted context omitted.
modern JS runtimes are extremely fast on all hardware that's not a 2000-era phone or an embedded micro-controller with 4MB ram. if your CSR is slow on a modern client, then that same JS code will bring your server to its knees when you simply migrate it to an equivalent V8-powered JS backend. scaling the server will not solve this; you just have to write fast JS code and pay attention when you write it, not merely op…
In theory yes, but in practice the majority of modern SPAs are slow and bloated.