The "JAM" stack is JavaScript, APIs, and Markup. It is relatively new, and JS devs love it because all the back-end and AWS stuff is outsourced to third parties. I've never used it myself, but that's my understanding.
I got my ticket for free at the last minute. These are my notes on the talks I caught. Like a lot of conferences, it's a lot of companies hawking their wares (none of which were super relevant to my employer) but it's good to get a lay of the land.
Videos: https://www.youtube.com/channel/UC8bRyfU7ycLXnEBfvdorpUg
Sean Grove · OneGraph
Only saw the end but it was a demo of making an app that buys a domain, starts a GH repo, builds a site, and plays a song all with one API, I think? Cute and powerful? wowowow
Scott Gallant · Forestry.io
They built a CMS named after the llama from Napoleon Dynamite that can live in a sliding sidebar on top of an existing React site, allowing you to edit the content and preview in realtime. Pretty cool.
Katie Sylor-Miller · Etsy
Overview of git workflow on a new project and a quick walkthrough of how to use Netlify + commit hooks + Github to deploy it.
Netlify apparently has a commit hook that builds a static preview of your site. You can patch to revise and merge to deploy.
Chris Coyier · CSS Tricks
Draws a parallel between the abstraction of complexity that React brought to the front-end landscape and what has been happening to the back-end landscape with GraphQL, Serverless, Netlify, etc.
Postures that these abstractions have loosened our definitions of software roles (ie, Node vs browser JS vs UX, etc) and stacks (LAMP, JAM, STAR, etc), and that that’s a pretty empowering thing for an engineer.
Compelling, well-delivered, mushy feel-good feeling.
Mandy Michael · Seven West Media
- Traditional fonts have italics, bold, maybe different weights, and you toggle each on/off or select the weight.
- Variable fonts have all those, maybe more, and let you pick values arbitrarily -- ie, how much should the text be italics, etc
- Uses regular @font-face and font-family CSS declarations, with some minor tweaks and all the regular caveats
- Values are interpolated can be “tweened” with CSS animation
- Browser support is good. No pre-Edge IE. FF needs a modern OS. W/o support, falls back using regular font stack.
- Performance can be better because it’s fewer requests than multiple weights. File size is comparable.
- CSS treatments and browser allowances like text-shadow, blend-modes, responsive, mobile device orientation, light/audio sensors, etc respond to animations in realtime to very nice effect
- Lots of examples around art, poetry, maybe header text treatments and stuff
- A JS example had lots of magic values and stuff, makes me think it would break in unexpected ways -- would need to be very important to be justifiable in a working codebase
- Why use? Accessibility, performance, interactive, engaging
TLDR: CSS can now do even more fun stuff with text
Shawn Erquhart · Netlify
- Typical components of any monolithic CMS: Editor, persistence layer (DB), view generator, server
- Can move persistence to git or some headless CMS, view generator to SSG (Static Site Generator) like Gatsby, and server to outsourced services
- Since content editors typically don’t like to write in Markdown for SSGs, this is the new gap to bridge (This is a “problem” he set up but didn’t clearly address. Maybe I need to know more about Netlify CMS, but then who is the talk targeted to? IDK.)
- With the content as markdown in github, it is "code" and gets all its benefits: versioning, PRs, etc
- Netlify CMS and forestry.io are the two players in this space
TLDR: big CMS's are bad? I won't argue.
Tammy Everts from SpeedCurve, has a book on JS<->$ effect
- Number of requests and total JS size has multiplied over the last couple years
- Big culprits are likely A/B testing and 3rd party content
- Instead of single, arbitrary “unicorn” metric or any of the dozen+ specific technical metrics to watch, we can instead start with user-centric, qualitative concerns: is it happening, useful, usable, delightful? — and these can help to narrow what to look at
- Google-defined metrics that show up in dev tools waterfall:
- Number of blocking JS requests
- First CPU Idle (formerly know as First Interactive) — long technical definition but basically when page is non-janky enough to use
- Closely related: Time To Interactive, subtly different definition but practically identical
- Blocking CPU time — inversely correlates to bounce rate; after 2sec, half of folks leave
- First input delay (FID) — time from click to response
- A browser's work to render a page is basically 50/50 JS/layout
- Performance budgets
- internal rule books for collection of metrics to stay w/in. There are general recommendations
- Like unit tests or lint rules, tooling can alert about violations and alert
- "How many folks here are using performance budgets?" No hands up. It's hard!
TLDR: performance metrics can be overwhelming but don't need to be, and there are tools to keep us in line.
CTO of RBI (North American fast food conglomerate)
- Popeyes ran out of chicken sandwiches or something and needed to iterate
- Before: 12 codebases (6 for ordering) across 5+ agencies, with content in Excel — harder to use = harder to update = less relevant/used by user
- After: React + Serverless + GraphQL + Sanity.io (headless CMS)
- Shared codebase example: Tim Horton’s, Popeyes, Burger King all use the same site code with different themes
- Nailing the data model to represent ever-changing menus, with all their items and modifications and cost/calories/etc was difficult, but getting it defined helped to determine what the UI for their Sanity CMS for marketers to use
- Making tools self-serve for markets and content editors = “Marketing-driven digital ordering”
TLDR JAM stack was a good fit for them
- Uniform is doing JAMStack for Entreprise, integration w/ Sitecore CMS
- Takeshape is an API for APIs. Demoed making a quick site powered w/ Shopify
Nicole Sullivan - Google
- Chrome team is starting to embrace good relations with JS frameworks, where previously there’d been animosity because they didn't like the huge JS payloads
- Large fraction of Chrome users are in emerging growth markets, BUT avg phone in India is about the same as American Midwest
- Perf stats across popular JS frameworks isn’t too different. 2s TTI, in general
- Frameworks work best when tied with meta-framework to do related heavy-lifting and enforce best practices. Next w/ React is 33% faster than React alone.
- It’s often easier to make new components than style native controls. So they're actively working on making native components look nicer and easier for devs to style and work with.
- Chrome doesn’t have great stats for Single Page Application metrics (like time navigation time between "pages")
- Performance budgets make sense but are hard to implement practically. How can browsers make that work well by default? Again, meta-frameworks to the rescue.
- They have a “Framework Fund” — $ for folks working on dev tools?, specifically around metaframeworks
TLDR Developer relations from Google Chrome acknowledges common dev frustrations and real world effects, and they're 1) actively working on them, 2) soliciting conversations, and 3) outsourcing stuff to other frameworks and independent devs
Ire Aderinokun · BuyCoins
- Wrote a JS component that embeds fresh caniuse info, but it doesn’t work w/o JS or on slow connections or over email! (Well, it falls back to an HTML link, which is fine but not great.)
- Instead, Puppeteer takes a screenshot of caniuse, which is managed and delivered with Cloudinary. The component (which has now turned into a
of different srcs) can then fallback to a real image. - Reminds me of Travis status images on github repos but with the heavy lifting outsourced