DEV Community: Krunal Kanojiya

Selection Sort Explained With a Bookshelf Story (With Code)

Krunal Kanojiya — Sat, 25 Jul 2026 16:14:42 +0000

Two years ago I tried to arrange my bookshelf by height, shortest on the left. I had no plan. I just picked up the shortest book I could find in the whole pile and placed it at the start. Then I looked at the remaining pile, found the next shortest, and placed it right after. I repeated this until the pile was gone.

That is selection sort. No fancy math needed to understand it. You already ran the algorithm once, on real books.

How Selection Sort Actually Works

Selection sort splits a list into two sections: a sorted section at the front and an unsorted section behind it. On every pass, it scans the entire unsorted section, finds the smallest value, and swaps it into the first open spot of the sorted section.

Here is the pass-by-pass version with the array [29, 10, 14, 37, 13]:

Pass 1: scan the whole array, find 10, swap it with 29. Array becomes [10, 29, 14, 37, 13].
Pass 2: scan from index 1 onward, find 13, swap it with 29. Array becomes [10, 13, 14, 37, 29].
Pass 3: scan from index 2 onward, 14 is already the smallest, no swap needed.
Pass 4: scan from index 3 onward, find 29, swap it with 37. Array becomes [10, 13, 14, 29, 37].

Five books, four passes, done. For n items, selection sort always runs n-1 passes.

The Code

Here is a plain Python version:

def selection_sort(arr):
    n = len(arr)
    for i in range(n - 1):
        min_index = i
        for j in range(i + 1, n):
            if arr[j] < arr[min_index]:
                min_index = j
        if min_index != i:
            arr[i], arr[min_index] = arr[min_index], arr[i]
    return arr

print(selection_sort([29, 10, 14, 37, 13]))
# [10, 13, 14, 29, 37]

The outer loop picks the position to fill. The inner loop hunts for the smallest remaining value. One swap closes out each pass.

Why It Never Gets Faster, No Matter the Input

This is the part most explanations skip. With bubble sort, an already sorted list finishes fast because the algorithm can detect nothing needs swapping. Selection sort has no such shortcut.

Even if your bookshelf pile was already sorted shortest to tallest, selection sort still scans the full remaining pile on every single pass to confirm it found the smallest one. According to GeeksforGeeks, selection sort's best, average, and worst case time complexity all land at O(n²), and the reason is structural: the algorithm cannot know an item is the minimum without checking every other unsorted item first.

The number of comparisons is fixed at n(n-1)/2 no matter the starting order. A 10,000 item list takes roughly 50 million comparisons regardless of whether it started sorted, reversed, or shuffled.

Where Selection Sort Actually Wins

Selection sort loses on speed, but it wins on writes. It performs at most n-1 swaps total, always, because it only swaps once per pass. Bubble sort and insertion sort can trigger far more swaps on the same data.

This matters in places where writing data costs more than reading it. Flash memory has limited write cycles, and embedded systems often run on tight memory budgets. In those environments, a predictable, low-swap algorithm like selection sort can be a reasonable choice even with its slow comparison count.

Outside of that narrow case, selection sort mainly shows up in classrooms and coding interviews, as a way to build intuition before moving to faster algorithms like merge sort or quicksort.

The Stability Problem

A sorting algorithm is stable if two equal items keep their original relative order after sorting. Selection sort does not guarantee this, because its swap can jump an equal item out of place.

Take [4a, 4b, 3], where 4a and 4b are equal but track their original position. Selection sort finds 3 as the smallest, and swaps it with 4a. The array becomes [3, 4b, 4a]. Notice 4b now comes before 4a, the opposite of their starting order.

If you are sorting a list where order among ties matters, like students with matching scores, skip selection sort and reach for merge sort or insertion sort instead.

Selection Sort vs Its Closest Relatives

Algorithm	Time (all cases)	Space	Swaps	Stable
Selection sort	O(n²)	O(1)	at most n-1	No
Bubble sort	O(n²) worst, O(n) best	O(1)	can be high	Yes
Insertion sort	O(n²) worst, O(n) best	O(1)	moderate	Yes

Insertion sort beats selection sort on nearly sorted data because it adapts to existing order. Selection sort never adapts. That single difference is why interviewers often ask you to explain both back to back.

The One Thing to Remember

Selection sort finds the smallest remaining item and puts it where it belongs, over and over, with no shortcuts. That simplicity is exactly why it is slow on large data and exactly why it is still the first sorting algorithm most people learn. Once you can trace it by hand on five numbers, every other comparison based sort gets easier to follow.

FAQs:

Q: What is selection sort in simple terms?
A: It is a sorting method that repeatedly finds the smallest remaining item and moves it to the front of the list, one item at a time.

Q: What is the time complexity of selection sort?
A: O(n²) in the best, average, and worst case, because it always scans the full unsorted section on every pass.

Q: Is selection sort stable?
A: No. Swapping can push equal elements out of their original relative order.

Q: Is selection sort in-place?
A: Yes. It sorts within the original array and uses only O(1) extra space.

Q: How many swaps does selection sort perform?
A: At most n-1 swaps, which is fewer than bubble sort or insertion sort typically make on the same data.

Q: When should I actually use selection sort?
A: For small datasets, teaching purposes, interview practice, or environments like flash memory where writes are expensive and swaps need to stay low.

What Is Databricks? Uses, Benefits, and How Databricks Works

Krunal Kanojiya — Sat, 25 Jul 2026 15:39:15 +0000

Companies collect data from websites, apps, sales tools, devices, support systems, and payment platforms. This data often sits in separate places. Different teams then spend time moving, cleaning, and checking the same information.

Databricks gives data teams one shared platform for this work. Teams use Databricks to collect data, process large datasets, run SQL analysis, build machine learning models, and create AI applications.

What Is Databricks?

Databricks is a cloud data and AI platform. Data engineers, analysts, data scientists, and AI developers use the platform to work with the same company data.

Databricks runs on Amazon Web Services, Microsoft Azure, and Google Cloud. The platform supports data engineering, analytics, machine learning, data governance, and generative AI work.

Apache Spark sits at the core of many Databricks workloads. Spark processes large datasets across several computers. Databricks adds managed computing, notebooks, SQL tools, pipelines, security controls, and team collaboration around Spark.

Databricks is not a single database. Databricks is a wider platform with connected tools for storing, preparing, managing, and analysing data.

What Problem Does Databricks Solve?

A company often stores customer, product, sales, and marketing data in different systems. One team might work with Shopify orders. Another team might use Google Ads reports. A third team might manage inventory in an ERP system.

Separate systems create extra work. Teams copy data between tools. Reports show different numbers. Security rules become harder to manage. Machine learning projects also slow down because data scientists spend more time preparing data.

Databricks brings these workloads into one shared environment. Each team works from governed data with clear access rules. This setup reduces repeated work and helps teams produce consistent reports, models, and AI applications.

How Does Databricks Work?

A common Databricks workflow follows five steps:

Data arrives from business apps, databases, files, APIs, or streaming systems.
Databricks reads and processes the raw data.
Data engineers clean, join, and organise the records.
The team stores trusted data in managed tables.
Analysts and developers use the data for reports, predictions, and AI tools.

In many setups, the data stays in cloud storage such as Amazon S3, Azure Data Lake Storage, or Google Cloud Storage. Databricks provides the processing, management, governance, and analysis tools around this data.

A simple flow looks like this:

Business systems → Cloud storage → Databricks → Trusted data → Reports and AI

What Is Databricks Used For?

Companies use Databricks for four main types of work.

Data pipelines

Data engineers collect data from several systems, remove errors, combine records, and prepare clean tables for other teams.

Business analytics

Analysts run SQL queries, study trends, and connect Databricks with reporting tools such as Power BI and Tableau.

Real-time processing

Teams process live events from websites, devices, payments, or applications. This supports fraud checks, system monitoring, and live business reporting.

Machine learning and AI

Data scientists train prediction models with company data. AI developers build search tools, assistants, and other applications using approved business information.

A Simple E-commerce Example

An online retailer collects orders from Shopify, campaign data from Google Ads, support records from a help desk, and stock data from an ERP system.

Databricks brings these sources together. Data engineers clean the records and create trusted sales and inventory tables. Analysts then track revenue, product demand, and campaign performance.

Data scientists use the same data to forecast demand or identify customers at risk of leaving. AI developers use approved product and support data to build a customer service assistant.

Each team uses the same governed data. This reduces conflicting reports and repeated data preparation.

Who Uses Databricks?

Different roles use Databricks for different tasks.

Data engineers build pipelines and prepare data.
Data analysts run SQL queries and create reports.
Data scientists train and track models.
AI developers build applications with business data.
Platform administrators control access, security, and governance.

This shared setup helps teams work together without moving data through many separate platforms.

When Should You Use Databricks?

Databricks suits companies with large datasets, many data sources, real-time processing needs, machine learning projects, or AI plans. The platform also fits organisations where several teams need access to the same governed data.

A small company with one database and a few basic reports might not need Databricks. A simpler database or warehouse often handles those needs with less cost and setup work.

Databricks helps companies turn scattered data into trusted information for engineering, analytics, machine learning, and AI. The main value comes from giving different teams one governed place to process data and build useful business outputs.

How to Migrate an Ecommerce Store to Shopify Without Losing Data or SEO

Krunal Kanojiya — Sun, 19 Jul 2026 05:56:29 +0000

Migrating an ecommerce store to Shopify looks simple until you inspect the data.

Products have variants. Customers have multiple addresses. Orders reference products that may no longer exist. Categories need to become collections. Custom fields need a new home. The source and destination platforms rarely agree on how any of this information should be structured.

Then there is SEO. A technically successful migration can still damage the business if thousands of established URLs suddenly return 404 errors.

For developers, a Shopify migration is not a CSV copy operation. It is a repeatable data-engineering project with four important goals:

Preserve the data the business needs.
Translate it into Shopify's data model.
Verify that the destination matches the source.
Switch platforms without disrupting customers or search engines.

This tutorial presents a practical workflow you can adapt for WooCommerce, Magento, BigCommerce, or a custom ecommerce platform.

Design the Migration as a Pipeline

Treat the migration as a pipeline rather than a collection of manual admin tasks:

Source platform
      |
      v
Extraction
      |
      v
Staging and normalization
      |
      v
Shopify data transformation
      |
      v
Test import
      |
      v
Validation and reconciliation
      |
      v
Production import and cutover

This approach makes the migration repeatable. When validation exposes a problem, fix the transformation logic and run the import again. Do not manually repair hundreds of records in Shopify unless the exception genuinely cannot be automated.

A repeatable pipeline also makes the final synchronization safer because you have already tested the exact process that will be used during launch.

1. Audit the Source Store

Before writing an importer, identify everything the existing store contains.

Your inventory should include:

Products, variants, options, prices, inventory, and images
Categories, collections, tags, and product relationships
Customers, addresses, segments, and account status
Orders, discounts, taxes, refunds, fulfilments, and transactions
Pages, blog posts, menus, and media
Meta titles, descriptions, canonical settings, and existing redirects
Reviews, subscriptions, loyalty balances, wishlists, and gift cards
Custom fields and extension-owned data
ERP, PIM, 3PL, payment, shipping, analytics, and marketing integrations

For each item, choose one of four actions:

Action	Meaning
Migrate	Transfer the data directly
Transform	Change its structure before importing
Rebuild	Reimplement the feature for Shopify
Archive	Preserve it outside Shopify for reference

This is especially important when the source store depends on plugins or extensions. A normal product export may not contain subscription contracts, reward balances, custom user fields, or records stored in extension-specific database tables.

If you do not discover those dependencies during the audit, you will probably discover them after launch.

2. Establish a Migration Baseline

Record the state of the source store before changing anything. At minimum, capture:

Total products and active products
Total variants and unique SKUs
Customers and customer addresses
Orders by status
Product images
Categories or collections
Content pages and blog posts
Indexed URLs and existing redirects
Gift card, loyalty, or subscription records

Keep these counts in a reconciliation sheet or database table. They will become the expected values for your test and production imports.

Also preserve the source IDs. An original product, customer, or order ID is extremely useful for tracing records across systems.

3. Build a Field-Mapping Document

Source fields rarely map directly to Shopify fields. Define the mapping before implementing it.

Source field	Shopify destination	Transformation
`product_name`	Product title	Trim and normalize whitespace
`long_description`	Product description	Sanitize and convert to HTML
`manufacturer`	Vendor	Map legacy values
`category_path`	Collection	Flatten or translate hierarchy
`material`	Product metafield	Store as `custom.material`
`legacy_product_id`	Product metafield	Preserve for reconciliation
`meta_title`	SEO title	Enforce length and encoding rules
`slug`	Product handle	Normalize and check uniqueness

Your mapping document should also answer less obvious questions:

What happens to products without SKUs?
How are duplicate SKUs handled?
Do archived products remain archived?
Which system owns inventory after launch?
How will deleted products referenced by historical orders be represented?
Which custom fields should be searchable or filterable?
How will source category trees map to Shopify collections?

Preserve the source ID in a Shopify metafield whenever possible. For example:

{
  "namespace": "migration",
  "key": "source_product_id",
  "type": "single_line_text_field",
  "value": "WC-18492"
}

That identifier lets your code locate an already migrated record during reruns, incremental synchronization, and debugging.

4. Choose CSV or API Imports

There is no single best import method. The correct option depends on store size, data complexity, and how frequently you need to rerun the migration.

Use CSV when

The catalog is relatively small and conventional.
Products use simple options and variants.
You can review the transformed data manually.
You do not need complex record relationships.
The migration is likely to run only a few times.

CSV is useful because it is transparent. A merchant or QA reviewer can open the file and inspect it before import.

Use Shopify APIs when

The catalog is large or structurally complex.
Products require metafields or custom mapping.
You need reliable reruns or incremental synchronization.
The process must record record-level errors.
Several connected data types need to be migrated.

For a custom migration, prefer Shopify's current GraphQL Admin API. Build around the API version supported when you begin the project, because Shopify versions its APIs and retires older versions regularly.

Your importer should include:

Idempotency so reruns do not create duplicates
Rate-limit handling
Retry logic for transient errors
Structured error logging
Checkpoints for long-running jobs
A source-to-destination ID map
A dead-letter queue or exception report for failed records

Do not treat a successful HTTP response as proof that a record migrated correctly. Inspect GraphQL user errors and validate the resulting Shopify object.

5. Normalize the Source Data

Do not send raw exports directly to Shopify. Introduce a staging layer and normalize the data first.

A simplified normalized product might look like this:

{
  "sourceId": "18492",
  "title": "Classic Running Shoe",
  "handle": "classic-running-shoe",
  "vendor": "Example Sports",
  "status": "ACTIVE",
  "options": ["Color", "Size"],
  "variants": [
    {
      "sku": "RUN-BLK-09",
      "price": "89.00",
      "options": {
        "Color": "Black",
        "Size": "9"
      }
    }
  ],
  "metafields": {
    "custom.material": "Mesh",
    "migration.source_product_id": "18492"
  }
}

Normalization should cover:

Duplicate or missing SKUs
Inconsistent option names such as Colour and Color
Invalid prices and inventory quantities
Malformed HTML in descriptions
Unsupported or unreachable image URLs
Duplicate product handles
Encoding issues
Empty variants
Legacy attributes that should become metafields

Make each transformation deterministic: the same source input should produce the same Shopify-ready output.

6. Handle Platform-Specific Differences

Every source platform creates a different set of migration problems.

WooCommerce

WooCommerce data may be split between WordPress tables, post metadata, and plugin-specific tables. Standard exports often miss:

Subscription information
Loyalty balances
Membership data
Custom checkout fields
Product data created by plugins

Customer passwords usually cannot simply be transferred between platforms. Plan a customer account activation or password-reset journey and communicate it before launch.

Magento or Adobe Commerce

Magento's Entity-Attribute-Value model does not map directly to Shopify. You need to decide which attributes become:

Standard product fields
Options and variants
Metafields
Tags
Collections

Magento URL rewrites also need to be exported explicitly. They are valuable SEO assets, not disposable platform configuration.

BigCommerce

BigCommerce stores may use product and variant combinations that require restructuring for Shopify's current product model. Audit products with unusually large option sets before choosing your Shopify representation.

BigCommerce themes use a different templating system from Shopify Liquid. Treat the storefront as a rebuild, not as an automated theme conversion.

7. Import Into a Development Store

Never make production your first complete test.

Begin with a representative sample containing:

A simple product
A product with several variants
A product with multiple images
A product with custom metafields
A customer with multiple addresses
A cancelled or refunded order
A page containing internal links
Records with non-ASCII characters

Validate the sample in Shopify Admin and on the storefront. Look beyond whether the records exist. Confirm that the migrated structure supports search, collections, filtering, inventory, templates, and connected applications.

Once the sample passes, run the complete catalog in a development or staging store.

8. Build the Redirect Map Before Launch

URL redirects are part of the migration, not a post-launch SEO task.

Export all valuable URLs from sources such as:

The source platform database
XML sitemaps
Google Search Console
Analytics landing-page reports
Backlink reports
Existing redirect rules

Map each old path to its closest new destination:

Redirect from,Redirect to
/product/classic-running-shoe,/products/classic-running-shoe
/product-category/running,/collections/running
/blog/shoe-care-guide,/blogs/guides/shoe-care-guide

Validate the redirect map for:

Duplicate source paths
Redirect loops
Multi-hop redirect chains
Missing high-traffic pages
Old internal links in migrated content
URLs containing parameters or encoded characters

Do not redirect every removed URL to the homepage. Send it to the closest relevant replacement. If no useful replacement exists, a legitimate 404 response can be more accurate than an irrelevant redirect.

Preserve existing handles where practical, but do not assume that matching a slug preserves the full URL. Shopify adds platform-specific path segments such as /products/ and /collections/.

9. Reconcile the Destination

Reconciliation proves that the migration is complete.

Start with counts:

Check	Source	Shopify	Expected difference
Products	4,812	4,812	0
Active variants	12,406	12,406	0
Customers	38,901	38,899	2 documented duplicates
Product images	18,220	18,220	0
Redirects	6,140	6,140	0

Then validate actual values for a representative set of records:

Product titles, handles, and status
SKUs, options, prices, and inventory
Image count and ordering
Customer names and addresses
Order totals, taxes, discounts, and refunds
Metafield types and values
Collection membership
SEO titles and descriptions

Counts can match even when the underlying mapping is wrong. Use both aggregate checks and record-level checks.

An exception is acceptable only when it is understood and documented. For example, two duplicate source customers might intentionally become one Shopify customer.

10. Test the Complete Commerce Journey

Data validation is only one part of QA. Test the store as a customer and as an operator.

At minimum, test:

Navigation, search, collections, and filters
Product options and variant selection
Pricing, discounts, taxes, and shipping rates
Cart and checkout
Successful and failed payments
Customer registration, activation, and login
Order confirmation notifications
Inventory deduction
Fulfilment and cancellation
Refunds and returns
Analytics and marketing events
Mobile layout and performance

Place a real order using a real payment method before launch. Test orders and preview modes do not always exercise every production integration.

11. Plan the Final Incremental Sync

A source store usually continues receiving customers and orders while the new store is being built. This means the first bulk export becomes outdated.

Use at least two migration passes:

Bulk migration: Move the historical data while the old store remains active.
Incremental migration: Move records created or changed after the bulk export.

Track a reliable watermark such as an update timestamp or monotonically increasing source ID. Be careful with timestamps if different systems use different time zones.

During cutover:

Pause catalog and content changes where practical.
Record the final synchronization boundary.
Export new and updated records.
Run the incremental import.
Reconcile critical counts.
Import and test redirects.
Point the domain to Shopify.
Confirm SSL and storefront availability.
Place a production order.
Verify payment, inventory, email, and fulfilment events.

Keep the previous platform available in read-only form until stakeholders approve the migrated data.

12. Monitor After Launch

The DNS change is not the end of the migration. Monitor the new store closely during the first days and weeks.

Watch for:

Import and application errors
Checkout or payment failures
Inventory discrepancies
Customer activation problems
Missing images
404 responses and redirect failures
Search Console indexing changes
Organic traffic to important landing pages
Core Web Vitals regressions
Integration failures involving ERP, PIM, 3PL, or marketing tools

Review 404 logs daily at first. A high-value URL without a redirect should be fixed immediately.

Also define who owns each type of post-launch incident. A clear escalation path prevents payment, fulfilment, or SEO problems from sitting unnoticed between teams.

Production Migration Checklist

Before approving launch, confirm that:

[ ] Every data domain has an owner and migration decision.
[ ] Source counts and important URLs have been recorded.
[ ] Field mappings have been reviewed.
[ ] Transformations are deterministic and repeatable.
[ ] Duplicate and invalid records have documented handling rules.
[ ] API retries and rate limits are handled.
[ ] Source and Shopify IDs are mapped.
[ ] Products, customers, orders, and content have been reconciled.
[ ] Redirects have been imported and tested.
[ ] Internal links use the new URL structure.
[ ] Customer account activation has been planned.
[ ] A real end-to-end order has succeeded.
[ ] The incremental sync has been rehearsed.
[ ] A rollback or contingency plan exists.
[ ] Post-launch monitoring and ownership are assigned.

Final Thoughts

The difficult part of a Shopify migration is not moving rows from one database to another. It is preserving meaning across two different commerce models.

A reliable migration is built around three principles:

Make it repeatable. A migration that cannot be rerun safely is difficult to test and risky to launch.
Make it measurable. Counts, ID maps, reconciliation reports, and automated checks turn assumptions into evidence.
Treat SEO and integrations as core data. Redirects, payment flows, fulfilment events, and customer activation are part of the migration—not cleanup tasks.

When the pipeline is repeatable and the results are measurable, launch day becomes a controlled cutover rather than an experiment.

For migration costs, timelines, platform comparisons, and guidance on deciding between a DIY and agency-led project, see the original Shopify migration guide.

Top Shopify Agencies in the US for 2026 (A Developer's Honest Take)

Krunal Kanojiya — Mon, 29 Jun 2026 10:04:16 +0000

I've seen good Shopify stores break because of bad agency choices.

Not bad code. Not bad ideas. The agency just was not the right fit for what the brand actually needed. And when you're a developer or a CTO making that call, the cost of getting it wrong lands squarely on your sprint.

By 2026, the Shopify ecosystem in the US has matured significantly. Building a high-performing Shopify store requires more than templates. It demands technical expertise, conversion-focused design, and strategic execution. There are hundreds of agencies claiming to be the best. Most of them are decent. A handful are genuinely excellent.

This post cuts through the noise.

Why Picking a Shopify Agency Feels Harder Than It Should

Here's the frustrating reality. Most agency websites look nearly identical. Everyone claims "conversion-focused builds," "scalable architecture," and "proven results." The language blurs together fast.

What actually separates agencies in 2026 is where their depth sits. Some are strong in custom Shopify app development. Others live and breathe CRO. Some are enterprise-grade and charge accordingly. A few are perfect for mid-market DTC brands that need speed without bloat.

US agencies have a strong understanding of consumer behavior, payment systems, and compliance requirements, which enables them to build not just functional stores but highly optimized, conversion-focused eCommerce solutions.

The question is not "which agency is best." It's "which agency is best for your specific situation."

What to Look for Before You Even Open a Proposal

Before evaluating any agency, get clear on three things:

Your project size and budget. Mid-market implementations typically range from $25,000 to $100,000 for comprehensive solutions, while enterprise Shopify Plus projects can exceed $100,000 for complex custom implementations.
Your platform maturity. Are you launching fresh, migrating from WooCommerce or Magento, or optimizing an existing Shopify Plus store?
Whether you need ongoing support. Some agencies are best for project-based work. Others shine on monthly retainers where they act as an embedded dev team.

With that in mind, here are the agencies worth your attention in 2026.

Top Shopify Agencies in the US for 2026

1. Lucent Innovation

Location: US-serving (Remote-first) | Best for: Custom Shopify development, Shopify Plus builds, API integrations, and eCommerce transformation

If you are looking for a team that treats your Shopify store as a product rather than a project, Lucent Innovation is worth a serious look.

They specialize in custom Shopify and Shopify Plus development for US-based brands, bringing a strong engineering foundation alongside a real focus on performance and scalability. Where a lot of agencies stop at theme customization, Lucent Innovation goes deeper, handling complex third-party API integrations, custom app development, and full eCommerce architecture builds.

What sets them apart is the combination of technical depth and product thinking. The team is not just building what you spec out. They are helping you think through what should be built and why. For CTOs and product teams that want a development partner who communicates clearly and ships reliably, that is a meaningful difference.

Their work spans industries including fashion, lifestyle, and consumer goods, with a consistent track record of high-performance Shopify storefronts that scale as traffic and catalog complexity grow.

Services: Custom Shopify development, Shopify Plus, third-party integrations, API development, performance optimization, UI/UX design, eCommerce consulting

Worth exploring if: You need a technical partner for a mid-to-large Shopify build where cookie-cutter solutions will not cut it.

2. SmartSites

Location: Paramus, New Jersey | Best for: SEO-driven Shopify builds, PPC, and performance marketing

SmartSites is a certified Shopify Partner based in Paramus, New Jersey, specializing in website design, SEO, PPC advertising, and social media marketing. They have earned over 1,000 five-star reviews, which is not a number most agencies get close to.

When enterprise brands and small businesses need eCommerce platforms that drive results, SmartSites builds Shopify stores with integrated SEO, PPC, and conversion optimization.

SmartSites makes the most sense if your store needs solid technical SEO baked in from day one alongside the build itself. Their entry-level project threshold is low compared to most premier partners, which gives smaller brands access to real Shopify expertise without enterprise-level pricing.

Services: Custom Shopify design and development, SEO, CRO, PPC, theme customization, migration services

3. Lounge Lizard

Location: New York City, NY | Best for: Brand-forward Shopify development and design-led experiences

Lounge Lizard brings a Madison Avenue advertising approach to Shopify development. They are a national digital agency that focuses heavily on brand perception and user experience, creating visually stunning, award-winning storefronts perfect for brands where aesthetics and storytelling drive sales.

They have been around long enough to have built deep experience across every stage of Shopify's evolution. Lounge Lizard is a reputable agency with 28 years of experience known for delivering strategic, design-driven digital solutions that help brands grow and compete effectively.

If your product is one where customers buy with their eyes first, Lounge Lizard understands that better than almost anyone on this list.

Services: Custom Shopify web design, development, digital marketing, brand strategy

4. Coalition Technologies

Location: Los Angeles, CA | Best for: Large-scale enterprise Shopify projects, technical SEO

Coalition Technologies is a US-based Shopify development agency known for handling large-scale and enterprise Shopify projects. The agency combines technical development, SEO, and digital strategy to deliver comprehensive eCommerce solutions.

For brands that need both a strong technical build and organic search performance from the same partner, Coalition sits in a fairly rare position. They have handled complex builds at scale and bring a data-informed approach to both development decisions and growth strategy.

Services: Enterprise Shopify development, SEO, PPC, CRO, Shopify Plus, custom integrations

5. BlueSwitch

Location: New York, NY | Best for: DTC and B2B Shopify Plus, conversion optimization, UX improvement

BlueSwitch specializes in conversion-focused Shopify website design and development. The agency works closely with US brands to optimize UX, improve customer journeys, and increase average order value.

BlueSwitch is a Shopify Plus agency specializing in developing high-performance eCommerce solutions for both direct-to-consumer (DTC) and business-to-business (B2B) brands. That dual B2C/B2B capability is not common. Most agencies pick one lane and stay there. BlueSwitch moving fluidly between both makes them useful for brands that sell across channels.

Services: Shopify Plus development, UX design, CRO, B2B and DTC builds

6. Sleepless Media

Location: Santa Cruz, CA | Best for: Lifestyle, outdoor, and food brands needing custom Shopify Plus builds

Sleepless Media is a US-based Shopify Plus agency with 20+ years of experience building high-converting Shopify stores. Frequently featured in Shopify's own Partner spotlight content, they bring deep eCommerce expertise to every project.

Their portfolio leans into lifestyle and national food brands, which means they understand how to balance visual storytelling with technical performance. They specialize in custom web design and branding, focusing on creating conversion-focused digital experiences for lifestyle, outdoor adventure, and national food brands.

Services: Custom Shopify Plus design and development, migrations, branding, ongoing optimization

7. Digital Silk

Location: New York, NY | Best for: Custom design-forward Shopify builds, enterprise brands wanting search-optimized storefronts

Digital Silk is a Shopify website development agency based in New York. They specialize in custom Shopify web design and development to create scalable eCommerce stores optimized for search engines and conversions.

Their strength is clean, intentional design work paired with technical execution. If your product requires a premium, polished storefront that also performs well in organic search, Digital Silk hits both.

Services: Custom Shopify design, development, SEO, branding

8. 1Digital Agency

Location: Philadelphia, PA | Best for: Mid-to-enterprise eCommerce brands, platform migrations, Shopify Plus

1Digital Agency is a Shopify website design agency based in Philadelphia. They specialize in eCommerce solutions to enhance online visibility and sales for brands across various industries.

They have a well-established practice around Shopify migrations, particularly from platforms like Magento. If you're pulling a brand off an aging platform and need someone who has done that exact thing dozens of times, 1Digital is experienced territory.

Services: Shopify Plus development, migrations, SEO, app integrations, eCommerce consulting

Choosing Between Them: A Framework That Actually Helps

It comes down to three filters.

Filter 1: Development depth vs. marketing integration. Some agencies are pure builders. Others wrap development inside a growth marketing practice. Know which you need before you talk to anyone. SmartSites and Coalition are strong on the marketing side. Lucent Innovation, BlueSwitch, and 1Digital go deeper on the development and integration side.

Filter 2: Enterprise vs. mid-market fit. While the top agencies represent the upper echelon of high-ticket enterprise development, mid-market brands often need highly experienced partners with more accessible entry points. Match the agency tier to your actual scope and budget. Bringing enterprise overhead to a $30K build just creates drag.

Filter 3: Long-term partner vs. one-time project. Successful Shopify partnerships should demonstrate continued value through ongoing optimization, strategic guidance, and adaptation to changing market conditions. If you want a team embedded in your roadmap, make sure the agency runs a retainer model that works for your velocity. Netalico and Lucent Innovation both operate well in this mode.

The Honest Reality of Agency Pricing in 2026

Some agencies charge $50 to $149 per hour depending on complexity. A high-quality agency doesn't stop at launch.

What that means practically: budget not just for the build, but for what comes after. Performance optimization, new feature development, app integrations, and ongoing A/B testing rarely fit inside a launch budget. The agencies that tell you this upfront, clearly and without pressure, are usually the ones worth working with long-term.

Final Take

Shopify in 2026 is not a simple platform anymore. The ecosystem runs deep, from headless commerce and custom checkout extensions to AI-powered personalization and complex B2B workflows. The agency you choose needs to match where your store is going, not just where it is today.

If you are a developer or a CTO evaluating partners for a serious Shopify project, start by scoping your real requirements before you request a single proposal. The agencies on this list are genuinely capable. The difference in outcomes usually comes from how well you match the engagement to the need.

For deeper technical breakdowns on Shopify architecture, eCommerce development patterns, and web infrastructure strategy, I write regularly at krunalkanojiya.com. If this was useful, that is a good next place to go.

How to Use the any Type and When to Avoid It

Krunal Kanojiya — Sun, 28 Jun 2026 10:57:27 +0000

TLDR

any is a special TypeScript type that turns off all type checking for a variable. It lets you assign any value and call any method without errors. This makes it feel helpful but it quietly breaks the safety TypeScript gives you. Avoid any in almost every case. Use unknown when you do not know the type yet. Only use any as a last resort when migrating old JavaScript code or working with untyped third-party libraries.

What is the `any` Type?

any is a type that tells TypeScript to stop checking a variable. Once you mark something as any, TypeScript lets you do anything with it.

You can assign a string. You can assign a number. You can call methods that do not exist. TypeScript will not say a word. It just trusts you to get it right.

let value: any = "hello";
value = 42;         // OK
value = true;       // OK
value = { x: 1 };  // OK
value = null;       // OK
value();            // OK — TypeScript does not check this
value.foo.bar.baz;  // OK — TypeScript does not check this either

All of those lines compile without error. But some of them will crash hard at runtime.

How `any` Disables Type Checking

The core problem with any is simple. TypeScript checks types to catch bugs. any turns that checking off. It is like buying a smoke detector and then removing the battery.

Here is what normally happens with a typed variable:

let name: string = "Alice";
name.toUpperCase(); // OK
name.push("Bob");   // Error: Property 'push' does not exist on type 'string'.

TypeScript catches the mistake. Now compare that with any:

let name: any = "Alice";
name.toUpperCase(); // OK at compile time
name.push("Bob");   // Also OK at compile time — but crashes at runtime

TypeScript sees any and stops checking. The bug gets through to production.

Two Ways `any` Appears in Your Code

Explicit `any`

This is when you write any yourself on purpose:

let data: any = fetchSomeData();
let input: any;
function process(value: any): any { ... }

You chose to use any. TypeScript respects that and skips type checking.

Implicit `any`

This is when TypeScript cannot figure out the type and defaults to any quietly:

// TypeScript cannot infer the type of 'item' here
function logItem(item) {
  console.log(item);
}

Without a type annotation, TypeScript gives item the type any if noImplicitAny is off. This is more dangerous because it is silent.

The noImplicitAny flag (included in strict: true) stops this from happening:

function logItem(item) {
// Error: Parameter 'item' implicitly has an 'any' type.
}

With the error in place, you are forced to add a proper type:

function logItem(item: string): void {
  console.log(item);
}

Why `any` is Dangerous

Problem 1: Errors reach runtime instead of compile time

function getFirstChar(value: any): string {
  return value[0]; // TypeScript is fine with this
}

getFirstChar(123);
// No compile error
// But at runtime: 1 (not a crash here, but wrong behavior)

getFirstChar(null);
// No compile error
// Crashes at runtime: Cannot read properties of null

Problem 2: `any` spreads to other variables

When you assign an any value to another variable, that variable also becomes any. This is called any infection. One any can quietly spread through your whole codebase.

let raw: any = getData();

let name = raw.name;       // name is now any
let age = raw.age;         // age is now any
let city = raw.address.city; // city is now any

// TypeScript checks none of these
age.toUpperCase();          // No error — but crashes at runtime if age is a number

Problem 3: You lose IDE support

TypeScript powers your editor's autocomplete, hover hints, and refactoring tools. When a variable is any, none of that works. You lose the benefits that make TypeScript worth using.

let user: any = getUser();
user. // No autocomplete suggestions here

Compare that with a typed variable:

let user: { name: string; age: number } = getUser();
user. // Editor shows: name, age

Problem 4: Bugs survive code reviews

Type errors show up in CI/CD pipelines and in your editor. They are hard to miss. But runtime crashes from any only show up when users hit that code path. They are much harder to catch.

The `any` Infection Example

Here is a realistic example of how any spreads:

// Step 1: One any at the boundary
const response: any = await fetch("/api/user").then(r => r.json());

// Step 2: Everything from it is also any
const userId = response.id;       // any
const userName = response.name;   // any
const userEmail = response.email; // any

// Step 3: Functions that use these values lose type safety too
function sendWelcomeEmail(email: any): void {
  // email is any, no checks inside this function either
}

// Step 4: The bug is invisible
sendWelcomeEmail(userId); // Wrong value passed — no error

None of these lines produce a TypeScript error. But the last line passes an ID where an email is expected. In production, users get a broken welcome email at best, or a crash at worst.

When is `any` Actually Okay to Use?

There are a small number of situations where any is an acceptable choice. Be honest with yourself about which category you are in before reaching for it.

Situation	Is `any` Okay?	Better Alternative
Migrating a JS file to TS step by step	Yes, temporarily	Add types file by file
Third-party library with no type definitions	Sometimes	Write a `.d.ts` file or use `unknown`
Truly unknown JSON data from an API	Temporarily	Use `unknown` + type guard
You do not want to figure out the type	No	Spend the time finding the right type
Prototype or throwaway script	Acceptable	Not needed for prod code
You are in a hurry	No	Technical debt that bites later

The Right Alternative: `unknown`

unknown is the safe version of any. You can assign anything to an unknown variable just like any. But TypeScript will not let you use the value until you check its type first.

let value: unknown = getData();

// This does not compile with unknown
value.toUpperCase();
// Error: 'value' is of type 'unknown'.

// You must check the type first
if (typeof value === "string") {
  value.toUpperCase(); // Now TypeScript knows it is a string — safe
}

Here is a side-by-side comparison:

	`any`	`unknown`
Can assign any value	Yes	Yes
TypeScript checks usage	No	Yes, after a type check
Autocomplete works	No	Yes, after narrowing
Crashes at runtime	Possible	Much less likely
Recommended	Almost never	When type is truly unknown

Practical example: Handling API responses safely

With any (unsafe):

async function getUser(): Promise<any> {
  const response = await fetch("/api/user");
  return response.json(); // Returns any
}

const user = await getUser();
console.log(user.name.toUpperCase()); // No error, but crashes if name is missing

With unknown (safe):

async function getUser(): Promise<unknown> {
  const response = await fetch("/api/user");
  return response.json();
}

const user = await getUser();

// Must check the shape before using it
if (
  typeof user === "object" &&
  user !== null &&
  "name" in user &&
  typeof (user as { name: unknown }).name === "string"
) {
  console.log((user as { name: string }).name.toUpperCase()); // Safe
}

Tip: For real projects, use a library like Zod to validate API responses instead of writing manual type guards. It is faster and more reliable.

How to Handle `any` When Migrating JavaScript Code

When you are moving a JavaScript project to TypeScript, you will see any everywhere. That is okay as a starting point. The goal is to replace it over time.

Use this step-by-step approach:

// Step 1: Start with any to get the file compiling
function processOrder(order: any): any {
  return order.total * 1.1;
}

// Step 2: Add a type for the input first
type Order = {
  id: number;
  total: number;
};

function processOrder(order: Order): any {
  return order.total * 1.1;
}

// Step 3: Add the return type
function processOrder(order: Order): number {
  return order.total * 1.1;
}

Go one function at a time. Do not try to fix everything at once.

How to Prevent `any` With ESLint

Setting noImplicitAny: true stops TypeScript from adding any silently. But it does not stop you from writing any yourself.

For that, use the @typescript-eslint/no-explicit-any rule:

// .eslintrc.json
{
  "rules": {
    "@typescript-eslint/no-explicit-any": "error"
  }
}

Now this will fail your lint check:

let data: any = fetch(); // ESLint error: Unexpected any. Specify a different type.

This is the best way to keep any out of a team codebase. The linter enforces it for everyone automatically.

`@ts-ignore` and `@ts-expect-error`: Related Escape Hatches

Two comment directives work like any but at the line level. They suppress TypeScript errors on the next line.

// @ts-ignore
const result = doSomethingBroken(); // TypeScript ignores errors on this line

// @ts-expect-error
const result2 = doSomethingBroken(); // Same, but gives an error if there is NO error

The difference between the two:

Directive	What it does
`// @ts-ignore`	Suppresses the error. No feedback if error disappears.
`// @ts-expect-error`	Suppresses the error. Gives a new error if the error is fixed.

Prefer @ts-expect-error over @ts-ignore. It will alert you when the suppression is no longer needed so you can clean it up.

Use both of these as rarely as possible. They hide real problems.

`any` vs `unknown` vs `never`: Quick Comparison

Type	What You Can Assign To It	What You Can Do With It
`any`	Anything	Anything — no checks
`unknown`	Anything	Nothing until you narrow the type
`never`	Nothing	Nothing — it is an impossible type

let a: any = "hello";
a.toUpperCase();  // OK — no checking

let b: unknown = "hello";
b.toUpperCase();  // Error — must narrow first
if (typeof b === "string") {
  b.toUpperCase(); // OK — narrowed to string
}

let c: never;
c = "hello"; // Error — nothing can be assigned to never

Common Mistakes with `any`

Mistake 1: Using any for JSON responses

// Bad
const data: any = await response.json();

// Better
const data: unknown = await response.json();
// Then validate the shape before using it

Mistake 2: Spreading any through utility functions

// Bad: input and return are both any, spreading infection
function transform(input: any): any {
  return input.value;
}

// Good: types are explicit
type InputData = { value: string };
function transform(input: InputData): string {
  return input.value;
}

Mistake 3: Casting to any to silence errors

// Bad: hiding a real type mismatch
const user = getUser() as any;
user.nonExistentMethod(); // Compiles, crashes at runtime

// Good: fix the actual type issue
const user: User = getUser();

Mistake 4: Using any[] for arrays

// Bad
const items: any[] = [1, "two", true];

// Better: use a union type
const items: (number | string | boolean)[] = [1, "two", true];

// Or, if all items are the same type
const scores: number[] = [1, 2, 3];

FAQ

Q: Is any the same as not using TypeScript at all?
Almost, yes. A variable typed as any gets zero type checking. Using any everywhere is the same as writing plain JavaScript with extra steps.

Q: When should I use any vs unknown?
Use unknown when you do not know the type yet but want TypeScript to keep checking how you use the value. Use any only as a last resort during migration or when a library gives you no other choice.

Q: Can I use any in a production codebase?
You can, but you should not. Every any is a place where type safety breaks down and bugs can hide. Use ESLint to ban it and replace it with proper types or unknown.

Q: Does noImplicitAny ban all any?
No. noImplicitAny only stops TypeScript from silently adding any when it cannot infer a type. It does not stop you from writing any yourself. Use the @typescript-eslint/no-explicit-any ESLint rule to ban explicit any too.

Q: What happens to any in the compiled JavaScript?
Nothing. Like all types, any is removed at compile time. It is only a TypeScript concept and has no effect on the JavaScript output.

Q: Is it okay to use any in test files?
It is more acceptable in test files than in production code. But you should still prefer proper types. Typed tests catch more bugs and are easier to maintain.

What You Learned

any turns off all type checking for a variable and lets you assign or do anything with it
TypeScript defaults to implicit any when it cannot infer a type. noImplicitAny: true stops this
any is dangerous because errors skip compile time and reach runtime instead
any spreads to other variables. One any can infect a whole chain of code
unknown is the safe alternative. You must check the type before using an unknown value
Use any only for JS migration or untyped third-party libraries, and replace it as soon as you can
Use @typescript-eslint/no-explicit-any to ban any from your team's codebase
Prefer @ts-expect-error over @ts-ignore when you must suppress a TypeScript error

Sources: TypeScript Handbook — Everyday Types | typescript-eslint — no-explicit-any | TypeScript TSConfig Reference

Pinecone vs Weaviate vs Milvus vs Qdrant: Which Vector DB in 2026?

Krunal Kanojiya — Sun, 28 Jun 2026 05:15:59 +0000

I have helped a number of teams pick a vector database in the last year. The conversation always starts the same way: four logos, one Slack message, one question — which one?

The honest answer is that all four are good. The useful answer is that each one is built for a different set of constraints. Getting this decision wrong does not break your application on day one. It shows up six months later when your bill is three times your compute budget, or your filtered search recall starts degrading under load.

This post gives you the architecture overview, latency benchmarks, filtering quality comparison, hybrid search comparison, real cost numbers, and code examples for each. The full 4,000-word breakdown with detailed cost formulas and every edge case is at krunalkanojiya.com.

The Short Answer First

Skip the full read if you already know your constraints:

Pinecone — Fully managed, zero infrastructure, best for datasets under 10M vectors
Qdrant — Best filtering, native hybrid search, lowest cost at scale, best default for most RAG pipelines in 2026
Weaviate — Built-in vectorization, multi-modal, most mature BM25 + dense hybrid search
Milvus — Only real option above 100M vectors, GPU-accelerated indexing, needs Kubernetes

For everything else, keep reading.

Architecture and Deployment at a Glance

How each database handles deployment defines most of the tradeoffs that follow.

Pinecone is a black box. You get an API key. No infrastructure decisions, no index tuning, no ops. The 2026 default is serverless: pay per read unit, write unit, and storage. No idle charges.

Weaviate uses HNSW indexing with a modular architecture that lets you swap vectorizers, rerankers, and embedding models without rebuilding your schema. In April 2026, v1.37 shipped a native MCP Server, making it the first vector database where LLMs and agents can query and write directly without custom integration code.

Milvus is the most architecturally complex. It separates compute from storage at the infrastructure level with specialized node types (query nodes, data nodes, index nodes) on Kubernetes. Milvus 2.6 replaced its Kafka/Pulsar dependency with Woodpecker, its own WAL system built on object storage.

Qdrant is written in Rust and runs as a single binary or Docker container. No Kubernetes required for most workloads. v1.14 (April 2026) shipped GPU-accelerated HNSW indexing (4x faster index builds on AWS) and Multi-AZ clusters with 99.95% uptime SLAs.

Deployment complexity, simplest to hardest:
Pinecone (no ops) → Qdrant (single binary) → Weaviate (Docker Compose) → Milvus (Kubernetes)

Performance Benchmarks

Benchmarks from Salt Technologies AI's Vector Database Performance Benchmark 2026, covering 1M vectors at 1536 dimensions:

Database	p50 Latency	p99 Latency	Notes
Qdrant (self-hosted)	4ms	8–12ms	Lowest latency of all purpose-built vector DBs
Milvus (with GPU)	6ms	12–18ms	CPU-only is 15–25ms
Pinecone Serverless	20–30ms	40–80ms (cold)	Warm queries 10–15ms
Weaviate Cloud	50–70ms	100–150ms	Self-hosted is significantly faster

A few things worth knowing about these numbers. Qdrant's 4ms p50 is consistent across warm and cold queries because it runs on infrastructure you control. Pinecone's cold query spike matters for applications with bursty or overnight-quiet traffic. Weaviate self-hosted with binary quantization reaches 20–40ms p99, much better than the managed numbers.

Filtering: The Most Underrated Difference

Filtering is the most important practical difference for production applications. Almost every real RAG query includes filters — user ID, date range, category, tenant ID.

The core problem: post-filtering retrieves candidates from the index first, then applies the filter. If only 1% of your vectors match the filter, the traversal wastes 99% of its work. Recall drops significantly under selective filters.

Qdrant applies the payload filter during HNSW graph traversal, not after. Recall stays high even when filters reduce the dataset to a tiny fraction of the total.

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue, Range

client = QdrantClient(url="http://localhost:6333")

results = client.query_points(
    collection_name="documents",
    query=query_vector,
    query_filter=Filter(
        must=[
            FieldCondition(key="user_id", match=MatchValue(value=42)),
            FieldCondition(key="category", match=MatchValue(value="technical")),
            FieldCondition(
                key="created_at",
                range=Range(gte=1700000000)
            ),
        ]
    ),
    limit=10,
)

Weaviate also applies filters during index traversal using an inverted index alongside the HNSW graph. Recall under selective filters is strong and comparable to Qdrant.

Milvus uses a scalar index built alongside the vector index. Handles complex filters well at billion-scale under high QPS through distributed query execution.

Pinecone handles metadata filtering well for common equality and range filters. Under highly selective filters on large datasets, recall can degrade. The filter syntax is also less expressive than the other three.

Filtering winner: Qdrant and Weaviate for correctness under selective filters. Milvus for filtering at billion-scale.

Hybrid Search

Hybrid search combines dense vectors with sparse BM25 to handle both semantic queries and exact keyword matches. It consistently outperforms pure semantic search for technical docs, product catalogs, and anything with specific identifiers like model numbers or proper nouns.

Weaviate has the most mature implementation. BM25 + dense vector search is processed in a single unified query, not two separate calls you merge in application code.

import weaviate
from weaviate.classes.query import HybridFusion

client = weaviate.connect_to_weaviate_cloud(
    cluster_url="YOUR_CLUSTER_URL",
    auth_credentials=weaviate.auth.AuthApiKey("YOUR_API_KEY"),
)

collection = client.collections.get("Documents")

results = collection.query.hybrid(
    query="vector database filtering performance",
    vector=query_embedding,
    fusion_type=HybridFusion.RELATIVE_SCORE,
    limit=10,
)

client.close()

Qdrant supports native sparse vectors alongside dense vectors in named vector collections. Query them together with Reciprocal Rank Fusion.

from qdrant_client import QdrantClient
from qdrant_client.models import SparseVector, Prefetch, FusionQuery, Fusion

client = QdrantClient(url="http://localhost:6333")

results = client.query_points(
    collection_name="documents",
    prefetch=[
        Prefetch(query=dense_vector, using="dense", limit=20),
        Prefetch(
            query=SparseVector(indices=sparse_indices, values=sparse_values),
            using="sparse",
            limit=20,
        ),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=10,
)

Milvus 2.6 ships BM25 full-text search built-in, benchmarked at 400% higher throughput than Elasticsearch on equivalent hardware. Teams can collapse a two-system stack (Elasticsearch + vector DB) into a single Milvus deployment.

Pinecone supports hybrid search through sparse-dense vectors. Clean implementation, less flexible than Qdrant's named vector design when combining more than two vector types.

Hybrid search winner: Weaviate for the most integrated implementation. Qdrant for flexibility. Milvus for teams replacing Elasticsearch.

Real Cost Numbers at 10M Vectors

This is where teams get surprised the most. The number on the pricing page is rarely the number you pay in production.

Database	10M vectors managed	10M vectors self-hosted	Best scenario
Pinecone Serverless	$70–$100/month	Not available	Low query volume, small scale
Weaviate Cloud	~$135/month (BQ enabled)	$80–$120/month	Hybrid search with no extra cost
Milvus (Zilliz)	$65–$120/month	$60–$100/month	Billion-scale with quantization
Qdrant Cloud	~$65/month	$20–$40/month	Best self-hosted economics

A few notes worth calling out.

Pinecone bills on read units, write units, and storage. At high query volume, read unit costs stack up fast. Weaviate's dimension-based billing multiplies by replication factor — enabling Binary Quantization is essential at any scale above 1M vectors or costs blow up. Milvus 2.6's RaBitQ 1-bit quantization compresses indexes to 1/32 their original size at 95% recall, which materially changes the hardware required at billion-scale. Self-hosted Qdrant on a $40/month VPS with binary quantization handles 10M vectors comfortably with sub-10ms p99.

Cost winner: Self-hosted Qdrant for lowest total cost at any scale. Pinecone Serverless for small workloads where zero-ops is worth the premium.

Quick Start Code for Each

Pinecone — fastest to get started, three lines to insert:

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="your-api-key")
pc.create_index(
    name="my-index",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1")
)
index = pc.Index("my-index")
index.upsert(vectors=[{"id": "doc-1", "values": embedding, "metadata": {"text": "..."}}])
results = index.query(vector=query_embedding, top_k=10, include_metadata=True)

Qdrant — clean defaults, sane out-of-the-box behavior:

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
client.upsert(
    collection_name="documents",
    points=[PointStruct(id=1, vector=embedding, payload={"content": "...", "user_id": 42})]
)
results = client.query_points(collection_name="documents", query=query_embedding, limit=10)

The Decision Matrix

Requirement	Pick
Zero infrastructure, fastest setup	Pinecone
Best filtering recall under selective filters	Qdrant
Native hybrid search out of the box	Weaviate
Built-in vectorization (no separate embedding call)	Weaviate
Dataset above 100M vectors	Milvus
GPU-accelerated index builds	Milvus or Qdrant Cloud
Lowest self-hosted cost	Qdrant
Replace Elasticsearch with vector search	Milvus
LLM agent integration via MCP	Weaviate
Most teams building RAG in 2026	Qdrant

Where to Go Deeper

This post covers the key differences. The full comparison at my blog goes deeper on Pinecone's Dedicated Read Nodes and BYOC setup, Weaviate's Diversity Search using MMR, Milvus's tiered hot/cold storage, Qdrant's audit logging, the full cost formulas for each pricing model, and the Lambda vs Kappa architecture question for teams running both batch and streaming ingestion alongside vector search.

Read the full guide here:
Pinecone vs Weaviate vs Milvus vs Qdrant (2026): Full Comparison

Which vector database are you currently using in production? And what made you pick it? Drop it in the comments.

Batch vs Real-Time Streaming: When to Use Each (with Examples)

Krunal Kanojiya — Fri, 26 Jun 2026 12:01:16 +0000

Every data pipeline makes one foundational decision before a single line of code is written.

Does it process data in scheduled chunks, or does it process data as events arrive?

That is the batch versus streaming decision. It looks simple on paper. In practice, it shapes everything: the tools you use, the infrastructure you maintain, the guarantees you can make about data freshness, and the cost you pay every month to keep it running.

Teams that build streaming pipelines when batch would have sufficed end up maintaining complex infrastructure for a problem that did not require it. Teams that build batch when their use case demands real-time discover the gap at the worst possible moment.

This post gives you a decision framework, a side-by-side comparison, and working code examples for both patterns. The full deep-dive with architecture diagrams, Lambda vs Kappa tradeoffs, and Databricks Real-Time Mode is at the original article on Lucent Innovation.

How Batch Works (and Where It Breaks Down)

Batch collects data over a window of time, then processes it all at once when a scheduled trigger fires.

Think of it like doing laundry. You do not wash one shirt the moment it gets dirty. You wait for a full load, then run the machine. Data accumulates throughout the day. At a scheduled time, the job picks up everything, transforms it, and loads the output.

Where batch wins:

Complex multi-table joins and heavy aggregations with no time pressure per record
ML model training on large, static datasets
Nightly financial reconciliation and compliance reporting
Historical data migrations and backfills

Where batch breaks down:

Use cases where decisions depend on data that is happening right now
A fraud detection system running on nightly batch is not a fraud system. It is a fraud reporting system.

Batch Pipeline Example (PySpark)

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, sum, date_trunc

spark = SparkSession.builder.appName("NightlyRevenueRollup").getOrCreate()

# Read from Delta Lake Bronze table
raw_orders = spark.read.format("delta").load("/mnt/bronze/orders")

# Transform: aggregate daily revenue per product
daily_revenue = (
    raw_orders
    .filter(col("status") == "completed")
    .withColumn("order_date", date_trunc("day", col("created_at")))
    .groupBy("order_date", "product_id")
    .agg(sum("amount").alias("total_revenue"))
)

# Write to Delta Lake Gold table
(
    daily_revenue.write
    .format("delta")
    .mode("overwrite")
    .option("replaceWhere", "order_date = current_date()")
    .save("/mnt/gold/daily_revenue")
)

This job runs on a schedule (nightly, hourly, whatever the SLA allows). It reads a full time window, transforms it, and overwrites the output partition. Simple failure mode: if it breaks, you fix the logic and rerun the window.

How Streaming Works (and Where It Costs You)

Streaming treats data as a continuous flow of individual events. Each event is processed the moment it arrives, without waiting for others to accumulate.

Think of it like a moving walkway at an airport. Nobody waits for 500 people to gather before the walkway starts. It runs continuously. Each person moves forward the moment they step on.

A streaming pipeline runs 24 hours a day, 7 days a week, processing each event within milliseconds to seconds of arrival.

Where streaming wins:

Fraud detection before a transaction clears
Real-time personalization based on current browsing behavior
Operational dashboards that need second-level granularity
IoT and sensor telemetry for predictive maintenance

Where streaming costs you:

Always-on compute, persistent state storage, and continuous monitoring
State management across windowed aggregations grows with data volume
Schema changes from source systems can corrupt output silently while the pipeline keeps running
A simple batch ELT pipeline costs $15,000–$50,000 to build. A production streaming pipeline with proper monitoring: $50,000–$200,000+

Streaming Pipeline Example (Spark Structured Streaming)

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, window, sum
from pyspark.sql.types import StructType, StringType, DoubleType, TimestampType

spark = SparkSession.builder.appName("FraudSignalStream").getOrCreate()

# Define schema for incoming payment events
payment_schema = (
    StructType()
    .add("transaction_id", StringType())
    .add("user_id", StringType())
    .add("amount", DoubleType())
    .add("merchant_id", StringType())
    .add("event_time", TimestampType())
)

# Read from Kafka topic
raw_stream = (
    spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "kafka-broker:9092")
    .option("subscribe", "payment_events")
    .option("startingOffsets", "latest")
    .load()
    .select(from_json(col("value").cast("string"), payment_schema).alias("data"))
    .select("data.*")
)

# Compute 5-minute rolling spend per user for anomaly detection
windowed_spend = (
    raw_stream
    .withWatermark("event_time", "10 minutes")
    .groupBy(
        col("user_id"),
        window(col("event_time"), "5 minutes")
    )
    .agg(sum("amount").alias("total_spend_5min"))
)

# Write results to Delta Lake for downstream fraud scoring
(
    windowed_spend.writeStream
    .format("delta")
    .outputMode("append")
    .option("checkpointLocation", "/mnt/checkpoints/fraud_signal")
    .start("/mnt/silver/fraud_signals")
)

This pipeline runs continuously. The checkpointLocation ensures exactly-once processing if the job restarts. The watermark handles late-arriving events. The windowed aggregation maintains rolling state in memory.

The Decision Framework: One Question Answers It

What happens if the data is one hour old?

If the answer is nothing meaningful, batch is the right choice.

If the answer is a real business loss, streaming earns its complexity.

Four follow-up questions to confirm:

Question	If Yes	If No
Does stale data cause a direct business loss?	Streaming	Batch
Does the output trigger a real-time action?	Streaming	Batch
Does your team have streaming ops experience?	Streaming feasible	Stick to batch
Would hourly refreshes satisfy the requirement?	Micro-batch	Streaming

Micro-Batch: The Middle Ground Most Teams Overlook

Between batch and streaming sits micro-batch. It is the pattern Spark Structured Streaming uses by default and the one that solves most "near real-time" requirements without full streaming complexity.

Micro-batch runs the same pipeline logic as streaming but on a short fixed interval: every 30 seconds, every minute, every 5 minutes.

Most stakeholders who say they want "real-time" data would be fully satisfied with a dashboard that refreshes every minute. That is micro-batch, not streaming, and it costs a fraction of the infrastructure.

Latency requirement   →   Pattern
─────────────────────────────────────────────
Hours                 →   Batch (scheduled)
Minutes               →   Micro-batch (short trigger)
Sub-minute + action   →   Streaming (Structured Streaming)
Sub-second + action   →   Real-Time Mode (Databricks RTM)

Micro-Batch in Practice

# Micro-batch: trigger every 60 seconds instead of continuously
(
    windowed_spend.writeStream
    .format("delta")
    .outputMode("append")
    .trigger(processingTime="60 seconds")   # <-- this is the only change
    .option("checkpointLocation", "/mnt/checkpoints/fraud_signal")
    .start("/mnt/silver/fraud_signals")
)

One line change. 60-second freshness. Dramatically simpler operational model.

Both Patterns in One Place: Databricks Lakeflow

On Databricks, batch and streaming live in the same pipeline definition using Lakeflow Spark Declarative Pipelines. No separate tools. No second codebase.

import dlt
from pyspark.sql.functions import col, sum, window

# STREAMING TABLE: processes each event as it arrives
@dlt.table(
    name="silver_payment_events",
    comment="Cleaned payment events, streamed from Kafka"
)
def silver_payment_events():
    return (
        spark.readStream
        .format("kafka")
        .option("kafka.bootstrap.servers", "kafka-broker:9092")
        .option("subscribe", "payment_events")
        .load()
    )

# MATERIALIZED VIEW: runs as batch, re-computes on a schedule
@dlt.table(
    name="gold_daily_revenue",
    comment="Daily revenue rollup, refreshed hourly"
)
def gold_daily_revenue():
    return (
        dlt.read("silver_payment_events")
        .groupBy("merchant_id", "order_date")
        .agg(sum("amount").alias("total_revenue"))
    )

The streaming table (silver_payment_events) processes events continuously. The materialized view (gold_daily_revenue) refreshes on a trigger or schedule. Both are governed by Unity Catalog. Both write to Delta Lake. One pipeline definition, two patterns, zero context switching.

Real-World Pattern Map

Use Case	Pattern	Why
Nightly revenue reporting	Batch	Hourly freshness acceptable
ML model training	Batch	Full static dataset required
Historical data migration	Batch	No real-time constraint
Fraud detection	Streaming	Decision before transaction clears
Live inventory dashboard	Streaming	Stockout response requires current state
IoT anomaly detection	Streaming	Equipment failure cannot wait
Stakeholder dashboard "refreshed often"	Micro-batch	Minutes of freshness, batch cost
Compliance reporting	Batch	Fixed time window, no urgency

The Full Picture

This post covers the decision framework and working code examples for both patterns. The full article at Lucent Innovation goes deeper on:

Lambda Architecture vs Kappa Architecture for systems that need both patterns simultaneously
Databricks Real-Time Mode (GA March 2026) and how it achieves single-digit millisecond P99 latency without switching to Flink
The three hidden streaming costs teams consistently underestimate: state management, exactly-once delivery, and silent schema drift
How ELT handles streaming more naturally than ETL due to the pre-transformation bottleneck

Read the full guide here:
Batch vs Streaming Pipelines: How to Choose in 2026

Which pattern are you currently running in production? Drop it in the comments.

Your Data Engineering Learning Path: 2026 Edition

Krunal Kanojiya — Thu, 25 Jun 2026 10:10:31 +0000

Data engineering in 2026 is not what it was three years ago.

The job has expanded. Modern data engineers design lakehouse architectures, run streaming and batch pipelines on the same platform, enforce data quality at ingestion time, and track cloud costs per pipeline run. The tooling has converged around a smaller number of platforms that do much more.

If you are learning data engineering now, or leveling up from an older stack, the volume of things to learn can feel paralyzing. This checklist breaks it into a clear sequence so you know exactly what to learn, in what order, and why each piece matters.

The full deep-dive guide behind this checklist lives at Modern Data Engineering: The Complete Guide. This post gives you the skeleton. The full guide gives you the muscle.

Stage 1: Get the Fundamentals Right

Before picking tools, understand the concepts. These are the building blocks every data engineer needs regardless of platform.

What to learn:

[ ] What a data pipeline actually is — how data moves from source to destination, what stages it passes through, and what makes a pipeline fragile vs reliable. Understand push vs pull patterns and what fan-in/fan-out means in practice.
[ ] ETL vs ELT — extract, transform, load vs extract, load, transform. The difference is where transformation happens. In cloud-native platforms like Databricks, ELT is the default because the destination has enough compute to transform at scale. Know when each pattern applies.
[ ] Batch vs streaming — batch processes large chunks of data on a schedule; streaming processes records as they arrive. Most production systems use both. Understand the latency, cost, and complexity tradeoffs before choosing.

The real-time analytics market is projected to grow from $14.5 billion in 2023 to over $35 billion by 2032. Streaming is no longer optional knowledge.

You are ready for Stage 2 when: You can explain what a pipeline is, why ETL is being replaced by ELT in cloud environments, and when you would use batch vs streaming.

Stage 2: Understand Modern Data Storage

Where you put data matters as much as how you move it. The storage landscape has shifted significantly.

What to learn:

[ ] Data warehouse vs data lake vs lakehouse — warehouses are fast and reliable but expensive and rigid. Data lakes are cheap and flexible but turn into unmanaged swamps without governance. The lakehouse model combines both. Know the tradeoffs and why the lakehouse has become the default architecture for new builds.
[ ] Lakehouse architecture — a lakehouse stores all data (structured and unstructured) in open-format cloud storage, then adds a reliability layer that provides ACID transactions, schema enforcement, and fast queries. One platform for data engineering, analytics, and AI.
[ ] Delta Lake — the open-source storage layer that makes the lakehouse work. Adds ACID transactions, time travel, schema enforcement, and Change Data Feed to files in S3, ADLS, or GCS. If you are working with Databricks, this is non-negotiable.

The four things Delta Lake gives you that plain files do not:

Capability	Why It Matters
ACID transactions	Writes fully complete or fully roll back. No partial corruption.
Schema enforcement	Bad data is rejected at write time, before it lands.
Time travel	Query any previous table version for debugging, audits, or rollbacks.
Change Data Feed	Track row-level inserts, updates, deletes without full table scans.

You are ready for Stage 3 when: You can explain why a plain S3 data lake is unreliable for production use, and what Delta Lake adds to fix it.

Stage 3: Learn the Databricks Platform

Databricks is the dominant platform for building modern data pipelines and lakehouses. Founded by the creators of Apache Spark, Delta Lake, and MLflow, it has become the standard for teams running large-scale data work.

What to learn:

[ ] What Databricks is and how it is structured — a unified workspace for SQL, Python, notebooks, and pipelines. Serverless compute that scales automatically. Native support for both batch and streaming.
[ ] The Databricks tool stack for 2026:

Layer	Tool	What It Does
Ingestion	Lakeflow Connect	Pull data from sources into Bronze layer
Storage	Delta Lake	Store data reliably with ACID guarantees
Transformation	Lakeflow Declarative Pipelines	Clean and model data through Bronze, Silver, Gold
Orchestration	Lakeflow Jobs	Schedule and coordinate pipeline runs
Governance	Unity Catalog	Access control, lineage tracking, auditing
Analytics	Databricks SQL	SQL queries and dashboards on governed data

[ ] Unity Catalog — in 2026, Unity Catalog is not optional on Databricks. It is the foundation for access control, data lineage, auditing, and discovery. If you skip it, you are building without governance.

You are ready for Stage 4 when: You can navigate a Databricks workspace, understand how Lakeflow and Unity Catalog connect, and explain what happens to data as it moves from ingestion to analytics.

Stage 4: Build Production-Grade Pipelines

Knowing the tools is not the same as using them reliably in production. This stage is where you go from "I can write a Spark job" to "I build pipelines that do not break."

What to learn:

[ ] Medallion Architecture (Bronze, Silver, Gold) — the standard pattern for organizing data inside a lakehouse. Bronze is raw data as-arrived. Silver is cleaned and validated. Gold is aggregated and business-ready. Schema enforcement lives at the Bronze-to-Silver boundary.
[ ] Incremental loads and CDC — most pipelines should not reprocess all data on every run. Learn how to build pipelines that process only what changed since the last run. Change Data Capture (CDC) tracks row-level changes so downstream tables update incrementally instead of via full scans.
[ ] Data quality and observability — Gartner forecasts that 50% of organizations with distributed data architectures will adopt observability platforms in 2026, up from under 20% in 2024. Quality checks and pipeline monitoring are now baseline requirements, not advanced features.
[ ] OPTIMIZE, VACUUM, and Liquid Clustering — Delta tables accumulate small files over time. OPTIMIZE compacts them. VACUUM removes stale files after your retention window. Liquid Clustering replaces manual partitioning for new tables. Know how and when to run each.

You are ready for Stage 5 when: You can build a pipeline that runs incrementally, enforces schema at each layer, handles errors without corrupting data, and stays performant over time.

Stage 5: Understand Where the Industry Is Heading

Data engineering in 2026 has new pressures that did not exist two years ago. These are not optional topics — they are becoming normal parts of the role.

What to follow:

[ ] AI-augmented data operations — AI tools are now involved in pipeline monitoring, anomaly detection, debugging, and performance tuning, not just during development. The global autonomous data platform market is projected to grow from $2.51 billion in 2025 to $15.23 billion by 2033.
[ ] FinOps for data — data engineering workloads are expensive. Tracking cost per pipeline run, right-sizing compute, and justifying cloud spend are now expected skills. If you are building on Databricks, learn auto-scaling and SQL warehouse sizing from the start.
[ ] Unified batch and streaming — the debate between batch and streaming architectures is largely over. Winning platforms run both seamlessly, with shared governance, schema evolution, and auditability. The question is how to run both reliably on the same platform.
[ ] Platform engineering model — teams that treat data infrastructure as a product (standardized ingestion templates, reusable transformation patterns, centralized deployment) see 20% to 25% lower operational overhead compared to teams that build bespoke pipelines per project.

The Full Checklist at a Glance

STAGE 1: Fundamentals
  [ ] Data pipeline anatomy
  [ ] ETL vs ELT
  [ ] Batch vs streaming

STAGE 2: Storage
  [ ] Warehouse vs lake vs lakehouse
  [ ] Lakehouse architecture
  [ ] Delta Lake (ACID, time travel, CDF)

STAGE 3: Databricks Platform
  [ ] Databricks overview and workspace
  [ ] Lakeflow (Connect, Pipelines, Jobs)
  [ ] Unity Catalog

STAGE 4: Production Skills
  [ ] Medallion Architecture
  [ ] Incremental loads and CDC
  [ ] Data quality and observability
  [ ] OPTIMIZE, VACUUM, Liquid Clustering

STAGE 5: Industry Direction
  [ ] AI-augmented operations
  [ ] FinOps for data
  [ ] Unified batch + streaming
  [ ] Platform engineering model

Where to Go Deep

This checklist is the map. The full guide at Lucent Innovation covers every stage in detail, with technical explanations, real examples, tool comparisons, and links to deeper articles for each topic area.

Read the full Modern Data Engineering Guide here:
https://www.lucentinnovation.com/resources/it-insights/modern-data-engineering-guide

The guide is organized as a complete content series. You can start with the foundational concepts and follow the links through to the implementation and best practices articles, or jump directly to the section most relevant to where you are right now.

What stage are you currently at? Drop it in the comments.

How to Use Type Annotations to Explicitly Type Variables in TypeScript

Krunal Kanojiya — Fri, 12 Jun 2026 02:21:11 +0000

TLDR

A type annotation tells TypeScript exactly what type a variable, function parameter, or return value should be. You write it using a colon after the name, like let age: number = 30. Annotations are removed when TypeScript compiles to JavaScript. They only exist to help you catch bugs during development.

What is a Type Annotation?

A type annotation is a label you attach to a variable or function. It tells TypeScript what kind of value is allowed there.

TypeScript can guess types in many situations on its own. But sometimes it cannot. And sometimes you want to be extra clear about what a variable should hold. That is when you write an annotation yourself.

The syntax is simple. You put a colon after the name, then write the type:

let age: number;
let name: string;
let isActive: boolean;

The Basic Syntax

The pattern for a type annotation is always the same:

name: type

You can add it to variables, constants, function parameters, and return values. Here is the syntax for each:

Where	Syntax	Example
Variable	`let name: type`	`let score: number`
Constant	`const name: type = value`	`const title: string = "Admin"`
Function parameter	`(param: type)`	`(age: number)`
Function return value	`(): type`	`(): string`
Array	`name: type[]`	`let tags: string[]`
Object	`name: { key: type }`	`let user: { name: string }`

How to Annotate Variables

The most common place to use annotations is on variables declared with let.

let username: string;
let score: number;
let isLoggedIn: boolean;

Here, the variables are declared but not given a value yet. TypeScript knows their types from the annotation alone.

Later, when you assign a value, TypeScript checks that it matches:

username = "Alice";    // OK
username = 42;         // Error: Type 'number' is not assignable to type 'string'.

score = 100;           // OK
score = "one hundred"; // Error: Type 'string' is not assignable to type 'number'.

You can also annotate and assign a value in one line:

let username: string = "Alice";
let score: number = 100;
let isLoggedIn: boolean = true;

Annotating constants

const variables cannot be reassigned. You can still annotate them, but it is often not needed because TypeScript infers the type from the value.

const MAX_RETRIES: number = 3;    // Annotation added for clarity
const API_URL: string = "https://api.example.com";
const DEBUG: boolean = false;

How to Annotate Function Parameters

Function parameters are the most important place to add type annotations. Without them, TypeScript cannot check if you call the function with the wrong values.

function greet(name: string): void {
  console.log("Hello, " + name);
}

greet("Alice"); // OK
greet(42);      // Error: Argument of type 'number' is not assignable to parameter of type 'string'.

Each parameter gets its own annotation:

function add(a: number, b: number): number {
  return a + b;
}

add(5, 10);    // OK — returns 15
add(5, "10");  // Error: Argument of type 'string' is not assignable to parameter of type 'number'.

Multiple parameters with different types

function createUser(name: string, age: number, isAdmin: boolean): void {
  console.log(name, age, isAdmin);
}

createUser("Alice", 30, true);  // OK
createUser(30, "Alice", true);  // Error: wrong order of types

How to Annotate Function Return Types

You write the return type after the closing parenthesis of the parameters, before the opening curly brace.

function getWelcomeMessage(name: string): string {
  return "Welcome, " + name;
}

The : string after (name: string) tells TypeScript this function must return a string.

If your function returns the wrong type, TypeScript catches it:

function getAge(): number {
  return "thirty";
  // Error: Type 'string' is not assignable to type 'number'.
}

The `void` return type

Use void when a function does not return anything:

function logMessage(message: string): void {
  console.log(message);
  // No return statement needed
}

void tells TypeScript and other developers: "This function does something but gives nothing back."

Common return type annotations

Return Type	When to Use
`string`	Function returns text
`number`	Function returns a numeric value
`boolean`	Function returns true or false
`void`	Function performs an action but returns nothing
`string[]`	Function returns an array of strings
`number[]`	Function returns an array of numbers

How to Annotate Arrays

To annotate an array, write the type followed by []:

let names: string[] = ["Alice", "Bob", "Charlie"];
let scores: number[] = [95, 87, 72];
let flags: boolean[] = [true, false, true];

TypeScript checks both the array itself and every item inside it:

let names: string[] = ["Alice", "Bob"];
names.push(42);
// Error: Argument of type 'number' is not assignable to parameter of type 'string'.

names.push("David"); // OK

The alternative `Array<type>` syntax

TypeScript also supports a second syntax for arrays using angle brackets:

let names: Array<string> = ["Alice", "Bob"];
let scores: Array<number> = [95, 87];

Both styles do exactly the same thing. Most developers use type[] because it is shorter and easier to read.

How to Annotate Objects

To annotate an object, you write the shape of the object inside curly braces:

let user: { name: string; age: number; isAdmin: boolean };

user = { name: "Alice", age: 30, isAdmin: true };  // OK
user = { name: "Alice", age: 30 };                 // Error: missing 'isAdmin'

TypeScript checks that the object has all the required properties with the right types.

Inline object annotation

You can write the annotation inline when you declare the variable:

let product: { id: number; title: string; price: number } = {
  id: 1,
  title: "TypeScript Book",
  price: 29.99
};

Optional properties in objects

Add a ? after the property name to make it optional:

let profile: { username: string; bio?: string } = {
  username: "alice_dev"
  // bio is optional, so we can skip it
};

Tip: For reusable object shapes, use a type alias or interface instead of writing the annotation inline every time. We cover those in later posts.

How to Annotate Union Types

Sometimes a variable can hold more than one type. Use a union type with the | symbol:

let id: string | number;

id = 101;       // OK
id = "abc_101"; // OK
id = true;      // Error: Type 'boolean' is not assignable to type 'string | number'.

You can use union types on function parameters too:

function printId(id: string | number): void {
  console.log("ID:", id);
}

printId(1);       // OK
printId("abc");   // OK

Note: We cover union types in detail in a later post. This is just a quick look at the annotation syntax.

How to Annotate with `null` and `undefined`

With strict: true, you need to be explicit when a value can be null or undefined.

let selectedItem: string | null = null;   // Can be a string or null
let cachedValue: number | undefined;      // Can be a number or undefined

Without the | null or | undefined, TypeScript will not let you assign those values:

let name: string = null;
// Error: Type 'null' is not assignable to type 'string'.

let name: string | null = null; // OK

What Happens to Annotations After Compilation?

Type annotations do not exist in JavaScript. When TypeScript compiles your code, it removes every annotation.

TypeScript (before compile):

let username: string = "Alice";
let score: number = 100;

function add(a: number, b: number): number {
  return a + b;
}

JavaScript (after compile):

let username = "Alice";
let score = 100;

function add(a, b) {
  return a + b;
}

All the : string, : number, and : boolean parts are stripped out. The output is clean JavaScript with no trace of the types.

This means type annotations have zero runtime cost. They only help you during development.

Annotation vs Inference: When to Write It Yourself

TypeScript can infer many types without annotations. So when should you write them yourself?

Write the annotation when:

You declare a variable without assigning a value right away
The return type of a function is not obvious
TypeScript infers a type that is too broad for your needs
You want to make the code easier to read for your team

Skip the annotation when:

The type is obvious from the assigned value
TypeScript can figure it out from context

// Skip annotation: value makes the type obvious
let name = "Alice";     // TypeScript infers: string
let count = 0;          // TypeScript infers: number
let active = true;      // TypeScript infers: boolean

// Write annotation: no value assigned yet
let username: string;
let retries: number;

// Write annotation: return type is not obvious from function name
function fetchData(): Promise<string> {
  return fetch("/api").then(res => res.text());
}

// Write annotation: function parameter always needs one
function double(n: number): number {
  return n * 2;
}

Full Example Putting It All Together

Here is a small program that uses type annotations throughout:

// Variable annotations
let appName: string = "TaskManager";
let version: number = 1;
let isProduction: boolean = false;

// Array annotation
let taskTitles: string[] = ["Write blog", "Review PR", "Fix bug"];

// Object annotation
let currentUser: { id: number; name: string; email: string } = {
  id: 1,
  name: "Alice",
  email: "alice@example.com"
};

// Function with parameter and return type annotations
function getTaskCount(tasks: string[]): number {
  return tasks.length;
}

// Function with void return type
function logStatus(status: string): void {
  console.log("App status:", status);
}

// Union type annotation
let searchInput: string | number = "";

// Optional value with null
let activeTask: string | null = null;

// Using the annotated values
const count: number = getTaskCount(taskTitles);
logStatus("running");
console.log(`${appName} v${version} — ${count} tasks loaded`);

Common Annotation Mistakes

Mistake 1: Using uppercase type names

let name: String = "Alice"; // Wrong — String is an object, not a primitive
let name: string = "Alice"; // Correct

Mistake 2: Forgetting the return type on public functions

// Unclear what this returns
function getUser(id: number) {
  return { id, name: "Alice" };
}

// Clearer with a return type
function getUser(id: number): { id: number; name: string } {
  return { id, name: "Alice" };
}

Mistake 3: Annotating when TypeScript can already infer the type

// Redundant annotation
let score: number = 100;

// Cleaner: TypeScript infers number from the value
let score = 100;

Mistake 4: Missing annotation on function parameters

// Bad: TypeScript has to guess what 'x' is
function square(x) {
  return x * x;
}

// Good: annotation makes the intent clear
function square(x: number): number {
  return x * x;
}

FAQ

Q: Do I have to annotate every variable?
No. TypeScript can infer many types on its own. Annotate when TypeScript cannot figure out the type, or when you want to make your intent clear to other developers.

Q: Do type annotations affect runtime performance?
No. TypeScript removes all annotations during compilation. The output is plain JavaScript with no types. Annotations have zero impact on how fast your code runs.

Q: What is the difference between a type annotation and a type assertion?
A type annotation tells TypeScript what type something should be. A type assertion (as SomeType) forces TypeScript to treat a value as a specific type, even if it disagrees. Annotations are the safe, standard way. Assertions should be used with care.

Q: Can I use type annotations in JavaScript files?
No. Type annotations only work in .ts files. If you need type hints in .js files, you can use JSDoc comments, but that is a different approach.

Q: Should I annotate the return type of every function?
It is good practice for public functions and exported utilities. For small internal helper functions where the return type is obvious, you can let TypeScript infer it.

Q: What happens if I annotate the wrong type?
TypeScript shows a compile error. For example, if you annotate a variable as number but assign a string, you will see an error immediately. The code will not compile until the mismatch is fixed.

What You Learned

Type annotations use the : type syntax after a variable, parameter, or function name
You can annotate variables, constants, function parameters, return types, arrays, and objects
Annotations are removed during compilation and have no runtime cost
Use void for functions that do not return a value
Use type[] to annotate arrays
Use { key: type } to annotate objects inline
Use | to annotate union types when a value can be more than one type
Write annotations when TypeScript cannot infer the type or when you want to be explicit

Sources: TypeScript Handbook — Type Annotations | TypeScript Tutorial — Type Annotations

How to Use Primitive Types in TypeScript: string, number, and boolean

Krunal Kanojiya — Thu, 11 Jun 2026 03:29:51 +0000

TLDR

TypeScript has 7 primitive types: string, number, boolean, null, undefined, bigint, and symbol. You use them to tell TypeScript what kind of value a variable holds. You write them in lowercase. TypeScript can often figure out the type for you. But knowing how each one works is key to writing safe and clear code.

What Are Primitive Types?

Primitive types are the simplest building blocks in TypeScript. Every piece of data in your program starts with one.

They hold a single value. They are not objects. You cannot add methods or properties to them directly.

TypeScript has 7 primitive types in total:

Type	What It Holds
`string`	Text like names, messages, or IDs
`number`	Any number: integers, decimals, negatives
`boolean`	Only `true` or `false`
`null`	An intentional empty value
`undefined`	A value that was never assigned
`bigint`	Very large whole numbers
`symbol`	A unique identifier value

This article covers all 7. You will use string, number, and boolean the most in everyday TypeScript code.

How to Use the `string` Type

A string holds text. Use it for names, messages, emails, URLs, and any other text data.

Basic string annotation

let firstName: string = "Alice";
let greeting: string = "Hello, world!";
let empty: string = "";

Three ways to write strings

TypeScript supports the same three string styles as JavaScript:

let single: string = 'Single quotes work fine';
let double: string = "Double quotes work too";
let template: string = `Template literals with ${firstName}`;

Template literals (backticks) let you insert values inside a string with ${}. TypeScript checks the types of those inserted values too.

let age: number = 30;
let message: string = `I am ${age} years old`;
// TypeScript checks that 'age' is compatible here

What TypeScript catches with strings

let name: string = "Alice";
name = 42;
// Error: Type 'number' is not assignable to type 'string'.

name = true;
// Error: Type 'boolean' is not assignable to type 'string'.

Once a variable is typed as string, TypeScript blocks you from putting a number or boolean in it.

Common string operations TypeScript knows about

let word: string = "typescript";

word.toUpperCase();   // string
word.length;          // number
word.includes("type"); // boolean
word.split("");       // string[]

TypeScript knows the return type of every built-in string method. This means you get autocomplete and error checking for free.

How to Use the `number` Type

In TypeScript, number covers all numeric values: whole numbers, decimals, and negative numbers. There is no separate int or float type.

All TypeScript numbers are 64-bit floating-point values under the hood.

Basic number annotation

let age: number = 30;
let price: number = 19.99;
let temperature: number = -5;
let zero: number = 0;

Special number values

let infinity: number = Infinity;
let negInfinity: number = -Infinity;
let notANumber: number = NaN;

All three of these are valid number values in TypeScript.

Number formats TypeScript supports

let decimal: number = 255;        // Regular decimal
let hex: number = 0xFF;           // Hexadecimal (255)
let binary: number = 0b11111111;  // Binary (255)
let octal: number = 0o377;        // Octal (255)

All four lines hold the same value: 255. TypeScript accepts all these formats as number.

What TypeScript catches with numbers

let score: number = 100;
score = "one hundred";
// Error: Type 'string' is not assignable to type 'number'.

A common mistake: numbers as strings

let userInput: string = "42"; // This is a string, not a number

let doubled: number = userInput * 2;
// Error: The left-hand side of an arithmetic operation must be
// of type 'any', 'number', 'bigint' or an enum type.

TypeScript stops you from doing math with strings. You need to convert first:

let userInput: string = "42";
let doubled: number = Number(userInput) * 2; // Safe conversion

How to Use the `boolean` Type

A boolean holds one of only two values: true or false. Use it for flags, toggles, conditions, and yes/no states.

Basic boolean annotation

let isLoggedIn: boolean = true;
let hasPermission: boolean = false;
let isLoading: boolean = false;

Booleans from comparisons

Most of the time you do not write true or false by hand. You get booleans from comparisons:

let age: number = 20;
let isAdult: boolean = age >= 18;       // true
let isTeenager: boolean = age < 18;     // false
let isExactly20: boolean = age === 20;  // true

Booleans in conditions

let isLoggedIn: boolean = true;

if (isLoggedIn) {
  console.log("Welcome back!");
} else {
  console.log("Please log in.");
}

What TypeScript catches with booleans

let isActive: boolean = true;
isActive = 1;
// Error: Type 'number' is not assignable to type 'boolean'.

isActive = "yes";
// Error: Type 'string' is not assignable to type 'boolean'.

In JavaScript, 1 and "yes" are both truthy. But TypeScript does not let you assign them to a boolean variable. You must use true or false.

How to Use the `null` Type

null means you are intentionally saying a value is empty or missing. It is a deliberate choice.

let selectedUser: string | null = null;
// No user is selected yet

`null` on its own

You can type a variable as only null. But this is rarely useful on its own.

let nothing: null = null;
nothing = "hello";
// Error: Type 'string' is not assignable to type 'null'.

`null` combined with other types

The real power of null is combining it with other types using a union (|):

let username: string | null = null;

// Later, when the user logs in:
username = "Alice"; // Also valid

Working safely with `null` values

With strict: true, TypeScript forces you to check for null before using a value:

let username: string | null = null;

console.log(username.toUpperCase());
// Error: 'username' is possibly 'null'.

// Fix: Check first
if (username !== null) {
  console.log(username.toUpperCase()); // Safe
}

How to Use the `undefined` Type

undefined means a value was never assigned. TypeScript uses this automatically for uninitialized variables and missing function return values.

let city: string | undefined = undefined;

function findUser(id: number): string | undefined {
  if (id === 1) {
    return "Alice";
  }
  return undefined; // No user found
}

The difference between `null` and `undefined`

This trips up many developers. Here is the key difference:

	`null`	`undefined`
Meaning	"I know there is no value here"	"This has not been set yet"
Set by	You, on purpose	TypeScript or JS automatically
Common use	Function returns no result	Optional properties, unset variables

let a: null = null;          // You chose to leave this empty
let b: undefined = undefined; // This was never set

console.log(typeof a); // "object" (a JavaScript quirk)
console.log(typeof b); // "undefined"

Note: typeof null returns "object" in JavaScript. This is a long-standing bug in the language. TypeScript is aware of this and handles it correctly in type checks.

How to Use the `bigint` Type

bigint is for working with very large whole numbers. The regular number type can safely handle integers up to 2^53 - 1 (which is 9,007,199,254,740,991). Anything bigger needs bigint.

let bigNumber: bigint = 9007199254740992n; // Add 'n' at the end
let anotherBig: bigint = BigInt(9007199254740992);

When to use `bigint`

Working with large database IDs
Financial calculations that need exact integer precision
Cryptography
Scientific computing with very large numbers

What you cannot do with `bigint`

You cannot mix bigint and number in operations:

let big: bigint = 100n;
let regular: number = 50;

let result = big + regular;
// Error: Operator '+' cannot be applied to types 'bigint' and 'number'.

You must convert one to match the other:

let big: bigint = 100n;
let regular: number = 50;

let result = big + BigInt(regular); // Convert number to bigint

Important: bigint only works when your tsconfig.json has "target": "ES2020" or higher.

How to Use the `symbol` Type

symbol creates a completely unique value. No two symbols are ever equal, even if they have the same description.

let id1: symbol = Symbol("id");
let id2: symbol = Symbol("id");

console.log(id1 === id2); // false — they are always unique

When to use `symbol`

Symbols are mainly used as unique keys for object properties. They prevent name clashes when two pieces of code use the same property name.

const USER_ID = Symbol("userId");

const user = {
  [USER_ID]: 123,
  name: "Alice"
};

console.log(user[USER_ID]); // 123

In everyday application code, you will rarely use symbol. It is more common in library code and advanced patterns.

Type Annotations vs Type Inference

You do not always have to write the type yourself. TypeScript can figure it out from the value you assign. This is called type inference.

let name = "Alice";   // TypeScript infers: string
let age = 30;         // TypeScript infers: number
let active = true;    // TypeScript infers: boolean

TypeScript reads the value on the right side and assigns the type automatically.

When should you write the type yourself?

// You SHOULD annotate when declaring without a value
let username: string;
username = "Alice";

// You SHOULD annotate when the type is not obvious
let score: number = calculateScore(); // Makes the return type clear

// You CAN skip annotation when the value is obvious
let count = 0; // No need to write ': number'

A good rule: if the type is obvious from the value, let TypeScript infer it. If the type is not clear, write it yourself.

All 7 Primitive Types at a Glance

// string
let name: string = "Alice";

// number
let age: number = 30;

// boolean
let isActive: boolean = true;

// null
let selected: null = null;

// undefined
let result: undefined = undefined;

// bigint (requires target ES2020+)
let bigId: bigint = 9999999999999999999n;

// symbol
let uniqueKey: symbol = Symbol("key");

Quick Comparison of All Primitive Types

Type	Example Value	Common Use Case
`string`	`"hello"`	Names, messages, URLs
`number`	`42`, `3.14`, `-1`	Scores, prices, ages
`boolean`	`true`, `false`	Flags, toggles, conditions
`null`	`null`	Intentional empty value
`undefined`	`undefined`	Unset variables, optional returns
`bigint`	`9999n`	Very large integers
`symbol`	`Symbol("id")`	Unique object property keys

Common Mistakes with Primitive Types

Mixing types without a union:

let value: string = "hello";
value = 42; // Error: You must use string | number if both are valid

Comparing loosely instead of strictly:

let count: number = 0;

if (count == false) { } // Loose comparison, avoid this
if (count === 0) { }    // Strict comparison, TypeScript-friendly

Confusing null and undefined:

// These are different
let a: null = null;
let b: undefined = undefined;

a === b;  // false
a == b;   // true (loose equality, but TypeScript will warn you)

Writing type names with capital letters:

// Wrong — these are JavaScript wrapper objects, not primitive types
let name: String = "Alice"; // Avoid
let age: Number = 30;       // Avoid
let flag: Boolean = true;   // Avoid

// Correct — always use lowercase
let name: string = "Alice";
let age: number = 30;
let flag: boolean = true;

Always use lowercase. string is the primitive type. String (capital S) is a JavaScript object. They behave differently. Always use the lowercase versions in TypeScript.

FAQ

Q: Does TypeScript have a separate int type for whole numbers?
No. TypeScript uses number for all numeric values including integers and decimals. If you need very large integers, use bigint.

Q: Can a variable hold both a string and a number?
Yes. Use a union type: let value: string | number. We cover union types in detail in a later post.

Q: Should I always annotate my variables with types?
Not always. If TypeScript can infer the type from the value, you do not need to write it. For example, let name = "Alice" is fine without : string. Write annotations when the type is not obvious.

Q: What is the difference between null and undefined in TypeScript?
null means the value is intentionally empty. undefined means the value was never set. Use null when you want to say "there is no value here on purpose." Use undefined for optional or uninitialized values.

Q: Why should I use lowercase string instead of String?
string (lowercase) is the primitive type. String (uppercase) is a JavaScript wrapper object. They are different. Using String can cause unexpected behavior. Always use the lowercase versions.

Q: Does TypeScript have a float type?
No. Both integers and floating-point numbers use the number type. Under the hood, all TypeScript numbers are 64-bit floating-point values.

What You Learned

TypeScript has 7 primitive types: string, number, boolean, null, undefined, bigint, and symbol
string holds text, number holds all numeric values, boolean holds true or false
null is an intentional empty value; undefined means a value was never assigned
bigint handles integers larger than 2^53 - 1 and requires target: ES2020 or higher
symbol creates unique values used as object property keys
TypeScript can infer types from values, so you do not always need to write them
Always use lowercase type names: string, number, boolean, not String, Number, Boolean

Sources: TypeScript Handbook — Basic Types | TypeScript TSConfig Reference

How to Enable Strict Mode and Why You Should Always Use It

Krunal Kanojiya — Wed, 10 Jun 2026 17:33:11 +0000

TLDR

Strict mode in TypeScript turns on 8 safety checks at once with one line: "strict": true in your tsconfig.json. It catches null errors, missing types, uninitialized class properties, and more before your code ever runs. Always enable it on new projects. On older projects, turn on the 8 flags one at a time and fix errors as you go.

What is Strict Mode in TypeScript?

By default, TypeScript is pretty relaxed. It lets you skip types in some places. It does not check for null on every value. It allows some patterns that can crash at runtime.

Strict mode fixes all of that. It is a single switch that turns on a group of type-checking rules all at once.

Think of it like turning on every warning light in a car instead of just the engine light. You see more problems, but that means you fix them before they cause a crash.

How to Enable Strict Mode

Enabling strict mode takes one line in your tsconfig.json.

{
  "compilerOptions": {
    "strict": true
  }
}

That is it. This one setting turns on 8 different checks at the same time.

You can also turn it on temporarily from the command line:

tsc --strict

What Does `strict: true` Actually Turn On?

When you set "strict": true, TypeScript enables these 8 flags automatically:

Flag	What It Checks
`strictNullChecks`	Stops you from using `null` or `undefined` where a real value is expected
`noImplicitAny`	Forces you to add types when TypeScript cannot figure them out
`strictFunctionTypes`	Checks that function parameters match the expected types correctly
`strictBindCallApply`	Makes `.bind()`, `.call()`, and `.apply()` type-safe
`strictPropertyInitialization`	Makes sure class properties are set in the constructor
`noImplicitThis`	Stops you from using `this` when its type is unclear
`useUnknownInCatchVariables`	Makes the `error` variable in `catch` blocks `unknown` instead of `any`
`alwaysStrict`	Adds `"use strict"` to every compiled JavaScript file

You do not need to set any of these one by one. "strict": true handles all of them.

Note: TypeScript may add new flags to the strict group in future versions. When you upgrade TypeScript, those new flags turn on automatically if you have "strict": true. This is a good thing. It means your code gets safer with every upgrade.

Why Each Flag Matters (With Code Examples)

1. `strictNullChecks` — Stop Null Crashes

This is the most important flag. Without it, TypeScript lets you use null and undefined anywhere. This causes runtime crashes.

Without strict:

function getLength(text: string): number {
  return text.length; // No error here
}

getLength(null); // Compiles fine. Crashes at runtime.

With strict:

function getLength(text: string): number {
  return text.length;
}

getLength(null);
// Error: Argument of type 'null' is not assignable
// to parameter of type 'string'.

Now TypeScript forces you to handle the null case before using the value:

function getLength(text: string | null): number {
  if (text === null) {
    return 0;
  }
  return text.length; // TypeScript knows text is a string here
}

2. `noImplicitAny` — No Hidden `any` Types

Without this flag, TypeScript quietly gives some values the type any when it cannot figure out the type. any turns off type checking for that value. It defeats the whole point of using TypeScript.

Without strict:

function processItems(items) { // items is silently 'any'
  items.forEach(item => {
    console.log(item.name); // No type checking at all
  });
}

With strict:

function processItems(items) {
// Error: Parameter 'items' implicitly has an 'any' type.
}

Now you must add a type:

function processItems(items: string[]): void {
  items.forEach(item => {
    console.log(item); // TypeScript checks this correctly
  });
}

3. `strictPropertyInitialization` — Class Properties Must Be Set

Without this flag, you can declare a class property and never set it. Then it is undefined at runtime and causes bugs.

Without strict:

class User {
  name: string; // Never set in constructor

  greet() {
    console.log(this.name.toUpperCase()); // Crashes at runtime
  }
}

With strict:

class User {
  name: string;
  // Error: Property 'name' has no initializer and is not
  // definitely assigned in the constructor.
}

Now you must either set it in the constructor or mark it as optional:

// Option 1: Set it in the constructor
class User {
  name: string;

  constructor(name: string) {
    this.name = name;
  }
}

// Option 2: Mark it optional with a default
class User {
  name: string = "Guest";
}

// Option 3: Mark it as possibly undefined
class User {
  name?: string;
}

4. `useUnknownInCatchVariables` — Safe Error Handling

In older TypeScript, the error variable inside a catch block had the type any. That meant you could call any method on it without checking. This could crash.

Without strict:

try {
  doSomething();
} catch (error) {
  console.log(error.message); // error is 'any', no check done
}

With strict:

try {
  doSomething();
} catch (error) {
  console.log(error.message);
  // Error: 'error' is of type 'unknown'.
}

Now you must check what kind of error it is before using it:

try {
  doSomething();
} catch (error) {
  if (error instanceof Error) {
    console.log(error.message); // Safe to use
  } else {
    console.log("Unknown error occurred");
  }
}

5. `strictBindCallApply` — Type-Safe Function Methods

This flag makes .call(), .bind(), and .apply() check that you pass the right argument types.

Without strict:

function greet(name: string): string {
  return `Hello, ${name}`;
}

greet.call(undefined, 42); // Wrong type, but no error

With strict:

function greet(name: string): string {
  return `Hello, ${name}`;
}

greet.call(undefined, 42);
// Error: Argument of type 'number' is not assignable
// to parameter of type 'string'.

6. `noImplicitThis` — Clear `this` Typing

Without this flag, using this inside a regular function is allowed even when TypeScript does not know what this points to.

Without strict:

function printName() {
  console.log(this.name); // 'this' is implicitly 'any'
}

With strict:

function printName() {
  console.log(this.name);
  // Error: 'this' implicitly has type 'any' because it does
  // not have a type annotation.
}

Fix it by adding an explicit this type:

function printName(this: { name: string }) {
  console.log(this.name); // TypeScript knows the shape of 'this'
}

Two Extra Flags Worth Adding

These two flags are NOT included in strict: true. But they are worth turning on for even safer code.

`noUncheckedIndexedAccess`

When you access an array item by index, TypeScript normally assumes the item exists. This flag makes it return T | undefined instead.

const names: string[] = ["Alice", "Bob"];

// Without noUncheckedIndexedAccess
const first: string = names[0]; // TypeScript thinks this is always a string

// With noUncheckedIndexedAccess
const first: string | undefined = names[0]; // Safer, might be undefined
if (first !== undefined) {
  console.log(first.toUpperCase()); // Now safe to use
}

`noImplicitOverride`

This flag makes you add the override keyword when you override a method in a subclass. It prevents silent bugs when the parent class changes.

class Animal {
  makeSound() {
    console.log("...");
  }
}

// Without noImplicitOverride: no error even if parent renames the method
class Dog extends Animal {
  makeSound() { // Silently breaks if parent renames makeSound()
    console.log("Woof");
  }
}

// With noImplicitOverride: you must write override
class Dog extends Animal {
  override makeSound() { // Clear intent, compiler verifies parent has this
    console.log("Woof");
  }
}

Add them to your tsconfig.json alongside strict:

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true
  }
}

The Full Recommended Strict Config

Here is the complete set of strict options we recommend for all new TypeScript projects:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true
  }
}

Here is what the extra flags do:

Flag	What It Does
`noUnusedLocals`	Errors on variables that are declared but never used
`noUnusedParameters`	Errors on function parameters that are never used
`noImplicitReturns`	Errors when a function does not return a value on all paths

What the Same Code Looks Like Without and With Strict Mode

Here is a real example. This function has two silent bugs without strict mode.

Without strict mode (no errors shown):

function getUserCity(user) {
  return user.address.city;
}

const city = getUserCity(null);
console.log(city.toUpperCase());

This code compiles with no errors. But it will crash at runtime because:

user could be null
user.address could be undefined
city could be undefined

With strict mode (all bugs caught at compile time):

// Error on line 1: Parameter 'user' implicitly has an 'any' type.
function getUserCity(user) {
  return user.address.city;
}

TypeScript stops you right away. You now write a safe version:

type Address = {
  city: string;
};

type User = {
  address: Address | null;
};

function getUserCity(user: User | null): string {
  if (user === null || user.address === null) {
    return "Unknown";
  }
  return user.address.city;
}

const city = getUserCity(null);
console.log(city.toUpperCase()); // Always safe

How to Enable Strict Mode on an Existing Project

If you are adding TypeScript to an older project, turning on strict: true all at once can show hundreds of errors. That is overwhelming.

Do it step by step instead.

Step 1: Keep strict off. Turn on flags one at a time.

{
  "compilerOptions": {
    "strict": false,
    "noImplicitAny": true
  }
}

Step 2: Fix all the errors from that flag. Commit your changes.

Step 3: Add the next flag.

{
  "compilerOptions": {
    "strict": false,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

Step 4: Keep going until all 8 flags are on. Then replace them all with "strict": true.

Here is a good order to follow when migrating:

Step	Flag to Enable	Why This Order
1	`noImplicitAny`	Easiest to fix, forces you to add types
2	`strictNullChecks`	Most impactful, stops null crashes
3	`strictPropertyInitialization`	Fixes class property bugs
4	`strictFunctionTypes`	Catches function type mismatches
5	`strictBindCallApply`	Usually few errors, easy to fix
6	`noImplicitThis`	Quick fixes with `this` annotations
7	`useUnknownInCatchVariables`	Makes catch blocks safer
8	`alwaysStrict`	Adds `"use strict"` to JS output

Does Strict Mode Change the JavaScript Output?

No. Strict mode is a compile-time feature only.

All the checks happen when you run tsc. The compiled JavaScript output is identical whether strict mode is on or off.

The only exception is alwaysStrict. That flag adds "use strict" at the top of every compiled JavaScript file. But that is a JavaScript directive, not a TypeScript type change.

Common Errors You Will See After Enabling Strict Mode

Here are the errors developers hit most often after turning on strict mode.

"Object is possibly null"

const el = document.getElementById("app");
el.innerHTML = "Hello"; 
// Error: 'el' is possibly 'null'.

// Fix:
const el = document.getElementById("app");
if (el !== null) {
  el.innerHTML = "Hello";
}

"Parameter implicitly has an 'any' type"

function double(n) { // Error
  return n * 2;
}

// Fix:
function double(n: number): number {
  return n * 2;
}

"Property has no initializer"

class Cart {
  items: string[]; // Error
}

// Fix:
class Cart {
  items: string[] = [];
}

"Not all code paths return a value"

function grade(score: number) {
  if (score >= 90) {
    return "A";
  }
  // Error: Function lacks ending return statement
}

// Fix:
function grade(score: number): string {
  if (score >= 90) {
    return "A";
  }
  return "B";
}

FAQ

Q: Does strict mode make TypeScript harder to use?
At first, yes. You will see more errors. But each error points to a real bug. Over time, your code becomes more reliable and easier to maintain.

Q: Can I turn off just one strict flag?
Yes. You can override any individual flag even with strict: true. For example, if you want everything except alwaysStrict, set it to false after enabling strict:

{
  "compilerOptions": {
    "strict": true,
    "alwaysStrict": false
  }
}

Q: Should I use strict mode on a team project?
Yes. Always. Agree on it at the start of the project so the whole team works with the same rules.

Q: Is strict: true the default?
No. TypeScript defaults to strict: false. You have to opt in. This is why you should always set it manually.

Q: Does strict mode slow down compilation?
A tiny bit. More checks take more time. But the difference is not noticeable on most projects.

Q: What is the difference between strict and strictNullChecks?
strictNullChecks is one of the 8 checks inside strict: true. Setting strict: true includes strictNullChecks plus 7 other checks. Always use strict: true instead of setting individual flags one by one on new projects.

What You Learned

"strict": true in tsconfig.json turns on 8 safety checks at once
strictNullChecks stops null crashes before they happen at runtime
noImplicitAny forces you to add proper types everywhere
strictPropertyInitialization catches unset class properties
useUnknownInCatchVariables makes error handling safer
Add noUncheckedIndexedAccess and noImplicitOverride for even more safety
On new projects, always start with strict: true
On existing projects, enable each flag one at a time and fix errors before adding the next

Sources: TypeScript TSConfig Reference | TypeScript Official Docs — Strict Mode

How to Use the TypeScript Compiler (tsc) to Compile Your Code

Krunal Kanojiya — Wed, 10 Jun 2026 03:41:20 +0000

TLDR

tsc is the TypeScript compiler. It turns your .ts files into .js files that Node.js and browsers can run. Install it with npm install -g typescript. Run tsc to compile your whole project. Run tsc --watch to auto-compile on every file save. Run tsc --noEmit to check for errors without creating any files.

What is the TypeScript Compiler?

The TypeScript compiler is a tool called tsc. It reads your TypeScript files and turns them into JavaScript files.

Your browser and Node.js cannot run TypeScript directly. They only understand JavaScript. So tsc acts as the bridge between what you write and what actually runs.

Think of tsc like a spell checker for your code. It finds problems before your code ever runs. Then it produces clean JavaScript output for you.

How to Install the TypeScript Compiler

You install tsc using npm. There are two ways to do this.

Option 1: Global Install (runs anywhere on your computer)

npm install -g typescript

After install, check it works:

tsc --version

You will see something like Version 6.0.3.

Option 2: Local Install (recommended for teams)

npm install --save-dev typescript

Then run it using npx:

npx tsc --version

Which one should you use? Use a local install for project work. This makes sure everyone on your team uses the same TypeScript version. Use a global install only for quick personal experiments.

How to Compile a Single TypeScript File

The simplest way to use tsc is to pass it a single file.

Create a file called hello.ts:

const message: string = "Hello, TypeScript!";
console.log(message);

Now compile it:

tsc hello.ts

This creates a new file called hello.js in the same folder:

var message = "Hello, TypeScript!";
console.log(message);

Notice that TypeScript removed the : string type annotation. The output is plain JavaScript that Node.js can run.

Run the output file:

node hello.js
# Hello, TypeScript!

Important: When you pass a file directly to tsc, it ignores your tsconfig.json. It uses its own default settings instead. For real projects, always use tsconfig.json.

How to Compile Your Whole Project

For most projects, you will not compile one file at a time. You will compile the whole project using tsconfig.json.

Just run tsc with no arguments:

tsc

TypeScript will look for a tsconfig.json in your current folder. It reads the settings and compiles all included .ts files.

If your tsconfig.json has this setup:

{
  "compilerOptions": {
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src"]
}

Running tsc will take all files from src/ and put compiled .js files into dist/.

Before tsc:             After tsc:
src/                    src/
  index.ts                index.ts
  utils.ts                utils.ts
                        dist/
                          index.js
                          utils.js

How to Use Watch Mode (Auto-Compile on Save)

Running tsc by hand every time you change a file is slow. Watch mode fixes this.

tsc --watch

Or use the short form:

tsc -w

Now TypeScript watches all your files. Every time you save a .ts file, it recompiles automatically. You will see output like this:

[12:10:01 PM] Starting compilation in watch mode...
[12:10:02 PM] Found 0 errors. Watching for file changes.

[12:10:45 PM] File change detected. Starting incremental compilation...
[12:10:45 PM] Found 0 errors. Watching for file changes.

To stop watch mode, press CTRL + C in your terminal.

Tip: Keep watch mode running in a terminal tab while you code. You will see errors right away instead of finding them later.

How to Type-Check Without Creating Files

Sometimes you just want to check for type errors. You do not want to produce any JavaScript output.

Use the --noEmit flag:

tsc --noEmit

This runs all the type checks and prints any errors. But it does not create any .js files.

This is very useful in two places:

In your CI/CD pipeline to make sure code passes type checks before deploying
Before a commit to catch bugs without building the whole project

# Check types only, no output files
tsc --noEmit

# Check types in watch mode (good during development)
tsc --noEmit --watch

How to Use a Specific Config File

By default, tsc looks for tsconfig.json in your current folder. You can tell it to use a different config file with --project.

tsc --project tsconfig.prod.json

Or use the short form:

tsc -p tsconfig.prod.json

This is useful when you have different builds. For example:

Config File	Used For
`tsconfig.json`	Default development settings
`tsconfig.prod.json`	Production build with stricter settings
`tsconfig.test.json`	Test environment settings

Most Useful tsc CLI Flags

Here is a list of the flags you will use the most.

Flag	Short Form	What It Does
`--watch`	`-w`	Recompile automatically on file changes
`--noEmit`		Check types only, no JS output
`--project`	`-p`	Use a specific config file
`--init`		Create a new `tsconfig.json`
`--version`	`-v`	Show the TypeScript version
`--help`	`-h`	Show all available options
`--listFiles`		Print all files being compiled
`--showConfig`		Print the full merged config
`--incremental`		Speed up builds by caching
`--strict`		Enable strict mode for this run
`--target`		Set the JS output version for this run
`--outDir`		Set the output folder for this run

How to Pass Flags Without tsconfig.json

You can pass compilerOptions directly from the command line. This is useful for quick tests.

# Compile a file targeting ES2022 output
tsc index.ts --target ES2022

# Compile two files into one output file
tsc app.ts utils.ts --target ESNext --outFile bundle.js

# Compile with strict mode on
tsc index.ts --strict

Remember: Flags passed on the command line override what is in your tsconfig.json. Use this only for testing and one-off tasks.

How to Debug Compilation Problems

When something goes wrong with compilation, these two flags help you figure out what is happening.

`--listFiles`

This shows you every file TypeScript is including in the compilation.

tsc --listFiles

Output example:

/usr/local/lib/node_modules/typescript/lib/lib.es2022.d.ts
/home/user/project/src/index.ts
/home/user/project/src/utils.ts

Use this when TypeScript is compiling files you did not expect.

`--showConfig`

This prints the full merged config that TypeScript is actually using.

tsc --showConfig

Output example:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "commonjs",
    "strict": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "files": [
    "./src/index.ts",
    "./src/utils.ts"
  ]
}

Use this when you are not sure what settings are active. This is especially helpful when you use extends to inherit from another config file.

Understanding tsc Exit Codes

Exit codes tell you if the compilation succeeded or failed. This matters a lot in CI/CD pipelines.

Exit Code	Meaning
`0`	Compilation succeeded with no errors
`1`	Compilation failed with errors
`2`	Invalid compiler arguments were passed

You can check the exit code in your shell like this:

tsc --noEmit
echo $?   # Prints 0 if no errors, 1 if there are errors

In a GitHub Actions workflow, you can use this pattern:

- name: Type check
  run: npx tsc --noEmit

If there are type errors, the pipeline stops and fails. This prevents broken code from being deployed.

How to Speed Up Compilation with Incremental Mode

For large projects, tsc can take a long time to compile. Incremental mode speeds things up by remembering what it compiled last time.

Turn it on in your tsconfig.json:

{
  "compilerOptions": {
    "incremental": true
  }
}

Or use the flag directly:

tsc --incremental

The first run will take the same amount of time. But every run after that will be much faster because TypeScript only recompiles files that changed.

TypeScript stores a cache in a file called .tsbuildinfo. Do not delete this file if you want faster builds.

my-project/
├── src/
├── dist/
├── tsconfig.json
└── tsconfig.tsbuildinfo    <-- build cache, keep this

Tip: Add .tsbuildinfo to your .gitignore file. There is no need to commit it.

How to Use tsc in Your package.json Scripts

Most developers add tsc commands to their package.json so the team does not have to remember flags.

{
  "scripts": {
    "build": "tsc",
    "build:watch": "tsc --watch",
    "type-check": "tsc --noEmit",
    "type-check:watch": "tsc --noEmit --watch"
  }
}

Now your team can run simple commands:

npm run build           # Compile the project
npm run build:watch     # Compile and watch for changes
npm run type-check      # Check types without building

This is a clean workflow that works for every developer on your team.

Common tsc Errors and What They Mean

Here are some errors you will see when starting out.

Error: Cannot find a tsconfig.json file

error TS5083: Cannot read file '/project/tsconfig.json'.

Fix: Make sure you are in the right folder. Run tsc --init if you do not have a tsconfig.json yet.

Error: Argument of type is not assignable

error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

Fix: You passed the wrong type to a function. Check your function's expected parameter types.

Error: rootDir is expected to contain all source files

error TS6059: File '/project/tests/app.test.ts' is not under 'rootDir' '/project/src'.

Fix: Your rootDir does not include all your .ts files. Update rootDir or adjust your include list.

Error: Cannot write file because it would overwrite input file

error TS5055: Cannot write file 'index.js' because it would overwrite input file.

Fix: Set an outDir in your tsconfig.json. TypeScript cannot save output files to the same place as source files.

Full Workflow Example

Here is a complete example of a TypeScript project using tsc the right way.

Project structure:

my-app/
├── src/
│   ├── index.ts
│   └── math.ts
├── tsconfig.json
└── package.json

src/math.ts:

export function add(a: number, b: number): number {
  return a + b;
}

src/index.ts:

import { add } from "./math";

const result: number = add(5, 3);
console.log(result);

tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "strict": true,
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["src"]
}

package.json scripts:

{
  "scripts": {
    "build": "tsc",
    "dev": "tsc --watch",
    "type-check": "tsc --noEmit"
  }
}

Now run:

npm run build

You will get:

dist/
  index.js
  math.js

Run the output:

node dist/index.js
# 8

That is a clean, working TypeScript workflow using tsc.

FAQ

Q: Do I need to run tsc every time I save a file?
No. Use tsc --watch and it will recompile automatically every time you save.

Q: Can I run TypeScript files without compiling?
Yes. Tools like ts-node and tsx can run TypeScript directly without a separate compile step. But for production use, you should always compile with tsc first.

Q: What is the difference between tsc and npx tsc?
If you installed TypeScript globally, use tsc. If you installed it locally in your project, use npx tsc. npx picks up the local version from your node_modules.

Q: Does tsc minify my JavaScript output?
No. tsc does not minify code. It only compiles TypeScript to JavaScript. For minification, use a bundler like Vite, Webpack, or esbuild.

Q: Why does tsc still output files even when there are errors?
By default, tsc emits JavaScript even if there are type errors. To stop this, set "noEmitOnError": true in your tsconfig.json.

Q: How do I compile only changed files to make builds faster?
Use "incremental": true in your tsconfig.json. TypeScript will cache the last build and only recompile changed files.

What You Learned

tsc is the TypeScript compiler that turns .ts files into .js files
Install with npm install --save-dev typescript and run with npx tsc
Run tsc to compile your whole project using tsconfig.json
Use --watch to auto-compile on every file save
Use --noEmit to type-check without creating files
Use --project to point to a specific config file
Use --showConfig and --listFiles to debug compilation issues
Add tsc commands to your package.json scripts so your whole team can use them

Sources: TypeScript Official tsc CLI Docs | TypeScript TSConfig Reference

DEV Community: Krunal Kanojiya

Selection Sort Explained With a Bookshelf Story (With Code)

How Selection Sort Actually Works

The Code

Why It Never Gets Faster, No Matter the Input

Where Selection Sort Actually Wins

The Stability Problem

Selection Sort vs Its Closest Relatives

The One Thing to Remember

FAQs:

What Is Databricks? Uses, Benefits, and How Databricks Works

What Is Databricks?

What Problem Does Databricks Solve?

How Does Databricks Work?

What Is Databricks Used For?

Data pipelines

Business analytics

Real-time processing

Machine learning and AI

A Simple E-commerce Example

Who Uses Databricks?

When Should You Use Databricks?

How to Migrate an Ecommerce Store to Shopify Without Losing Data or SEO

Design the Migration as a Pipeline

1. Audit the Source Store

2. Establish a Migration Baseline

3. Build a Field-Mapping Document

4. Choose CSV or API Imports

Use CSV when

Use Shopify APIs when

5. Normalize the Source Data

6. Handle Platform-Specific Differences

WooCommerce

Magento or Adobe Commerce

BigCommerce

7. Import Into a Development Store

8. Build the Redirect Map Before Launch

9. Reconcile the Destination

10. Test the Complete Commerce Journey

11. Plan the Final Incremental Sync

12. Monitor After Launch

Production Migration Checklist

Final Thoughts

Top Shopify Agencies in the US for 2026 (A Developer's Honest Take)

Why Picking a Shopify Agency Feels Harder Than It Should

What to Look for Before You Even Open a Proposal

Top Shopify Agencies in the US for 2026

1. Lucent Innovation

2. SmartSites

3. Lounge Lizard

4. Coalition Technologies

5. BlueSwitch

6. Sleepless Media

7. Digital Silk

8. 1Digital Agency

Choosing Between Them: A Framework That Actually Helps

The Honest Reality of Agency Pricing in 2026

Final Take

How to Use the any Type and When to Avoid It

TLDR

What is the any Type?

How any Disables Type Checking

Two Ways any Appears in Your Code

Explicit any

Implicit any

Why any is Dangerous

Problem 1: Errors reach runtime instead of compile time

Problem 2: any spreads to other variables

Problem 3: You lose IDE support

Problem 4: Bugs survive code reviews

The any Infection Example

When is any Actually Okay to Use?

The Right Alternative: unknown

Practical example: Handling API responses safely

How to Handle any When Migrating JavaScript Code

How to Prevent any With ESLint

@ts-ignore and @ts-expect-error: Related Escape Hatches

any vs unknown vs never: Quick Comparison

Common Mistakes with any

FAQ

What is the `any` Type?

How `any` Disables Type Checking

Two Ways `any` Appears in Your Code

Explicit `any`

Implicit `any`

Why `any` is Dangerous

Problem 2: `any` spreads to other variables

The `any` Infection Example

When is `any` Actually Okay to Use?

The Right Alternative: `unknown`

How to Handle `any` When Migrating JavaScript Code

How to Prevent `any` With ESLint

`@ts-ignore` and `@ts-expect-error`: Related Escape Hatches

`any` vs `unknown` vs `never`: Quick Comparison

Common Mistakes with `any`

The `void` return type

The alternative `Array<type>` syntax

How to Annotate with `null` and `undefined`

How to Use the `string` Type

How to Use the `number` Type

How to Use the `boolean` Type