
@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

@Igloczek @remotesynth @stefanjudis @timbenniks Take http://app.netlify.com. That's a React front-end served statically from a CDN. It's Jamstack. But it makes very heavy use of APIs to drive the content and state of the UI. The services and infra delivering that API are very not Jamstack.
And different teams build each.
And different teams build each.

@Igloczek @remotesynth @stefanjudis @timbenniks Oh I see.
I'd say that an application providing an API is unlikely to be built as Jamstack. (unless read-only, perhaps)
But it might be *consumed* by a Jamstack site and be part of the Jamstack ecosystem.
I'd say that an application providing an API is unlikely to be built as Jamstack. (unless read-only, perhaps)
But it might be *consumed* by a Jamstack site and be part of the Jamstack ecosystem.

Phil Hawksworth
@philhawksworth •

@Igloczek @remotesynth @stefanjudis @timbenniks I don't fully understand your question in this tweet. Can you help me make sure I don't misunderstand and botch my answer? :)

@timbenniks @Igloczek @remotesynth @stefanjudis I don't want to have to maintain an origin server as part of the infra / logic that I need to service a request.
I want to abstract that away.
There will be an origin server.
I never want to need to consider it.
Like serverless. There are servers, but not in my mental model.
I want to abstract that away.
There will be an origin server.
I never want to need to consider it.
Like serverless. There are servers, but not in my mental model.

@Igloczek @remotesynth @stefanjudis @timbenniks Server in the meaning of an active application running on some dedicated, shared, or virtual infrastructure that you have to keep "up and running" to service the incoming requests.

@Igloczek @remotesynth @stefanjudis @timbenniks Feels like massive overlaps to me.
I still consider the absence of a server in my problem space as core to Jamstack though. Which might not always be true of composable.
I still consider the absence of a server in my problem space as core to Jamstack though. Which might not always be true of composable.

@remotesynth @stefanjudis @Igloczek @timbenniks We don't know what future tools and practices will emerge which can fit nicely into this mental model, so an attempt was made to reframe this to accommodate that and avoid of always shifting goalposts.

@remotesynth @stefanjudis @Igloczek @timbenniks The emergence of ISR, DPR, Edge Functions, etc are all beyond pre-generated assets, and yet they fit perfectly into a composable architecture model where no server is part of the infra or mental model of serving sites and apps... things at the heart of a Jamstack mindset.
...
...

@remotesynth @stefanjudis @Igloczek @timbenniks The update to the definition removes explicit mention of pre-generation (although I consider that very desirable to this day) because otherwise it is interpreted as ONLY pre-generated assets.
...
...

@remotesynth @stefanjudis @Igloczek @timbenniks I'd agree with @stefanjudis, in that it was never really a stack. More of an approach. (see "naming is hard")
That fact made it hard to really define in a way that ages well as new technologies and practices arrive.
...
That fact made it hard to really define in a way that ages well as new technologies and practices arrive.
...

@remotesynth @stefanjudis @Igloczek @timbenniks Ah!
Naming is hard.
As is keeping things clear per the history and memory of the web, it seems!
That page should have gone leaving one definition.
Earlier in the year some work was done to try to help keep the term current, while also attempting not to just wildly pivot...
Naming is hard.
As is keeping things clear per the history and memory of the web, it seems!
That page should have gone leaving one definition.
Earlier in the year some work was done to try to help keep the term current, while also attempting not to just wildly pivot...

@jakelear My cooking repertoire is about to sky-rocket.

Phil Hawksworth
@philhawksworth •
Now do every other recipe https://twitter.com/deoncole/status/1574126193607004160

@jlengstorf @cassiecodes This phrase is an absolute bullseye!

@timbenniks Yeah I like that.
It's how I think of a build server.
The fact that modern web hosting can abstract that layer away and do clever caching things behind the scenes without you needing to include any of that in your mental model is reason to celebrate.
Whatever we call it.
It's how I think of a build server.
The fact that modern web hosting can abstract that layer away and do clever caching things behind the scenes without you needing to include any of that in your mental model is reason to celebrate.
Whatever we call it.

@zachleat @bram_stein yyyyes!

@timbenniks Yeah. The key is in how things get to the CDN. What do you have to understand? What is the flow and what infra is involved in serving your site (vs generating it).
I like servers that can go away.
I waxed lyrical on this topic in 2018 in this post
https://www.hawksworx.com/blog/webserverless/
I like servers that can go away.
I waxed lyrical on this topic in 2018 in this post
https://www.hawksworx.com/blog/webserverless/

@timbenniks I’d argue that just having a cache layer falls short of it being Jamstack.
But if you can totally decouple the server that generated the views from the requests that come from the users, then maybe the term holds.
It’s that decoupling which is core to Jamstack
But if you can totally decouple the server that generated the views from the requests that come from the users, then maybe the term holds.
It’s that decoupling which is core to Jamstack

@AlexanderTrefz @johnallsopp @ffconf It wasn’t. I was calling how browsers handle HTML fault tolerant. The Robustness Principle is a cornerstone of the web. HTML and browsers were designed specifically with this in mind and the web could never have become widespread without it.