My wife keeps sending me random pictures of our cat rendered as a cuddly toy and I’m here for it.
It's been fun adding the archive of my tweets to my own site.
https://www.hawksworx.com/notes/
- Index of all tweets paginated into ~1000 pre-gen pages
- ODB (on-demand) render + cache of any specific tweet page
- Speedy (but basic for now) searching with Edge Functions
@Igloczek @remotesynth @stefanjudis @timbenniks SSR is more slippery because it's not a very definitive term.
It might be in an active server (not Jamstack) or it might be delivered via an Edge Function instead (Jamstack?!)
I think of SSR as at "runtime rendering not on the client", but my campaign for RRNOTC has gone badly
It might be in an active server (not Jamstack) or it might be delivered via an Edge Function instead (Jamstack?!)
I think of SSR as at "runtime rendering not on the client", but my campaign for RRNOTC has gone badly
@jlengstorf A leading enterprise CMS was unable to present content in the components needed, so instead it rendered all possible content into the HTML as JSON and then re-rendered everything needed for that page client-side with JavaScript.
The SEO, A11y, and perf impacts were comical
The SEO, A11y, and perf impacts were comical
@jlengstorf 10 months of engineering work to hit ambitious browser performance goals for a heavy design undone on launch day thanks to the customer adding 8 different analytics tracking products 7 of which were render blocking.
And Google Tag Manger.
#enterprise
And Google Tag Manger.
#enterprise
RT @IleshMistry: The #Jamstack #MMT_TechMeetup had @philhawksworth talking about "Rendering models that scale. Whatever your framework"
Se…
Se…
@andyhawkes @Netlify @eleven_ty …and if you wanted to mint a unique shareable URL for every recipe permutation, you could do that on demand rather than at build time with Eleventy’s serverless rendering (which is just a helper for Netlify’s on-demand builders)
https://www.11ty.dev/docs/plugins/serverless/
https://www.11ty.dev/docs/plugins/serverless/
This should be fun!
I’ll talk about how I migrated an existing site with thousands of pages to use Distributed Persistent Rendering.
There will be lollies. 🍭 https://twitter.com/IleshMistry/status/1461121959643815941
I’ll talk about how I migrated an existing site with thousands of pages to use Distributed Persistent Rendering.
There will be lollies. 🍭 https://twitter.com/IleshMistry/status/1461121959643815941
@mattyfromle @amacarthur @Netlify This looks likes the view of the HTML in dev tools right? So it's the shape of the DOM once the client side JS has done its thing (and looks good). Are you pre-rendering the site into HTML or do you have an HTML only version of this form somewhere in your build?
@mattyfromle @Netlify The way that Netlify creates the endpoint that forms can then post to, is by looking for form elements in the html during the build. So if the form is rendered client-side only, then it won't get detected. Seen this?
https://docs.netlify.com/forms/setup/#work-with-javascript-rendered-forms
https://docs.netlify.com/forms/setup/#work-with-javascript-rendered-forms
@flarup What horribly entitled claptrap!
I can't enjoy a game when it feels like my success depends on surrendering to endless in-app micropayments. I'm hungry for games that are free to try, and then have a price tag I can see and pay. That has value to me.
Congrats on a great launch!
I can't enjoy a game when it feels like my success depends on surrendering to endless in-app micropayments. I'm hungry for games that are free to try, and then have a price tag I can see and pay. That has value to me.
Congrats on a great launch!
@FredKSchott @blue2blond @slightlylate @eleven_ty As long as it sounds delicious, I’m in!
(And you don’t need to use each of J, A, and M for something to be Jamstack. It’s mostly about the pre-rendering.)
But I’m swayed by “ham”.
(And you don’t need to use each of J, A, and M for something to be Jamstack. It’s mostly about the pre-rendering.)
But I’m swayed by “ham”.
@jlengstorf @SalientKnight @cassidoo @levlinds FWIW this is the exact usecase I had in this example which is framework agnostic. 404s are handled by a servlerless function which attempts to render content on demand.
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
@sebastienlorber @zachleat @slightlylate @kylemathews @youyuxi @swyx @sarah_edo @Rich_Harris @eleven_ty I think we can clearly distinguish between the modes/models... but the way one uses the tools can also have an influence. That's why I mentioned their "default".
1. Pre-rendered.
2. Client-side rendered.
3. Hybrid. (Pre-rendered with progressively enhanced client-side rendering)
1. Pre-rendered.
2. Client-side rendered.
3. Hybrid. (Pre-rendered with progressively enhanced client-side rendering)
@sebastienlorber @zachleat @slightlylate @kylemathews @youyuxi @swyx @sarah_edo @Rich_Harris I typically use @eleven_ty to pre-generate all of my views and serve them as HTML. But I could add some JS to that to progressively enhance and fetch JSON of subsequent pages, rendering them with client-side JS.
Many tools can be used for either model of we choose.
Many tools can be used for either model of we choose.
@sebastienlorber @zachleat @slightlylate @kylemathews @youyuxi @swyx @sarah_edo @Rich_Harris If a view of the content is generated in the browser with javascript, I consider that a client-side render.
Gatsby absolutely does client-side rendering. That rendering can happen as an enhancement for subsequent pages after the entry point is delivered as pre-rendered HTML.
Gatsby absolutely does client-side rendering. That rendering can happen as an enhancement for subsequent pages after the entry point is delivered as pre-rendered HTML.
@sebastienlorber @zachleat @slightlylate @kylemathews @youyuxi @swyx @sarah_edo @Rich_Harris The tricky thing is that although these have different defaults, all these tools can be used in builds to employ each model (with additional JS for some).
I think of the 2 models as pre-rendered/ready-rendered and client-side rendered.
I think of the 2 models as pre-rendered/ready-rendered and client-side rendered.
RT @Netlify: Static First: Pre-Generated JAMstack Sites with Serverless Rendering as a Fallback
This post by @philhawksworth on @css is ex…
This post by @philhawksworth on @css is ex…
@aral Nice!
One small clarification about #Jamstack though... you don't need to use 3rd party APIs (or even 1st party APIs, or JavaScript) for a site to be Jamstack. Mostly, it is about pre-rendering so a site can be served directly from a CDN, and decoupling APIs if you have them.
One small clarification about #Jamstack though... you don't need to use 3rd party APIs (or even 1st party APIs, or JavaScript) for a site to be Jamstack. Mostly, it is about pre-rendering so a site can be served directly from a CDN, and decoupling APIs if you have them.
@yoavweiss @DasSurma Will likely to some sort of follow up post in a while perhaps with some results as well as some more background.
What dynamic assets do you mean? Netlify does the compression of the build assets en route to the CDN where they are then cached. We serve things pre-rendered for 🏎
What dynamic assets do you mean? Netlify does the compression of the build assets en route to the CDN where they are then cached. We serve things pre-rendered for 🏎
@polarbirke @hankchizljaw @eleven_ty @Netlify Ha! It's a tough competition where we all win because the web gets faster.
(And also, these are build times for the entire 1200 page site, not client-side page render times. The build does the work, so your browser won't have to)
(And also, these are build times for the entire 1200 page site, not client-side page render times. The build does the work, so your browser won't have to)
@hankchizljaw @eleven_ty @Netlify I should upgrade @eleven_ty from v0.8.3 to v0.10 to see if it gets any sort of site generation speed bump. (Although I'm happy with this, and new pages are available instantly due to the serverless rendering as a fallback)
Happy to see this little demo still chugging away making lollipops for people.
🍭 https://vlolly.net
@eleven_ty takes ~ 6.5 seconds to generate almost 1200 pages.
@Netlify takes ~ 51 seconds to build and deploy the site and the serverless API
? 👉 https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
🍭 https://vlolly.net
@eleven_ty takes ~ 6.5 seconds to generate almost 1200 pages.
@Netlify takes ~ 51 seconds to build and deploy the site and the serverless API
? 👉 https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
"Rendering" - what's that?
There are various terms which convey how we generate HTML or manipulate the DOM. And they can be confusing.
I spent a couple of minutes of this @freeCodeCamp video on JAMstack to describe some popular terms for rendering.
https://www.youtube.com/watch?v=A_l0qrPUJds&feature=youtu.be&t=2496
There are various terms which convey how we generate HTML or manipulate the DOM. And they can be confusing.
I spent a couple of minutes of this @freeCodeCamp video on JAMstack to describe some popular terms for rendering.
https://www.youtube.com/watch?v=A_l0qrPUJds&feature=youtu.be&t=2496
@_rndlph @smashingmag I think I'd challenge the view that it is rarely acceptable.
The majority of sites on the web don't need their views re-rendered on the fly for every request. Or need a database. Think of how many WordPress blogs exist that hit a database for every view, but change infrequently.
The majority of sites on the web don't need their views re-rendered on the fly for every request. Or need a database. Think of how many WordPress blogs exist that hit a database for every view, but change infrequently.
@joeflateau @sarah_edo Yeah, I think Id say so!
You serve your views pre-rendered, populating those at build time. And then use some craft serverless fu to service requests for missing assets directly from the source while you back-fill. Right?
One could argue that serverless isn't JAMstack...
You serve your views pre-rendered, populating those at build time. And then use some craft serverless fu to service requests for missing assets directly from the source while you back-fill. Right?
One could argue that serverless isn't JAMstack...
@joeflateau @sarah_edo Sounds like that starts to blur the edges 😀
I myself have used a lambda to render routes _as a fallback_ while those new routes were being generated. Then they get served from the CDN.
I think of any server-side request-time render as not jammy. But can be a great complement
I myself have used a lambda to render routes _as a fallback_ while those new routes were being generated. Then they get served from the CDN.
I think of any server-side request-time render as not jammy. But can be a great complement
@joeflateau @sarah_edo I think of pre-rendered pages as part of what jamstack is. Jamstack enjoys the benefits of pre-rendering as much as possible (in some cases 100% so... yes) and then being able to serve directly from a CDN. Then if needed, using JS to enhance pages with APIs (browser/content/etc)
RT @NaveenS16: #JAMstack is an emerging term which describes an approach to architecting and delivering sites as pre-rendered assets, and w…
@rposbo @stubbornella @LorienMCS Logically they do seem similar. But in practice and when deploying code and content changes they have quite different implications. If pre-rendering, deployment can be sending everything to the CDN. That’s not the case with SSR if code/data/content might all change independently.
@stubbornella @LorienMCS My experience has been: this is can be tough to get right.
Server side rendering at request time tends to involve querying dynamic sources (or else why do it on demand per request?)
So you need to define the logic of what is dynamic and what is cacheable throughout the stack.
Server side rendering at request time tends to involve querying dynamic sources (or else why do it on demand per request?)
So you need to define the logic of what is dynamic and what is cacheable throughout the stack.
@chrisbiscardi @adactio I think this gets more complicated than JS on or off. I've had "just html" go unresponsive on some devices after it was rendered because my device was blocked while it unpacked, parsed and executed a big JS bundle.
Less so on my >$1000 phone and 4G or with JS disabled.
Less so on my >$1000 phone and 4G or with JS disabled.
@anna_debenham @Cennydd The two hour delay between purchase and surrender is the mark of true love. I salute you.
@infinitelychriz @poozipotti @algolia @reactjs You'd probably pre-render at least an app shell, right? And potentially even pre-render the data sources/pages which get requested via js. In which case, sure :)
@poozipotti @algolia @reactjs Good luck with it! Yes, it is rather a broad term. My rule of thumb is something like:
"Will I have to maintain a web server to host this?"
Since a key part of #JAMstack is being able to host it without the need for a logical server.
Recent thoughts: https://dev.to/philhawksworth/prerendering-is-the-key-to-a-tasty-jamstack-22pp
"Will I have to maintain a web server to host this?"
Since a key part of #JAMstack is being able to host it without the need for a logical server.
Recent thoughts: https://dev.to/philhawksworth/prerendering-is-the-key-to-a-tasty-jamstack-22pp
@poozipotti 2 examples at opposite ends of the JAM spectrum:
http://www.netlify.com is a marketing site & blog which is all pre-rendered (then enhanced with JS to @algolia API for search)
http://app.netlify.com is a @reactjs app, served statically. With lots of client-side APIs for data.
http://www.netlify.com is a marketing site & blog which is all pre-rendered (then enhanced with JS to @algolia API for search)
http://app.netlify.com is a @reactjs app, served statically. With lots of client-side APIs for data.
January seems like a good time to share our thoughts and experiments using #JAMstack.
@shortdiv has been blogging **every day this year** about it.
Now, I've added some #jamuary thoughts of my own.
https://dev.to/philhawksworth/prerendering-is-the-key-to-a-tasty-jamstack-22pp
@shortdiv has been blogging **every day this year** about it.
Now, I've added some #jamuary thoughts of my own.
https://dev.to/philhawksworth/prerendering-is-the-key-to-a-tasty-jamstack-22pp
@gumnos @chriscoyier A JAMstack site might seem reliant
On doing everything in the client
In fact though, it depends on what
Requirements and use-cases you have got
The biggest key though, to remember
Is to serve things statically, and pre-render.
On doing everything in the client
In fact though, it depends on what
Requirements and use-cases you have got
The biggest key though, to remember
Is to serve things statically, and pre-render.
If you are generating sites with many thousands of pages, you may already know that @goHuguo has incredibly fast pre-rendering speeds.
Here, @regisphilibert describes some crafty additional optimisations to speed things up even more by caching partials.
https://regisphilibert.com/blog/2019/12/hugo-partial-series-part-1-caching-with-partialcached/
Here, @regisphilibert describes some crafty additional optimisations to speed things up even more by caching partials.
https://regisphilibert.com/blog/2019/12/hugo-partial-series-part-1-caching-with-partialcached/
@klarstrup @swyx Yeah, I like that combo.
- Generate a view and URL of every page.
- Progressively enhance with client-side rendering and APIs for content.
In some cases that will be perfect. In others that will be over engineering. In others still, it might not be practical. But I like it.
- Generate a view and URL of every page.
- Progressively enhance with client-side rendering and APIs for content.
In some cases that will be perfect. In others that will be over engineering. In others still, it might not be practical. But I like it.
@RapidOwl But if it is all pre-rendered, then you could serve it from anywhere. Including entirely from a CDN with no origin server involved at request time. That's what makes JAMstack sites so massively resilient and scalable.
And you can use PE in the client with APIs to enrich further.
And you can use PE in the client with APIs to enrich further.
@hankchizljaw @css @eleven_ty @Netlify Just checking... you didn't mean this site, right? (For that 35s.)
This site should return any lolly page instantly because it was pre-generated. Or instantly because it wasn't ready yet, but got served directly from the db thanks to a severless render.
This site should return any lolly page instantly because it was pre-generated. Or instantly because it wasn't ready yet, but got served directly from the db thanks to a severless render.
Since posting this little example of user generated content in a #JAMstack site with #serverless fallbacks on @css, over 800 people have "made lollypop pages" 🍭
Some build stats:
- 800+ pages built by @eleven_ty: ~5.2s
- Full @Netlify deploy: ~30s
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
Some build stats:
- 800+ pages built by @eleven_ty: ~5.2s
- Full @Netlify deploy: ~30s
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
Excited to return to this great #JAMstack meet-up in Toronto. I’ll be showing:
- pregeneration
- database as a service
- automation
- user generated content
- serverless rendering
- lollipops
And I’ll have a few copies of the JAMstack book to give away (https://findthat.at/jamstack-book) https://twitter.com/HenriHelvetica/status/1194987955141726208
- pregeneration
- database as a service
- automation
- user generated content
- serverless rendering
- lollipops
And I’ll have a few copies of the JAMstack book to give away (https://findthat.at/jamstack-book) https://twitter.com/HenriHelvetica/status/1194987955141726208
RT @JavaScriptCon: In this keynote by @philhawksworth you’ll explore how an #application can be built to include pre-rendered #userinterfac…
RT @chriscoyier: JAMstack-spirited pre-rendering pages makes sense for a blog, where there might be <1000 pages, but what about a site with…
@thatsmyjamstack @Netlify We talked a bit about using #serverless functions as a fallback to render pages on the fly in place of a 404.
A more detailed description of that and an example which uses this for user generated content on a pre-generated JAMstack site is over here 👇
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
A more detailed description of that and an example which uses this for user generated content on a pre-generated JAMstack site is over here 👇
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
People of @JSCampRo, thanks ever so much for listening to me talk about #JAMstack and serverless rendering.
More details about my proof of concept published on @css here:
http://findthat.at/lollytricks
And slides are available now
https://findthat.at/servered
More details about my proof of concept published on @css here:
http://findthat.at/lollytricks
And slides are available now
https://findthat.at/servered
@chadtomkiss @sebdedeyne @fauna I used it a little (and really enjoyed it) on this example site:
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
The API is nice.
And we recently launched an official @fauna add-on for @Netlify too, which makes the onramp even more straightforward.
https://www.netlify.com/blog/2019/09/10/announcing-the-faunadb-add-on-for-netlify/
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
The API is nice.
And we recently launched an official @fauna add-on for @Netlify too, which makes the onramp even more straightforward.
https://www.netlify.com/blog/2019/09/10/announcing-the-faunadb-add-on-for-netlify/
@K16EInc @lauragift21 @css No. This is not about that. There is no client-side js required to render these pages.
This is about making sure that a view is returned for requests to a URL even if that page has not yet finished being created by a static site generator. Serverless functions as a fallback.
This is about making sure that a view is returned for requests to a URL even if that page has not yet finished being created by a static site generator. Serverless functions as a fallback.
@joaocarmona @swyx Yeah, it's similar. But subtly different.
Serverless Pre-Rendering is using functions to populate the CDN with the pages either after every request, or at a configured interval.
My example assumes everything comes from the build. Only hitting a function if something 404s.
Serverless Pre-Rendering is using functions to populate the CDN with the pages either after every request, or at a configured interval.
My example assumes everything comes from the build. Only hitting a function if something 404s.
I made *a thing* so that I could play with using #serverless functions to render pages on the fly while a site deployment completes.
You can play with it here: https://vlolly.net
And you can read all about it on @css
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
You can play with it here: https://vlolly.net
And you can read all about it on @css
https://css-tricks.com/static-first-pre-generated-jamstack-sites-with-serverless-rendering-as-a-fallback/
@zachleat @DasSurma @jeromecoupe @eleven_ty I use pagination for this on my blog. I want some pages to get rendered as a page, and also to get another representation with a simpler template so that I can use that to make images for OG and social. ( “I add “card” to its frontmatter if I want one)
https://github.com/philhawksworth/hawksworx.com/blob/master/src/site/social-cards.njk
https://github.com/philhawksworth/hawksworx.com/blob/master/src/site/social-cards.njk
Tonight should be fun at @MiddlesbroughFE!
If you are planning on coming along, heads up that there has been a venue change. See you there for talk of:
- #JAMstack
- #Serverless rendering
- @Netlify
- Lollipops https://twitter.com/jamiebradley234/status/1167050514489577472
If you are planning on coming along, heads up that there has been a venue change. See you there for talk of:
- #JAMstack
- #Serverless rendering
- @Netlify
- Lollipops https://twitter.com/jamiebradley234/status/1167050514489577472
Looking forward to speaking at @JavaScriptCon! In this talk, I'll walk through an example of building an example #JAMstack site which:
- Pre-renders all pages as good ol' HTML
- Has #serverless fallbacks for new content
- Automatically regenerates
- Has customisable lollipops 🥳 https://twitter.com/JavaScriptCon/status/1161170659873103872
- Pre-renders all pages as good ol' HTML
- Has #serverless fallbacks for new content
- Automatically regenerates
- Has customisable lollipops 🥳 https://twitter.com/JavaScriptCon/status/1161170659873103872
RT @JavaScriptCon: In this Keynote at #IJScon @philhawksworth will show you how an #application can be built to include pre-rendered #useri…
@khaled_garbaya Nice!
I'd also love to see tips on making architectural decisions. Perhaps...
- What to pre-render, how and when.
- How/if to augment pre-rendered, with rendering-on-demand.
- Choosing a framework to suit your (users') needs
I'd also love to see tips on making architectural decisions. Perhaps...
- What to pre-render, how and when.
- How/if to augment pre-rendered, with rendering-on-demand.
- Choosing a framework to suit your (users') needs
@TatianaTMac @SwissWebMiss @karenmcgrane @sallylait @RenderConf @SaraSoueidan @FronteersConf @charis @hj_chen @webconf_asia @sonniesedge @frontendunited @Una @smashingconf @NikkitaFTW @MinaMarkham @perfmattersconf @BettieRub @csscamp @jscamp @davidpich @Netlify Thanks! That’s very kind.
Excited to cross paths IRL soon at @nejsconf!
Excited to cross paths IRL soon at @nejsconf!
@karenmcgrane I’ve really enjoyed watching
@sallylait MC @RenderConf
@SaraSoueidan MC @FronteersConf
@charis and @hj_chen MC @webconf_asia
@sonniesedge MC @frontendunited
@una MC @smashingconf
@NikkitaFTW MC various
...but would also like to see better representation across the industry
@sallylait MC @RenderConf
@SaraSoueidan MC @FronteersConf
@charis and @hj_chen MC @webconf_asia
@sonniesedge MC @frontendunited
@una MC @smashingconf
@NikkitaFTW MC various
...but would also like to see better representation across the industry
Having real-time previews of how the content will render in the site is great for raising the confidence for content authors.
Lovely to see this in @netlifyCMS and this excellent scaffold project from @andybelldesign. Try it out with a couple of clicks! https://twitter.com/piccalilli_/status/1142523346363584512
Lovely to see this in @netlifyCMS and this excellent scaffold project from @andybelldesign. Try it out with a couple of clicks! https://twitter.com/piccalilli_/status/1142523346363584512
@dev__adi @NaveenS16 @chriscoyier It's both. The more you can pre-render, the better. Low friction, low cost, and automated deployments make pre-generating and deploying very frequently viable. But you are right about scale — for sites with millions of pages, this becomes challenging.
@swyx @mjackson @chriscoyier Yes! Whether rendering in the client with JS because you're shipping an app which demands it, or if you can pre-generate all of your site in markup at build time like with a blog, or somewhere in between, the key to JAMstack is in avoiding the need for an active web server.
@altryne @yoavweiss With #JAMstack sites, you want to pre-render as much as possible. @Netlify Split Testing allows you to serve up different pre-rendered branches right from the CDN to avoid the performance tax you’d get doing A/B tests with JavaScript.
https://youtu.be/5VgpJJUOng4
https://youtu.be/5VgpJJUOng4
@raymondcamden @Netlify 🎉
Names for things are hard. And the cognitive baggage that comes with the word "static" is a big part of why another term is useful.
I'm less worried about the word we use, and more excited by the potential in...
- JAMstack
- Static
- StaticFirst
- Pre-rendered
- ShortStack
Names for things are hard. And the cognitive baggage that comes with the word "static" is a big part of why another term is useful.
I'm less worried about the word we use, and more excited by the potential in...
- JAMstack
- Static
- StaticFirst
- Pre-rendered
- ShortStack
@rem I do it server side at build time.
Because anything I can do ahead of time, I do ahead of time.
It doesn't add markup for me as it is done by my SSG (@eleven_ty) during the build.
One less thing to have as a client-side js dependency and on the render path.
Because anything I can do ahead of time, I do ahead of time.
It doesn't add markup for me as it is done by my SSG (@eleven_ty) during the build.
One less thing to have as a client-side js dependency and on the render path.
@andypimlett @upfrontconf That's a good question.
This is a very light build but a deliberately excessive example to prove a point. Meanwhile it's also an example of a prerendered site architecture which avoids any execution on the server at request time. So under heavy load this is more energy efficient.
This is a very light build but a deliberately excessive example to prove a point. Meanwhile it's also an example of a prerendered site architecture which avoids any execution on the server at request time. So under heavy load this is more energy efficient.
@healves82 @tudor_prodan @smakosh @gatsbyjs @GraphQL @HasuraHQ @Netlify If only this were up to me!
Prepare for... HawkStack™
I think we should use whichever term makes it easiest to communicate what the architecture is. #JAMstack has been getting more broadly understood, but I've also heard:
- StaticFirst
- Pre-rendered
- ShortStack
& more!
Prepare for... HawkStack™
I think we should use whichever term makes it easiest to communicate what the architecture is. #JAMstack has been getting more broadly understood, but I've also heard:
- StaticFirst
- Pre-rendered
- ShortStack
& more!
@superpatell @sebastienlorber @Netlify @zeithq @cloudfront @Cloudflare I'd suggest not doing that.
One of the advantages of this pre-rendered or #JAMstack approach on @Netlify is that your site is served directly from our distributed CDN. It's designed for this scenario. By adding a CDN in front of the CDN, you'll add latency and complexity.
One of the advantages of this pre-rendered or #JAMstack approach on @Netlify is that your site is served directly from our distributed CDN. It's designed for this scenario. By adding a CDN in front of the CDN, you'll add latency and complexity.
@AndyWhalePhoto @frontendyork @imconnorm @AndyCallaghan @Netlify Yep. I like to think about putting as much distance as possible between the users, and the complexity.
Serving assets directly from a CDN after pre-rendering everything can be huge in this regard. And adding small pieces of logic via serverless functions can fill any last gaps.
Serving assets directly from a CDN after pre-rendering everything can be huge in this regard. And adding small pieces of logic via serverless functions can fill any last gaps.
Live coding an AR application on stage at #coldfront18! 🤩
3D rendering, composting and a game including pickles and cats!
What's not to love?!
Nerves of steel from @srdanrasic in this excellent session.
3D rendering, composting and a game including pickles and cats!
What's not to love?!
Nerves of steel from @srdanrasic in this excellent session.
@codemzy @Netlify 👍 In those few places where pre-rendering at build time is not going to cut it, you might indeed use functions to server-render. This example explores using #expressJS that way:
https://github.com/DavidWells/netlify-functions-express
https://github.com/DavidWells/netlify-functions-express
@sankalped @Netlify It doesn't.
There is no webserver to perform server-side rendering at request-time. Instead think of @Netlify as a CDN to serve your pre-rendered sites. Includes are typically performed by the templating of a SSG at build time.
See https://www.staticgen.com/ for leading SSGs
There is no webserver to perform server-side rendering at request-time. Instead think of @Netlify as a CDN to serve your pre-rendered sites. Includes are typically performed by the templating of a SSG at build time.
See https://www.staticgen.com/ for leading SSGs
@smakosh @Netlify It looks like you're using @gatsbyjs for your site, and that it doesn't expose a form as HTML (which the Netlify build bots need in order to create a form API for you)
There is some good info on this in the docs: https://www.netlify.com/docs/form-handling/#javascript-rendered-forms
and an example:
https://github.com/imorente/gatsby-netlify-form-example
There is some good info on this in the docs: https://www.netlify.com/docs/form-handling/#javascript-rendered-forms
and an example:
https://github.com/imorente/gatsby-netlify-form-example
@mattferderer @growdigital @Netlify Also, even with cached DB requests, you still need to render views and serve things on demand. Granted, adding layers of caching can expedite requests, but you are really adding layers of logic that you have to manage yourself which essentially make things behave as if static. :)
@toddmorey I like that I used it both sides back when I made this.
https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
@jrTera3yte @Netlify Standard unhelpful answer: It depends! (On what your site/app does)
More useful guidance: The more you can deliver pre-rendered in your HTML, the more performant and robust your site will be. You can then enhance with calls to the same API client-side too. Best of both! :)
More useful guidance: The more you can deliver pre-rendered in your HTML, the more performant and robust your site will be. You can then enhance with calls to the same API client-side too. Best of both! :)
Ooh, my @render_conf presentation is featured on the home page of @benotist! Yay!
I'm getting excited at how @benotist is shaping up, and would certainly recommend signing up for the beta. It nicely bridges Lanyrd & Speakerdeck.
https://noti.st/
I'm getting excited at how @benotist is shaping up, and would certainly recommend signing up for the beta. It nicely bridges Lanyrd & Speakerdeck.
https://noti.st/
@dav_is_dev @ChrisFerdinandi @vincpa @ianfeather True. Do those things. They help. The difference is that *if* your site depends on JavaScript to be functional, or to convey and render the content, then *if* that fails to load/parse, the user is left at sea.
Progressively enhancing from content in HTML can defend against this.
Progressively enhancing from content in HTML can defend against this.
@jlengstorf @Netlify Ha! Never fear!
I'm a Gatsby duffer... will this page view be pre-rendered too, or only available when rendered vis js? I ask because Netlify will need to spot a valid form in the HTML generated in order to generate a corresponding form API to post to.
https://github.com/imorente/gatsby-netlify-form-example
I'm a Gatsby duffer... will this page view be pre-rendered too, or only available when rendered vis js? I ask because Netlify will need to spot a valid form in the HTML generated in order to generate a corresponding form API to post to.
https://github.com/imorente/gatsby-netlify-form-example
RT @render_conf: 'Serving for the win - Deploys and hosting for the rest of us' – @philhawksworth explores the tools & techniques to make t…
Video of my @render_conf talk is now online. Sadly a few videos in my slides didn't play well with the snazzy projector. Those missing videos are here:
📺 Deploy dashboard: https://youtu.be/kMJHDWzT3eE
📺 Preview builds: https://youtu.be/ETSYoRsjtps
📺 A/B tests: https://youtu.be/Wg67_KXMsS4 https://twitter.com/Netlify/status/984826327818698752
📺 Deploy dashboard: https://youtu.be/kMJHDWzT3eE
📺 Preview builds: https://youtu.be/ETSYoRsjtps
📺 A/B tests: https://youtu.be/Wg67_KXMsS4 https://twitter.com/Netlify/status/984826327818698752
@Marcus_Noble_ The talks were recorded, but I'm not sure what the timeline is for posting them. When it happens, both @render_conf and myself are likely to shout about it.
Who's got two thumbs and really enjoyed speaking at @render_conf?
https://www.flickr.com/photos/whiteoctevents/40317737574/in/album-72157667111416898/
https://www.flickr.com/photos/whiteoctevents/40317737574/in/album-72157667111416898/
Honoured to have been part of #renderconf this year. I leave feeling inspired and motivated.
Thanks to @render_conf and everyone involved. And to all who found me to ask questions. Keep 'em coming!
My slides are online at https://www.hawksworx.com/talks/render
Thanks to @render_conf and everyone involved. And to all who found me to ask questions. Keep 'em coming!
My slides are online at https://www.hawksworx.com/talks/render
@Marcus_Noble_ @render_conf @Una @JSOxford Thanks Marcus. I had a blast! So impressed by the mental stamina of @JSOxford to drive straight into a post conference hack!
@Sohil_is @render_conf @csswizardry @Una @girlie_mac @NadiehBremer @jawache @BenedekGagyi Great seeing you.
@Sohil_is @render_conf Well, if you need anyone to anxiously describe what happens in videos... you know who to call.
:)
:)
"Hi! I'm Ben, and I have a microphone."
– @benjaminbenben
Love those first words at @render_conf as Ben and @sallylait get things started.
– @benjaminbenben
Love those first words at @render_conf as Ben and @sallylait get things started.
@nowakowskipl @Netlify The route works via the link on your home page. Could this be a client-side SPA which does not have all of the routes pre-rendered as valid entry points? Do you get different behavior locally?
@Netlify can help with pre-rendering: https://www.netlify.com/docs/prerendering/
@Netlify can help with pre-rendering: https://www.netlify.com/docs/prerendering/
Launch day should be a time for celebration, not a time for anxiety.
Looking forward to @render_conf where I'll be talking about ways to avoid sleepless nights as you get closer to launching your next big project.
https://2018.render-conf.com/
Looking forward to @render_conf where I'll be talking about ways to avoid sleepless nights as you get closer to launching your next big project.
https://2018.render-conf.com/
Excited to *finally* get to a @render_conf. I've heard nothing but good things! https://twitter.com/render_conf/status/963369925795598338
Excited enough to just get to attend, let alone be a speaker among this lineup. Roll on @render_conf !
https://2018.render-conf.com/
https://2018.render-conf.com/
@whymclovin @Netlify If you mean rendering views on the server at request time, then no. We believe strongly in the power of the #JAMstack and removing that complexity.
Powerful automation and reduced friction for timely *pre-rendering at build time* (not req) time is where our power comes from.
Powerful automation and reduced friction for timely *pre-rendering at build time* (not req) time is where our power comes from.
@AndiSmith @GoHugoIO Solved. (thanks to a helpful hint from @brycekahle)
Now my multi-paragraph summaries are properly formatted. From this:
https://css-styled-summaries--hawksworx.netlify.com/blog/isomorphic-rendering-on-the-jam-stack/
to this:
https://styled-summaries--hawksworx.netlify.com/blog/isomorphic-rendering-on-the-jam-stack/
thanks to this:
Now my multi-paragraph summaries are properly formatted. From this:
https://css-styled-summaries--hawksworx.netlify.com/blog/isomorphic-rendering-on-the-jam-stack/
to this:
https://styled-summaries--hawksworx.netlify.com/blog/isomorphic-rendering-on-the-jam-stack/
thanks to this:
@m5 @brianleroux Some more "application-y" sites lend themselves better to client-side rendering driven by user actions etc as you mention. But the more you can deliver "ready to render" html down the wire, the better the perf and the fewer points of failure to worry about.
@brianleroux No problem. Except often we render on the b/e (or "generate HTML") in response to a request, when we could have done that at build time & de-risked all of our hosting infrastructure.
Not all cases of course, but do blogs really need a DB to reply to get requests? (For example)
Not all cases of course, but do blogs really need a DB to reply to get requests? (For example)
@eduardoboucas Nice! This is the approach I took on one of my projects. A @gulp build running on @Netlify turns @contentful content into HTML and JSON APIs for client renders. Works beautifully.
https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
@jekyllrb & @GoHugoIO both offer output formats which could give this.
https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
@jekyllrb & @GoHugoIO both offer output formats which could give this.
@hjortureh @Netlify @contentful Yep. I do exactly that.
https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
This site uses a bespoke SSG which I made myself, but the principle is exactly as you described. A gulp build gets the data from Contentful. Then an SSG builds it. Triggered by webhooks.
https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
This site uses a bespoke SSG which I made myself, but the principle is exactly as you described. A gulp build gets the data from Contentful. Then an SSG builds it. Triggered by webhooks.
@smashingmag @rachelnabors @slsoftworks @zeithq Yep. An SSG can output all of your site & also the API that drives it. Progressive Enhancement all the way down! https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
#fronttrends - We have a change to the running order. @g33konaut and @misprintedtype have swapped places. Rendering Performance is next.
Some buzzword-mungous waffling from me about this post https://www.hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/ on @heavybit's @JAMstackRadio podcast https://www.heavybit.com/library/podcasts/jamstack-radio/ep-8-isomorphic-rendering-in-the-jamstack/
@guypod @bdougieYO Should have called it "Isomorphic Rendering and other ridiculous buzzwords"
Waving my hands around in front of arrows and boxes. Slides from my #jamstacksf meetup are up. (video coming soon) https://speakerdeck.com/philhawksworth/easy-isomorphic-rendering-on-the-jamstack
@Froggie92 @Netlify Video soon (I think) until then... slides: https://speakerdeck.com/philhawksworth/easy-isomorphic-rendering-on-the-jamstack
Thanks for listening tonight at #JAMStackSF. My slides on Isomorphic Rendering (phew!) are now online: https://speakerdeck.com/philhawksworth/easy-isomorphic-rendering-on-the-jamstack
A static site I put on @netlify feels dynamic because of confident, frictionless deploys. https://www.netlify.com/blog/2016/08/11/release-engineering http://hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
@ultraperk I use a build to get and stash content as an API in server & client. Take a peek If you are interested http://hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/.
Blogged: Notes on making https://comedyinthecrown.com with @contentful, @netlify & "Isomorphic Rendering" on a #JamStack http://hawksworx.com/blog/isomorphic-rendering-on-the-jam-stack/
@SmashingConf Is it me or has @ebrunborg rendered God as one of the ghosts from pacman? Busted! #smashingconf
@auchenberg Yep. That first render if HTML... But we are starting to debate 2 different things. Beer in Amsterdam will help the conversation
RT @jaffathecake: I did a little video on the real-world effects of client rendering vs server rendering vs ServiceWorker rendering https:/…
RT @googledevs: Check out the new episode of HTTP 203, where @aerotwist & @jaffathecake talk about rendering performance on the web: https:…
Seeing Boston Globe on a Newton reminds me of http://unobtrusify.com rendered in W3M text browser https://flickr.com/photos/psd/3169949641/ #smashingconf
@boagworld @addyosmani Are there page rendering speed implications for using Polymer? Rendering blocked? #smashingconf
Making @trello faster by @bobbygrace - Performance breakthroughs from progressive rendering & less UI thrashing. http://blog.fogcreek.com/we-spent-a-week-making-trello-boards-load-extremely-fast-heres-how-we-did-it/
@geekles @jaffathecake Expect that browsers can render your html *while* it is being downloaded. Perceived performance gains abound. PE FTW!
@FronteersConf @angelinamagnum Does appending many templates to a document have any impact on the rendering time of the page?
I use markdown all over the place, so I almost hugged @benoitgrelard when he showed me Quicklook rendering it with https://github.com/toland/qlmarkdown
@joshaustin Not you… I'm just critical of 80MB pages which take 2 mins to render. I feel it impacts users and the web. Would love to talk
Reducing ‘time to content’ with progressive enhancement and tiered rendering. Great Performance Design from AirBnb. http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product
@rcasseus @smashingmag Actually mobile devices & suffer the most from these sites. They have huge bandwidth and rendering engine overheads
Some good notes from @paul_irish from his browser rendering optimisation session with Facebook engineers - https://plus.google.com/113127438179392830442/posts/Kgk78sixgYp
I love the simple but effective use of CSS3 transitions and rendering to create the device illustrations on http://reederapp.com