Take.
My.
Money. https://twitter.com/ezyjules/status/1225469621156896768
@stubbornella @modernserf @LorienMCS @Netlify @loblawdigital @citrix @mattersupply This is also a good reference for JAMstack sites at enterprises and at large scale.
Rebooting MS Docs. Millions of pages and monthly views
The whole talk by @danielfe is great and well worth a watch. The JAMstack specific mentions start ~ 18mins in.
https://twitter.com/danielfe/status/1225261643254288384?s=20
Rebooting MS Docs. Millions of pages and monthly views
The whole talk by @danielfe is great and well worth a watch. The JAMstack specific mentions start ~ 18mins in.
https://twitter.com/danielfe/status/1225261643254288384?s=20
@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.
@stubbornella @torgo @phae Yeah.
My perspective here is that I spent years enthusing about static sites, claiming they had many advantages in certain situations.
Even though the tools & services had evolved, few clients were convinced until I began avoiding the loaded term "static". The word mattered.
My perspective here is that I spent years enthusing about static sites, claiming they had many advantages in certain situations.
Even though the tools & services had evolved, few clients were convinced until I began avoiding the loaded term "static". The word mattered.
@stubbornella @torgo @phae Ha ha. Nice.
I guess it might be seen as a dirty word if placed in exclusive opposition to "substance".
(As with the 99.9% vs 0.1% assertion)
There is more substance to the things described by the word, than to the word itself. But isn't that how such words work?
I dunno!
I guess it might be seen as a dirty word if placed in exclusive opposition to "substance".
(As with the 99.9% vs 0.1% assertion)
There is more substance to the things described by the word, than to the word itself. But isn't that how such words work?
I dunno!
@torgo @stubbornella @phae I'm very much with you to be honest.
I think of both PWA and JAMstack in similar ways - a collection of tools, services, and technologies which are hard to articulate without a convenient catch-all term.
I'd argue they have substance but needed some vocab.
I think of both PWA and JAMstack in similar ways - a collection of tools, services, and technologies which are hard to articulate without a convenient catch-all term.
I'd argue they have substance but needed some vocab.
@torgo @stubbornella It was hard to "sell" the pattern to stakeholders
"It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname that keeps the open web going a bit longer"
— @phae on coining PWA
https://fberriman.com/2017/06/26/naming-progressive-web-apps/
"It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname that keeps the open web going a bit longer"
— @phae on coining PWA
https://fberriman.com/2017/06/26/naming-progressive-web-apps/
@stubbornella Oh I agree that the phrase PWA is marketing.
But would you say that PWAs are 99.9% marketing and 0.1% substance? Or would you say that there are great technologies there which we struggled to communicate with stakeholders until it they got a convenient name?
But would you say that PWAs are 99.9% marketing and 0.1% substance? Or would you say that there are great technologies there which we struggled to communicate with stakeholders until it they got a convenient name?
@stubbornella @modernserf @LorienMCS My case studies are @Netlify-centric, but still about JAMstack.
Like this from @loblawdigital:
https://www.netlify.com/customers/loblaw/?utm_source=twitter&utm_medium=casetstudy-pnh&utm_campaign=devex
this from @citrix:
https://www.netlify.com/blog/2019/06/12/jamstack_conf-nyc-session-recap-citrix-delivers-better-ux-with-less-overhead-using-jamstack-and-netlify?utm_source=twitter&utm_medium=casetstudy-pnh&utm_campaign=devex
and this from @mattersupply for Nike
https://www.netlify.com/customers/matter-supply-nike-site/?utm_source=twitter&utm_medium=casetstudy-pnh&utm_campaign=devex
Like this from @loblawdigital:
https://www.netlify.com/customers/loblaw/?utm_source=twitter&utm_medium=casetstudy-pnh&utm_campaign=devex
this from @citrix:
https://www.netlify.com/blog/2019/06/12/jamstack_conf-nyc-session-recap-citrix-delivers-better-ux-with-less-overhead-using-jamstack-and-netlify?utm_source=twitter&utm_medium=casetstudy-pnh&utm_campaign=devex
and this from @mattersupply for Nike
https://www.netlify.com/customers/matter-supply-nike-site/?utm_source=twitter&utm_medium=casetstudy-pnh&utm_campaign=devex
@modernserf @stubbornella @LorienMCS Yes. Cost and confidence differences for sure. We've seen huge savings (in terms of infrastructure, licensing, time to market, and developer and author productivity) at large companies with substantial projects too.
@stubbornella @LorienMCS Although a staggering percentage of the sites on the web *are* content sites. I find it hard to justify a roundtrip to a DB to get the content for a blog post, for example.
And caching is so hard to do with dynamic infra that it is the source of CS jokes
https://martinfowler.com/bliki/TwoHardThings.html
And caching is so hard to do with dynamic infra that it is the source of CS jokes
https://martinfowler.com/bliki/TwoHardThings.html
@stubbornella I'd offer that it is useful vocabulary rather than all marketing. Since "static" doesn't go nearly far enough to describe all the technologies and services which have arrived and make this model so attractive and viable. (which is the "substance")
Kind of like with term "PWA"
Kind of like with term "PWA"
@adokce @thekitze @zeithq @Netlify Since the context itself is an env var, I often use one build script for all contexts and have conditionals. Like this:
if(process.env.CONTEXT == 'production') {
secret = http://process.env.PROD_KEY;
} else {
secret = http://process.env.DEV_KEY;
}
https://docs.netlify.com/configure-builds/environment-variables/?utm_source=twitter&utm_medium=support-pnh&utm_campaign=devex#build-metadata
if(process.env.CONTEXT == 'production') {
secret = http://process.env.PROD_KEY;
} else {
secret = http://process.env.DEV_KEY;
}
https://docs.netlify.com/configure-builds/environment-variables/?utm_source=twitter&utm_medium=support-pnh&utm_campaign=devex#build-metadata
@thekitze @zeithq @Netlify Contextual builds on @Netlify can help with this. You can run different builds and so pull different env vars according to context:
- production
- branch-deploy
- deploy-preview
Or according to specific branch names.
To the docs! 👉 https://docs.netlify.com/site-deploys/overview/?utm_source=twitter&utm_medium=support-pnh&utm_campaign=devex#deploy-contexts
- production
- branch-deploy
- deploy-preview
Or according to specific branch names.
To the docs! 👉 https://docs.netlify.com/site-deploys/overview/?utm_source=twitter&utm_medium=support-pnh&utm_campaign=devex#deploy-contexts
@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.
@chrisbiscardi @adactio Yeah. I think it depends on how we use the frameworks not just what the frameworks give us.
Deciding on the baseline from which we'll enhance is key, and depends so much on what experience and capabilities we are building.
Deciding on the baseline from which we'll enhance is key, and depends so much on what experience and capabilities we are building.
RT @eduardoboucas: 📢 If you’re using a headless CMS to feed data into a static site, I’d love to know how you do it.
- Plugins made for y…
- Plugins made for y…
@richhiggins @adactio And I prefer not to think of the baseline/fallback as being something akin to "SEO" markup. But as delivering the baseline of capabilities to all users. That was leads to the widest possible support for people, devices, and conditions by default. (+ that valuable SEO juice too)
@richhiggins @adactio I've found that providing a fallback shows the best of intentions, but becomes difficult to execute well, and often falls by the wayside over time. Where as planning an approach which enhances from a sensible baseline (the "it depends" moment for each project) was more successful
This from @adactio captures my own perspective perfectly.
To me, Progressive Enhancement feels as fundamental as spellchecking our content, and I don’t see why we’d discard it.
But misunderstandings about what PE means seem to be on the increase.
https://adactio.com/journal/16404
To me, Progressive Enhancement feels as fundamental as spellchecking our content, and I don’t see why we’d discard it.
But misunderstandings about what PE means seem to be on the increase.
https://adactio.com/journal/16404
📣 London calling (for your jamstack proposals) https://twitter.com/Netlify/status/1225481803424829440