If you are still writing Liquid templates the old-school way on product pages, you are injecting developer dependency into every single layout request your client makes.
Shopify Online Store 2.0 shipped in June 2021 and rewired how themes are built — JSON templates, sections everywhere, app blocks, and native metafields. Most developers understand the concept, but burn 11-17 extra hours per project because they don't know the exact architectural decisions that actually save time.
This guide covers those decisions.
What Actually Changed in OS 2.0
Before 2.0, sections only worked on the homepage. Product pages, collection pages, and blogs were locked to Liquid-only templates — no drag-and-drop, no merchant control, pure developer dependency for every layout change.
The Change That Matters Most
JSON templates now replace Liquid templates for every page type except gift_card.liquid and robots.txt.liquid. That single architectural shift is why merchants can add, remove, and reorder sections across the entire store without filing a support ticket to their developer.
When a JSON template loads, it stores section references as data — not markup — and Liquid renders them.
This is how "Sections Everywhere" works without performance regression.
The Theme Folder Structure
You will waste 3 hours hunting bugs if you don't understand where every file type lives.
| Folder | What Lives Here |
|---|---|
/assets |
CSS, JavaScript, fonts, images |
/config |
settings_schema.json and settings_data.json |
/layout |
theme.liquid (the global wrapper) |
/locales |
Translation files for multi-language stores |
/sections |
Reusable content blocks (hero, banner, footer) |
/snippets |
Small reusable fragments (buttons, badges, icons) |
/templates |
JSON or Liquid files per page type |
/blocks |
Global theme blocks (Winter 2024) — work across any section site-wide |
JSON Templates vs. Liquid Templates
A Liquid template like product.liquid is pure markup — you cannot modify it from the theme editor. A JSON template like product.json is a data file that references sections, and each section contains Liquid. The JSON file defines what sections appear by default, in what order, and which ones merchants can add or remove.
The Practical Rule
Use JSON templates for everything. If you inherit a legacy theme where product pages still use product.liquid, migration is straightforward — create a product.json referencing your existing section files.
The Liquid doesn't change; only the wrapper does.
Migration typically takes 4-8 hours per template.
Blocks, App Blocks, and Global Theme Blocks
Blocks are nested components inside sections that let merchants toggle, reorder, and configure content pieces without touching code.
Block Architecture Evolution
Before Winter 2024
A block lived inside one section only. Reusing block logic across sections meant duplicating code and schema definitions. Maintenance nightmare at scale.
After Winter 2024
Reusable global theme blocks live in a /blocks folder and can be dropped into any section across the store — no duplication, no copy-pasting schema code.
App Blocks
To make a section accept app blocks, add {"type": "@app"} to the section's blocks array. When an app is uninstalled, its block code is automatically removed — no orphaned script tags silently slowing your store.
Block Guideline Most Developers Ignore
Don't build blocks that are too granular. We have seen themes with separate blocks for author name, post date, and comment count on a blog card — that's 3 blocks instead of 1.
It triples your schema complexity and confuses merchants in the customizer.
Group related fields into one block or fold them into section settings.
Metafields and Metaobjects: The 2.0 Power Tools
Before OS 2.0, using metafields required apps like Metafields Guru — adding $29-$79/month per client project just to manage custom product data. With OS 2.0, native metafields connect directly to theme blocks via dynamic sources in the theme editor, and update automatically to reflect the product being rendered.
Metaobjects Limitation Worth Knowing
Metaobjects let you define custom structured data types like a "Staff Member" object with photo, name, title, and bio, then loop them into sections. But Shopify only supports connecting single fields from a metaobject into a block, not looping over multiple entries from the customizer dynamically.
You either code the loop in Liquid or wait for Shopify to ship native support.
Shopify CLI: The Only Sane Dev Workflow
Working inside the online code editor is a really bad idea at any project scale above a 3-file tweak. You lose version control, modern tooling, and the ability to collaborate.
The Correct Shopify 2.0 Workflow
Scaffold + Develop
shopify theme init — scaffold a new theme (clones Dawn by default). shopify theme dev — local dev server, syncs live changes to a dev store.
Sync + Deploy
shopify theme pull — pull existing theme files locally. shopify theme push — deploy local code to the store.
Review + Package
shopify theme share — generate shareable preview URL for client review. shopify theme package — zip for Theme Store submission.
Integrate with Git from day one. We have recovered projects destroyed by accidental pushes to live stores more times than we care to count — and the fix was always the same: Git history.
Performance: What Moves the Needle
Dawn is built HTML-first, with JavaScript used only when necessary — that philosophy should guide your custom builds. The Google PageSpeed Insights metrics that carry the heaviest weights are:
Core Web Vitals Weight Distribution
Total Blocking Time (TBT): 30% weight — eliminate render-blocking scripts
Largest Contentful Paint (LCP): 25% weight — lazy-load below-fold images, preload the hero
Cumulative Layout Shift (CLS): 25% weight — set explicit dimensions on all images and embeds
Developer Habits That Silently Kill Performance
► Loading full jQuery for a 12-line interaction script
► Using {% include %} instead of {% render %} — render scopes variables properly; include does not, causing side effects and hard-to-trace bugs
► Installing 6+ apps that each inject global scripts into theme.liquid
Shopify replaced its old Speed Score with a Web Performance Dashboard in Winter 2024 — it surfaces real Core Web Vitals field data, not just synthetic lab scores.
The Business Case for OS 2.0 (What to Tell Clients)
Legacy Shopify 1.0 themes require a developer for every section layout change — typically $150-$500 per edit, with a 3-5 business day turnaround. With a properly built OS 2.0 theme, merchants handle 80% of layout changes themselves directly in the theme editor.
The Number That Closes the Conversation
You are not selling "flexibility." You are selling the elimination of $1,200-$3,000 in annual developer dependency costs for a mid-size Shopify store.
$150-$500 per edit x 8-20 edits/year = $1,200-$10,000/year on layout changes.
A properly built 2.0 theme eliminates 80% of those tickets permanently.
Braincuber Insider Take
Everyone says they build "OS 2.0 themes." But we still see agencies delivering themes where the product page is a product.liquid file with hardcoded sections, the blog template has no block support, and metafields require a third-party app. That's a 1.0 theme in a 2.0 folder structure. Ask your developer to show you the /templates folder. If you see .liquid files instead of .json files — you got charged for an upgrade you didn't receive. (Yes, this happens more than anyone admits.)
Here's Our Challenge
Open your theme's /templates folder right now. If you see product.liquid instead of product.json, you are running a legacy architecture. Every layout change request from your client is a billable ticket that an OS 2.0 migration would have eliminated. Count those tickets from the last 6 months. Multiply by your hourly rate. That's what the old theme is costing you.
Ready to Build a Shopify 2.0 Theme Your Clients Can Actually Manage?
Braincuber builds and customizes Shopify 2.0 themes for merchants who need performance, merchant-friendly editing, and zero tech debt — without charging for features that will never get used. Book a free 15-minute Shopify development consultation.
FAQ: Shopify 2.0 Theme Development
What is the difference between Shopify 1.0 and 2.0 themes?
Shopify 1.0 themes use Liquid templates with sections available on the homepage only. Shopify 2.0 themes use JSON templates, enabling sections on every page type. This lets merchants customize product, collection, and blog layouts directly in the theme editor — without developer involvement for every layout change.
Can I migrate a legacy Shopify theme to OS 2.0?
Yes. The core migration is converting .liquid template files to .json files that reference your existing section files. Your Liquid code does not change — only the template wrapper does. Depending on how many templates a theme has, a full migration typically takes 4 to 8 hours per template.
What is Dawn and should I build on top of it?
Dawn is Shopify's open-source, source-available reference theme built specifically on OS 2.0 architecture. It is HTML-first, performance-focused, and actively maintained on GitHub. We recommend using Dawn as your starting base — it saves 20 to 30 hours per project compared to building a theme from scratch.
What are app blocks and why do they matter?
App blocks let third-party apps inject UI into a specific section without modifying your theme's base code. When the app is uninstalled, its block is automatically removed. This eliminates the legacy problem of ghost script tags leftover from uninstalled apps that silently slow your store and inflate your TBT score.
Do I need new programming languages to develop Shopify 2.0 themes?
No. Shopify 2.0 still uses Liquid, CSS, and JavaScript. The new elements are JSON template files (a straightforward data format) and the Shopify CLI toolchain. If you are familiar with component-based development, the OS 2.0 sections-and-blocks model will feel natural within a few hours of hands-on work.