11–20 of 170 posts
This starts to make sense when you consider the self-flagellation of a full server-side-rendering production setup that has existed over the past decade, to the point many SPA products completely give up on SSR - or nowadays throw themselves at the walled garden of Vercel/Next.js etc to solve it for them.
Earlier quoted context omitted.
I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.
The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML
"time to interactive: 1.0s / first content paint 1.0s" My man, let me introduce you to ... HTML. It has "time to interactive" at 0.0 seconds and content paints instantly!
How are the cache control headers with this set-up - is there a varnish or similar cdn/cache doing useful work (I'm assuming not, more importantly I'm worried pointing something like fastly at this will fail in caching static pages?).
> rendered dynamically, just in time, at the edge, close to the user. HTML. You're serving HTML. Doesn't really matter that the server-side language is JS, PHP, or BASIC.
Aaron from Deno here. Of course it's producing HTML as an output, but the point is that you can use JSX and familiar technologies like tailwind to dynamically generate that HTML at edge vs client side. And unlike a pure static site, you can add API or form routes
"time to interactive: 1.0s / first content paint 1.0s" My man, let me introduce you to ... HTML. It has "time to interactive" at 0.0 seconds and content paints instantly!
I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.
As other posters have pointed out, why not do it in HTML from the start? It's more simple and efficient than this -or any- framework. Just drop the ol HTML file on your server and away you go!
I understand that the supposed "real" utility in this would be when you want to do JS-y things in HTML (auth, API, hand state, etc), but they don't show any of that on their showcase site...so...yeah.
Earlier quoted context omitted.
I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.
The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML
If you can elaborate on how statically-served HTML would render orders of magnitude faster than server-sider-rendered HTML with a similar response time, I'd love to hear it.
Earlier quoted context omitted.
I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.
The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML
I don’t think a simple, static site is a great example for an entire framework
What other kinds of examples would you like to see ? The goal was to showcase simple yet intuitive JSX + tailwind at edge, we didn't elaborate on more advanced use-cases like authenticated pages, API endpoints/forms, dynamic pages (location, etc...) or parametric routes.
Earlier quoted context omitted.
The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML
You can see for yourself with the provided Pagespeed metrics that the root document was served in around 30ms (corresponding to TTFB). If you can elaborate on how statically-served HTML would render orders of magnitude faster than server-sider-rendered HTML with a similar response time, I'd love to hear it.
Earlier quoted context omitted.
I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.
The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML